Thu 24 Nov 2016 12:17:11 AM UTC, comment #35:
Closing this bug as fixed now, since I don't see any mention of this bug occurring on the 4.2 development branch in the bug log, and 4.2 is now released and no further work is being done on the 4.0 branch. If the test cases in this bug log can still trigger some kind of error with Octave 4.2, I would recommend filing a new bug report mentioning the history here.
|
Fri 03 Jun 2016 05:34:48 PM UTC, comment #34:
Yes I believe Pascal's testing has all been on the stable branch. I briefly looked at his stack traces, seems to be some contention between what the interpreter thread is doing while the Qt thread is trying to render an axes object.
|
Fri 03 Jun 2016 04:35:49 PM UTC, comment #33:
Continuation of the previous comment: stack trace of all the threads when the hang occurs.
Regards
Pascal
(file #37380)
|
Fri 03 Jun 2016 04:09:39 PM UTC, comment #32:
@Pascal: Was your backtrace made against the stable branch or the development branch? I want to know how to match up the line numbers in the report.
|
Fri 03 Jun 2016 04:00:40 PM UTC, comment #31:
The first script posted by J. Bect still hangs, even using Rick changeset 21803:4950810ce605 stable
I enclose the file 46466_callstack_example1
Very similar pattern; opengl_renderer::set_font => octave functions => hang
Regards
Pascal
(file #37378)
|
Fri 03 Jun 2016 10:21:38 AM UTC, comment #30:
I ran plot_string_error2 a few times under gdb with
set args --no-gui plot_string_error2.m
set detach-on-fork off
b octave_base_value::convert_to_str_internal
r
I include the backtrace when the hangs happen. The context before entering Octave is opengl_renderer::draw => opengl_renderer::draw_axes => opengl_renderer::set_font
Regards
This mean that rev 21803 helps but does probably not prevent all cases.
Regards
(file #37373)
|
Fri 03 Jun 2016 07:43:12 AM UTC, comment #29:
I compiled the stable branch with revision 21803. I confirm the bug disappeared in qt.
Side effect: the gramm demo runs under qt without hanging
Platform: x86_64, fedora 23
Regards
Pascal
|
Fri 03 Jun 2016 02:50:39 AM UTC, comment #28:
(Sorry -- put comments into the wrong box)
Rich's change seems to fix it for 4.0.2, but 4.10+ (changeset: 21815:418b6066e544 + Rick's diff) still crashes with sig11 on original test script (attached). Dmitri.
|
Fri 03 Jun 2016 12:46:55 AM UTC, comment #27:
I have tested Rik's patch on octave-4.0.2 on Windows 32bit version.
plot_string_error2.m works on patches 4.0.2 but error randomly happens on un-patched 4.0.2.
However, today Julian's test gives random errors on both patched and un-patched 4.0.2. As wrote comment #9:. The test worked at that time without patch.
|
Thu 02 Jun 2016 07:18:35 PM UTC, comment #26:
I have tested a freshly compiled Octave stable version on my laptop. My original test script (post #0) does not produce any errors now! Good. Where as the Octave 4.0.2 release version does throw error messages regularly. (Ubuntu Linux 14.04).
So I can confirm that the mentioned patch solves the original issue of this bug report. (I have not tested Juliens script from comment #4, though.)
|
Thu 02 Jun 2016 04:10:07 PM UTC, comment #25:
I think this is the same issue as the newly reported bug #48081. I'm attaching the script plot_string_error2.m which I used to provoke the error messages for that script. I pushed a small patch to stable that seems to work for me (http://hg.savannah.gnu.org/hgweb/octave/rev/4950810ce605). I'm marking this bug as Ready for Test.
(file #37356)
|
Fri 20 May 2016 11:41:10 AM UTC, comment #24:
I have just finished bisecting on default:
http://hg.savannah.gnu.org/hgweb/octave/rev/b70cc4bd8109
I don't understand how this changeset is related to the random error discussed in this report...
|
Fri 20 May 2016 05:21:14 AM UTC, comment #23:
I am currently trying to bisect the cs that solved the problem on default.
It seems that seems happened somewhere between 20522 and 20732.
The cs proposed by Pantxo (comment #21) was applied after that (21543).
The cs proposed by Avinoam (comment #22) was applied at revision 20698 on stable, and merged at 20742.
So, unless I'm mistaken, it must be something else...
Pehaps this one: http://hg.savannah.gnu.org/hgweb/octave/rev/d0f886a030b7?revcount=20 ?
|
Thu 19 May 2016 08:24:51 PM UTC, comment #22:
Maybe http://hg.savannah.gnu.org/hgweb/octave/rev/a7903de9c359 is related to this bug?
|
Thu 19 May 2016 07:43:20 PM UTC, comment #21:
It doesn't ring a bell here. As it looks like drawnow has an effect I'd try first this changeset:
which essentially forces drawnow between each callback execution.
|
Thu 19 May 2016 05:02:19 PM UTC, comment #20:
Le 19/05/2016 18:39, Dmitri A. Sergatskov a écrit :
> I just tried with the current hg snapshot and the test script kills octave with signal 11 after displaying few plots....
Have you recompiled the MEX-files ?
or
|
Thu 19 May 2016 03:37:32 PM UTC, comment #19:
@Pantxo: do you have any idea of a change that was made on the default branch that might have solved this "random failure" problem with Qt?
|
Thu 19 May 2016 03:23:31 PM UTC, comment #18:
Good answer :)
I only got involved to confirm the bug since it seemed suspicious that some people weren't able to reproduce, now I'll bow out again.
If you do want to try to find where this was fixed, you might ask Pantxo, it looks to me like he's made quite a few fixes for the Qt toolkit and OpenGL in general on the default branch for 4.2.
Here are some mercurial commands to help in narrowing down the search
|
Thu 19 May 2016 03:10:17 PM UTC, comment #17:
> Do you think this is important enough to try to track down the cause and backport a fix on the stable branch?
How would you define "important"?
To me it certainly looks important: Octave 4.0.2 is the current version of Octave, and I have some scripts that look perfectly ok but randomly fail (depending on apparently innocuous details, such as the exact position of a "drawnow" statement).
Even if 4.2.x is released in a few months, there will be systems with 4.0.x installed for several years to come...
So: yes, I believe it is important to backport to stable whichever change solved the problem on default.
|
Thu 19 May 2016 03:01:13 PM UTC, comment #16:
@Mike (comment #13): I can confirm that the problem does not appear in Octave 4.2.x.
|
Thu 19 May 2016 03:00:21 PM UTC, comment #15:
Julien,
I agree with your observation that running the example with --eval yields a higher probability of the script running to completion without error.
The difference between "octave --eval" and "octave-cli --eval" is the absence of the qt toolkit. You said at the start that you didn't see this problem with the fltk toolkit, which is what the default will be with octave-cli.
I ran some more tests with the stable branch (not the same as 4.0.2) and the default branch, and can still confirm that the bug is present only on the stable branch.
Do you think this is important enough to try to track down the cause and backport a fix on the stable branch?
|
Thu 19 May 2016 02:42:54 PM UTC, comment #14:
Some additional observations (on Octave 4.0.2, Debian stretch 64 bits) relative to the example of comment #7, to be confirmed:
- On the one hand, if I run
I obtained random errors in approximately 70% of the runs
- On the other hand, if I run
I never obtain the random errors.
I thought "octave --eval" and "octave-cli --eval" were equivalent (the GUI does not start) but apparently I am wrong (or VERY unlucky).
Can someone confirm this? Please try at least five or ten times in each case, because these random failures are... random...
|
Thu 19 May 2016 02:42:21 PM UTC, comment #13:
I notice that all the people who can reproduce the error are on 4.0.x.
I downloaded the example and tested with both 4.0.2 and default branch on Debian x86_64. I can reproduce on 4.0.2 every time I run example.m, but I can't reproduce on the default branch.
|
Thu 19 May 2016 02:35:40 PM UTC, comment #12:
For reference, here is the thread where some of the results referred to in comment #11 were initially reported:
http://octave.1599824.n4.nabble.com/Please-confirm-bug-46466-tc4677035.html
|
Thu 19 May 2016 02:29:51 PM UTC, comment #11:
Many thanks to all of thos who tried to run my example.
To summarize, the random failures have been observed by:
- myself on Debian strech 64 bits (Octave 4.0.2, system package)
- Dmitri Sergatsov (Octave 4.0.1 on Fedora 23)
- Nicholas Jankowski (Octave 4.0.2, Windows 7, 32 bits, zip install)
But some people have managed to run the same script without seeing any error:
- Tatsuro Matsuoka (Octave 4.0.2 on Windows 10, 32 and 64 bits)
- Ben Abbott (Octave 4.0.1 on Mac OS 10.10.5)
(Doug Stewart has reported has also reported a problem, on Octave dev tip + ubuntu 15.10, but it looks like a different issue...)
CONCLUSION: well... I don't know what to conclude, except that the status of this bug can be set to "Confirmed" ;-)
|
Thu 19 May 2016 12:47:53 PM UTC, comment #10:
Octave 4.0.2 32bit on Windows 7, zip-file install.
|
Thu 19 May 2016 11:00:12 AM UTC, comment #9:
Octave 4.0.2 32 bit on windows 10
Octave 4.0.2 64 bit on windows 10
|
Thu 19 May 2016 10:58:51 AM UTC, comment #8:
Octave 4.0.2 32 bit on windows 10
Octave 4.0.2 64 bit on windows 10
|
Thu 19 May 2016 10:50:11 AM UTC, comment #7:
Here is a second version of my example, without the binaries inside. The MEX-files will be compiled automatically.
(file #37205)
|
Thu 19 May 2016 10:42:13 AM UTC, comment #6:
Oh yes, sorry, I shipped the binary MEX-files...
Just type: "stk_init force_build_mex" to recompile them, after adding the stk* directory to the path.
|
Thu 19 May 2016 10:37:25 AM UTC, comment #5:
I have tried your script on Windows 10.
But I saw
Perhaps I need to re-build mex files for windows.
I could not find the way to do.
|
Wed 18 May 2016 04:37:16 PM UTC, comment #4:
The attached example is causing random errors with Qt in Octave 4.0.4 (Debian stretch, 64bits).
Can someone please try to confirm this ?
You just have to unpack and run example.m (several times, if it doesn't fail the first time).
(file #37202)
|
Tue 17 May 2016 12:12:20 PM UTC, comment #3:
I can confirm (a for of) this problem on Octave 4.0.2, both on
- Linux (debian stretch, both with system package and compiled from stable),
- and Windows 10 (using the official 32bits installer).
I cannot give the full script, and I haven't managed yet to reproduce it with a small example, but I can report the following facts:
- The problem is not strictly reproducible (the error does not always happen at the same moment, and the error message is not always the same).
- The problem happens all the time (really, 100%) with the script I am currently working on...
- The problem happens with a plot (a figure with two subplots, actually) that is inside a loop, after several iterations of the loop.
- The problem does not seem to exist on the default branch.
- The problem only happens with 'qt', not 'fltk' or 'gnuplot'.
- The problem disappears if I insert a drawnow somewhere in the middle of the loop, just after the plots (but NOT if I insert it at the end...)
- The most common error message is: error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown type>' but I sometimes gets other messages
- Sometimes I get only one error, but sometimes I get several errors successively, which is surprising because usually the first error causes the script to stop:
|
Thu 19 Nov 2015 09:45:08 PM UTC, comment #2:
Now, I have also tested the current Octave versions from the repo. I made those tests on Ubuntu Linux. Here are my results:
- The current "default" branch in the repo, does NOT show this bug any more. I wasn't able to provoke those sporadic error messages there :)
- But in the current "stable" branch of the repo, this error DOES still happen. The test script of the original bug post was still able to produce those error messages.
I have no insight into what those two different code branches will be used for. Is the upcoming Octave 4.0.x release going to emerge from the default or from the stable branch? If it will emerge from the stable branch (what my guess would be), would it be possible to include the corresponding fix (it must be somewhere in the default branch) also into the stable branch?
|
Wed 18 Nov 2015 06:51:02 AM UTC, comment #1:
I could reproduce these error with Octave 4.0.0 under windows,
but not with the current dev. branch, even when changing the upper limit of k to 1000.
|
Tue 17 Nov 2015 07:03:42 PM UTC, original submission:
Here is a little script to (quasi reproducibly) show the behavior:
Observation: If you run this script, then there will sometimes be error messages.
This sound kind of non-reproducible, but I had a real application script that produced errors in around 90% of the runs. The above simple demo script only produces errors in around 5% to 10% of the runs, that's why it has the for loop now to better show the bug. This demo script (including the loop) nearly always throws errors on two computers I tested.
This happens with Octave 4.0 under Linux (Ubuntu 14.04) as well as Windows (7). It happens with the CLI version as well as with the GUI. But it only happens with QT plots, FLTK plots and gnuplot plots are fine.
In the following verbatim boxes I will paste some of the error messages I observed. I randomly get different error messages, that's why there are multiple boxes. The script was saved as "bug_plot.m", when those error messages popped up. And maybe the line numbers changed a bit, with respect to the above demo script. But I think it was always a "plot" command in bug_plot.m that triggered the error. Here a some resulting error messages:
error message 1:
error message 2:
error message 3:
error message 4:
error message 5:
error message 6:
error message 7:
|