Thu 16 Jan 2014 04:57:08 PM UTC, comment #15:
I had to rebuild because earlier I removed FLTK from the build.
But I did so, and indeed, ./run-octave -cli with native graphics works fine. I do get these warnings occasionally, but that's it:
|
Thu 16 Jan 2014 04:54:31 PM UTC, comment #14:
Since this is a duplicate of bug #40242, let's continue the discussion over there.
|
Thu 16 Jan 2014 04:47:58 PM UTC, comment #13:
You you should not have to rebuild. I can't remember the option that must be passed to run-octave, but you always have the option to install octave (make install) and launch "octave-cli" (that will be in the bin directory of your install path).
|
Thu 16 Jan 2014 04:41:27 PM UTC, comment #12:
OK, I understand better now that ./run-octave does not automatically select the cli build unless I ask for it. To test cli/fltk I will have to rebuild, and I will do that.
|
Thu 16 Jan 2014 03:35:13 PM UTC, comment #11:
Ah, that's good to know, but since fltk seems problematic on both, perhaps the default toolkit should be gnuplot for both.
|
Thu 16 Jan 2014 03:20:51 PM UTC, comment #10:
Oops, I forgot that octave --no-gui and use
of fltk are incompatible on OS X.
It seems a bit boring, but maybe the graphics_toolkit
setup code should check for system type and not allow
fltk on OS X if executing octave, not octave-cli.
|
Thu 16 Jan 2014 02:57:19 PM UTC, comment #9:
The "--no-gui" option in run-octave runs octave (and thus fltk graphics toolkit) in a second thread, after launching a QApplication in the mains thread. This implies gui operations (graphics) in another thread than the main one, which is not allowed on apple platform.
Sorry for insisting: in order to test pure cli, with octave and fltk in the main thread, you have to install and launch octave-cli binary. If this is what you did there is a regression: fltk used to work in pure cli mode.
|
Thu 16 Jan 2014 02:35:48 PM UTC, comment #8:
I may not have my terminology right, but this occurs in both GUI and CLI mode with native graphics. I've switched over to gnuplot though and it is fine for me. I will ensure that the Homebrew formula uses gnuplot until this can be nailed down.
|
Thu 16 Jan 2014 02:31:23 PM UTC, comment #7:
AFAICS, this is a duplicate of [1]. I am even surprised that the crash does not occur immediately at the first figure. With the "--no-gui" option, the problem is expected to remain, but not in cli mode.
[1]https://savannah.gnu.org/bugs/?40242
|
Thu 16 Jan 2014 02:02:53 AM UTC, comment #6:
The fact that it appears from the assertion error
that it is a locking problem is also not a surprise.
At least one bit of information to think about.
|
Thu 16 Jan 2014 01:57:06 AM UTC, comment #5:
I'm honestly not surprised. I certainly understand that debugging these things is not trivial. There's a reason, I'm sure, that the Mac binary builds use gnuplot!
If it's remotely useful to anyone, if I quit before a segfault, I often get this assertion error:
|
Thu 16 Jan 2014 01:52:35 AM UTC, comment #4:
Michael,
I just tried several scripts which did
lots of figure(k) calls, using devel
system on fedora 20 x86_64.
After hundreds of calls, with and without drawnow()'s,
I could not cause any problem.
So, this could be an OS X specific problem.
Sorry.
Could anyone else with an OS X system try some tests?
|
Thu 16 Jan 2014 01:30:02 AM UTC, comment #3:
I am pretty sure that drawnow is called from
figure(), but...
What happens if you follow each figure() by a
drawnow()?
Experience on Linux machines is that fltk plotting
is much more stable than gnuplot, and quicker.
The gnuplot pipe mechanism becomes a problem if you
try to output a long (like 30-40) series of complex plots.
Something gets comfused and the plots become incorrect.
Your mileage may differ on OS X.
|
Thu 16 Jan 2014 12:34:16 AM UTC, comment #2:
Yes, I'm using fltk. I suppose 41216 could be related, but do note I'm not actually attempting to use printing here---indeed I can get this without even creating a plot, just by calling figure(1), figure(2), ... etc. (though not necessarily reliably).
Without more direct instructions on how this might be traced I will be unable to do so. This is going to have to go to the folks who have experience building this GUI.
In the meanwhile it's clear we'll have to stick with gnu plot for Mac OS, which is fine.
|
Thu 16 Jan 2014 12:23:07 AM UTC, comment #1:
First, are you using gnuplot of fltk?
This may be another manifestation of some
malfunction, possibly a race condition,
associated with drawnow.
The most recent bug report on this is 41216,
but there have been quite a few others.
There was a time when this problem seemed to have
"gone away" but I do not think a precise fix was
ever found. So, it appears to be back as expected.
If you look into this you will find that the
drawnow related flow of control is fairly hard to
follow.
Good luck!
|
Wed 15 Jan 2014 10:49:48 PM UTC, original submission:
I'm running the gui-release build here, and I can cause Octave to segfault periodically simply by using the figure() command. I also see interesting behavior where the first figure window is initially rendered upside down (screenshot attached); that behavior is far more consistent.
I basically do this:
If it doesn't crash after the first three or four figures, I quit and try again. Sometimes quitting itself will do it.
This happens, by the way, with the "--no-gui" setting.
Look at Thread 9 of the crash dump; it seems that's where the crash is triggered, by what looks to be some sort of drawnow-like command. I'm not the most skilled lldb user out there but I can try and get more debug information if that's helpful.
|