Tue 31 Jan 2017 05:17:35 PM UTC, comment #13:
Leaving bug #50198 as the definitive issue report for cross-thread error problems. CLosing this report.
|
Tue 31 Jan 2017 04:29:55 PM UTC, comment #12:
Unknown devices are now handled differently and this bug can't be reproduced anymore. Should we close it as "fixed" even if the root cause is still not fixed (see bug #50198)?
|
Fri 07 Oct 2016 11:28:17 PM UTC, comment #11:
For FLTK --no-gui flag, I now get pretty much the same as what you report, except perhaps you have more error messages.
Good hypothesis on your part. I've recompile with this change:
and the segfault is gone:
So, I recompile again with just this change:
and get segfault again. With this change
I see "warning: broken pipe" a hundred plus times. That seems backward to me, but it's beside the point. The call to error() is the problem, as you surmised.
|
Fri 07 Oct 2016 10:42:51 PM UTC, comment #10:
The test code now works for me if I use the cli version of Octave and fltk (no qt).
The issue seems to have changed. The problem now is that throwing an error when there are multiple threads (interpreter thread and qt thread) seems to cause a segfault. This may be because the thrown error is captured by the wrong thread which does not have an error handler set up.
The message when using FLTK is
versus this when using qt.
|
Sat 04 Apr 2015 10:43:52 AM UTC, comment #9:
Now I think about it, I have overlooked the mutex mechanism: the construct in the diff I provided doesn't ensure that "Canvas::print" will have locked the mutex before Fdrawnow tries to.
So this is not the proper way to ensure sequential operation across threads. It only ensures that "Canvas::print" will have to be completed before it is called again.
|
Sat 04 Apr 2015 10:21:13 AM UTC, comment #8:
As explained in bug #44463, I could check that the gh_manager::lock/unlock mechanism doesn't seem to work. As I understand it should work as a cross thread mutex.
I attached a diff in which I tried to follow who lock and unlock the gh_manager: I don't know if I should trust the order in which the callers are printed on screen (due to possible threading issues) but here is the result I see in the terminal when I paste Rick's script:
In normal operation I would expected something like:
(file #33531)
|
Mon 30 Mar 2015 04:30:58 PM UTC, comment #7:
Still reproducible for me. This is on Linux Mint 13 at cset 19995:185e8dbdaa40. Maybe try running with the '-f' switch to make sure there isn't anything in your .octaverc which might influence the result.
|
Sat 28 Mar 2015 11:05:53 AM UTC, comment #6:
I can't reproduce the error in comment #5: for me the figure color is reset to its original value. This is with a recent dev build on linux mint. Can some confirm that this bug is still present?
|
Tue 03 Mar 2015 09:05:11 PM UTC, comment #5:
Here is a sample piece of code that illustrates the problem
So it is clear that when an error occurs we are not restoring the plot to its original state. This is probably because error() short-circuits running the normal end-of-print routines.
It probably means we need to have any code that might fail in a try/catch block or in an unwind_protect statement so that errors are cleaned up afterwards.
Actually, check out print.m.
This is in an unwind_protect statement. So, maybe there is some reason why the restore code is not working.
In fact, I just did a bunch of insertions of printf statements into print.m and lots of them do not seem to be executed after I use a function which calls into the C++ graphics code such as ishandle() or set().
|
Tue 03 Mar 2015 07:20:51 PM UTC, comment #4:
Here's a related example from https://savannah.gnu.org/bugs/?44406#comment6, but it isn't bogus device, instead typing Cntrl-C while the printing is taking place.
|
Sun 01 Mar 2015 06:09:11 PM UTC, comment #3:
https://savannah.gnu.org/bugs/?44400 is unrelated to this bug.
|
Sun 01 Mar 2015 04:09:59 PM UTC, comment #2:
I posted another bug #44400 that may be related to this one.
|
Sat 28 Feb 2015 05:21:38 AM UTC, comment #1:
That's the new Qt toolkit running in the CLI. It's a day or two old in Mercurial so I'm sure there are new issues with it.
|
Sat 28 Feb 2015 04:45:37 AM UTC, original submission:
When a print is done when FLTK graphics toolkit is operating, I notice that the background of the plot will go haywire momentarily. I think if an error happens to occur while FLTK window is in that state, the window stays in that state. I've attached an example plot window after running the following:
|