bugGNU Octave - Bugs: bug #48519, Segfault with Qt plotting when...

 
 

bug #48519: Segfault with Qt plotting when running demos

Submitted by:  Andreas Weber <andy1978>
Submitted on:  Fri 15 Jul 2016 08:38:57 AM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 11 Jan 2019 11:27:48 PM UTC, comment #47:

No complaints so far, I'm closing this report as fixed and crossing it out at https://wiki.octave.org/Bug_Fix_List_-_5.0_Release.

Rik <rik5>
Project Administrator
Mon 07 Jan 2019 10:26:19 AM UTC, comment #46:

Can someone take a look at bug #54187 for which I posted a patch? This is also a case of C++ callbacks causing a crash.

Pantxo Diribarne <pantxo>
Project Member
Sun 06 Jan 2019 10:52:07 PM UTC, comment #45:

I have

  • compiled the latest stable Octave (hg-id bf835b1d04b1), including Pantox's patch and Markus's patch (both directly from the repo). Without any debug symbols this time.
  • I have run 'compare_plot_demos ("toolkits", "qt")' as before, with massivly clicking into the figure windows and moving them around with the mouse.
  • Doing this twice, I could never provoke any crash of Octave any more (before I could).

So this look much better! Thanks for those two patches.

Can anyone else (who observed those crashes before) confirm that this issue is now fully FIXED?

Hartmut <hardy>
Sun 06 Jan 2019 08:12:50 PM UTC, comment #44:

I pushed the patch from comment #32 here:

http://hg.savannah.gnu.org/hgweb/octave/rev/bf835b1d04b1

Pantxo Diribarne <pantxo>
Project Member
Sun 06 Jan 2019 03:53:50 PM UTC, comment #43:

Both bug #55400 and "demo lighting 5" now pass for me as well.

Rik <rik5>
Project Administrator
Sun 06 Jan 2019 02:07:45 PM UTC, comment #42:

Thanks again for testing.
I pushed the change to stable here:
http://hg.savannah.gnu.org/hgweb/octave/rev/dd40f9650821

I don't know whether this was the sole issue this report is about. So I'm leaving the status as is.

Markus Mützel <mmuetzel>
Project Member
Sun 06 Jan 2019 01:57:04 PM UTC, comment #41:

Yes, this patch (applied after bug 5540 patch) solved
"demo lighting 5" crash for me.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 06 Jan 2019 12:22:18 PM UTC, comment #40:

I think I found the issue. The last line of the grid must use the same face normals like the second last line.

Could you please try whether you still see the error after applying the attached diff?

There is also an issue with how face normals are calculated if xdata or ydata are vectors. I hope I can push a patch for this shortly.

(file #45883)

Markus Mützel <mmuetzel>
Project Member
Sun 06 Jan 2019 01:18:30 AM UTC, comment #39:

If I compile w/o qt, I do not get this crash.

I do have a similar crash running
contour3(peaks(19))
See bug 55400 -- it might be completely different issue.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 05 Jan 2019 10:39:31 PM UTC, comment #38:

Confirmed. I can also reproduce with "demo lighting 5" on an unpatched Octave. Simplest example now that segfaults is

Order of execution is important. This does not segfault.

Rik <rik5>
Project Administrator
Sat 05 Jan 2019 05:57:39 PM UTC, comment #37:

FWIW i can reproduce Hartmut's results with

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 05 Jan 2019 05:27:23 PM UTC, comment #36:

Address sanitizer finds neumerous problem with octave (especially with qt and java enabled). So you should either disable docs (which invoces octave) or suppress this particular diagnostics with

See e.g.:
https://github.com/google/sanitizers/wiki/AddressSanitizerFlags

for details.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 05 Jan 2019 05:12:08 PM UTC, comment #35:

I don't see immediately why it fails in these lines.

I tried to replicate (with Pantxo's second patch on top of af7faef288ad). But compiling after:

Fails with:

Am I doing something wrong?
Is it necessary to compile with address-sanitizer-flags to reproduce?

@Hartmut: Does it always fail for you in octave::opengl_renderer::set_normal with the same (or a similar) backtrace like in your comment #33?
(For a backtrace just type "bt" at the gdb prompt.)

Markus Mützel <mmuetzel>
Project Member
Sat 05 Jan 2019 02:45:46 PM UTC, comment #34:

This is starting to look promising. I added Markus to the CC list for the bug since he wrote the lighting and update_normals code. It may be unrelated, but I would at least start there.

Rik <rik5>
Project Administrator
Sat 05 Jan 2019 01:27:04 PM UTC, comment #33:

I have (using gdb for the first time):

  • used Pantxo's second patch (from comment #32)
  • recompiled my Octave version (still hg id 31b0761cd641) with debug symbols (configure FFLAGS=-g CFLAGS=-g CXXFLAGS=-g --enable-address-sanitizer-flags) as explained in the wiki
  • run Octave without GUI (I couldn't interact with the Octave GUI after starting gdb any more): ./run-octave -g
  • gdb> run
  • octave> compare_plot_demos ("toolkits", "qt")
  • moved most of the figure windows around

This resultet in the following "last words" (which might not be a stack trace at all):

Sorry if this is not too helpful. But this is probably as far as I can get with gdb. Currently I don't have the time to dig further into this topic (i.e. using gdb to produce stack traces), and I couldn't find a simple (and working) description how to do this.

Hartmut <hardy>
Fri 04 Jan 2019 07:40:48 AM UTC, comment #32:

I attached an updated version of the patch (that simply removes unused functions).

(file #45862)

Pantxo Diribarne <pantxo>
Project Member
Fri 04 Jan 2019 07:38:42 AM UTC, comment #31:

@Harmut: Thanks for testing. I can't reproduce the second crash and without debug info then it is hard to guess its origin. Do you have debug symbols enabled? If so, can you attach a backtrace?
As for bug #55028, yes it should fix it since the offending callback (Figure::updateBoundingBoxHelper) is not used anymore.

Pantxo Diribarne <pantxo>
Project Member
Thu 03 Jan 2019 10:51:05 PM UTC, comment #30:

I have compiled a current dev version of Octave (hg id 31b0761cd641) with Pantxo's "no callback" patch from comment #29. When I then massivly move the figure windows around during the running of the compare_plot_demos.m script, then I canNOT produce any crash during this plotting, any more. So this patch definitly improves something.

I have tried this twice, and both times Octave still crashed:

  • After my first try, Octave crashed with "signal 11" immediatelly AFTER the script was finished (it only shortly displayed the Octave prompt in the Octave GUI).
  • During my second try, I could make a screenshot of the last "words" on the Octave console, they were:

(the last message was really truncated on my screen, when Octave became unresponsive, an empty figure windows was still open)

Those might be a different "kinds" of crashes, but they are still a crash :(

Does this patch improve bug #55028 (mentioned in comment #27) by the way?

Hartmut <hardy>
Wed 02 Jan 2019 04:46:39 PM UTC, comment #29:

With those additional information, I can reproduce the crash. The issue is that we are passing Figure objects member functions as callbacks to be executed in the interpreter event queue. At the time the callback is executed, the Figure object may not exist anymore, hence the crash. Note that this is in fact the same origin as bug #54187.

I attached a preliminary cset (complicated I admit) that avoids passing such dangerous callback, and fixes the issue for me. It does not fix bug #54187.

(file #45844)

Pantxo Diribarne <pantxo>
Project Member
Tue 01 Jan 2019 04:04:19 PM UTC, comment #28:

(as a reply to comment #22 and comment #23:)
I have tried some more times to reproduce this crahs of Octave. Here are my observations:

  • When I don't touch my PC during the running compare_plot_demos.m script, then I do NOT get any crash. (This fits to the observation of Pantxo in comment #22.)
  • When I move the popping up figure windows around with my mouse once in a while (because I try to read some news page in my browser meanwhile), then I still DO get this crash. (This fits to the observations of Andreas in comment #25.)
  • When I set LIBGL_ALWAYS_SOFTWARE (as suggested by Dmitri in comment #23), and move some figure windows around, then I still DO get those crashes. So this LIBGL_ALWAYS_SOFTWARE does NOT change the behavior for me.

Note: I am using Qt version 5.9.5 for this (in Octave 5.0.xxx). So my Qt version is new enough and it should not still have the Qt bug mentioned in comment #26. (The Qt webpage claims to have fixed this in 5.9.4)

Hartmut <hardy>
Sun 30 Dec 2018 08:44:50 PM UTC, comment #27:

See also bug #55028 where Michael Godfrey reports the same segfault.

Andreas Weber <andy1978>
Project Member
Sun 30 Dec 2018 05:12:04 PM UTC, comment #26:

Perhaps this Qt bug? https://bugreports.qt.io/browse/QTBUG-63844

Andreas Weber <andy1978>
Project Member
Sun 30 Dec 2018 04:36:20 PM UTC, comment #25:

Meanwhile I'm able to trigger this within seconds moving the window by hand or per xdotool.

file doit.m

And I call it with

Andreas Weber <andy1978>
Project Member
Sun 30 Dec 2018 03:29:25 PM UTC, comment #24:

I'm able to reproduce this with a current build of stable with a stripped dump_plot_demos.m (see attachments)

It can take up to 30mins until I see the segfault:

see backtrace.log for full backtrace but without debugging symbols. I'll du a debug build next

(file #45790, file #45791)

Andreas Weber <andy1978>
Project Member
Wed 26 Dec 2018 07:03:00 PM UTC, comment #23:

Also a usual suggestion to set software renderer

LIBGL_ALWAYS_SOFTWARE=1 octave

etc...

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 26 Dec 2018 11:25:18 AM UTC, comment #22:

@hardy: I can't reproduce, all files are properly created. To be honest my desktop environment becomes unusable during the process (figure widgets keep popping up and taking the focus over any other window in my OS). Can you add some more comments on the crash you are seeing: is there a specific demo on which the crash happens or does it crash randomly? Can you paste here typical error messages (the "malloc" one for example)? Can you try to run the attached modified script (images are then printed using a single invisible figure)?

(file #45741)

Pantxo Diribarne <pantxo>
Project Member
Sun 23 Dec 2018 07:28:08 PM UTC, comment #21:

I STILL see this crash with Octave 5.0.1 (hg-id 9644c0b7efd8), self compiled on Ubuntu 18.04, when running 'compare_plot_demos ("toolkits", "qt")' from the scripts/testfun/private dir".

I've seen different ways of crashing:

  • Some lines of error messages, including "malloc" on the Octave console, freezing Octave. And "octave exited with signal 9" on the linux console.
  • A full crash of Octave, the GUI dissappearing. And "octave exited with signal 11" on the linux console.

Conclusion: This bug is still alive :(

Hartmut <hardy>
Sun 23 Dec 2018 04:15:21 PM UTC, comment #20:

@Hartmut: See comment #0, "compare_plot_demos ("toolkits", "qt")' from the scripts/testfun/private dir".

Try this

To run it

Rik <rik5>
Project Administrator
Sat 22 Dec 2018 10:03:02 PM UTC, comment #19:

Where can I find the "run_plot_demo" scripts today, in order to try reproducing this behavior?

Hartmut <hardy>
Thu 19 Jan 2017 05:37:31 AM UTC, comment #18:

change report status to "In Progress", according to comment #17

Avinoam Kalma <avinoam>
Project Member
Wed 21 Sep 2016 12:44:33 AM UTC, comment #17:

I am still getting crashes on machines with with NVidia and AMD cards (as of 4.2.0-rc2). Crashes are intermittent but it looks like the situation gets worse if I LD_PRELOAD multithreaded openblas library. At least once instead of crash octave hanged on
ghostscript making zoom1.png (I killed it after ~20 minutes).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 22 Aug 2016 09:46:44 PM UTC, comment #16:

So I changed dump_plot_demos_2.m so it save hold_06.eps instead of png. No crash but file is corrupted (attached).

Dmitri.
--

(file #38322)

Dmitri A. Sergatskov <dasergatskov>
Mon 22 Aug 2016 09:39:22 PM UTC, comment #15:

With changeset: 22361:a12f11e20c75
I have crashes on computers with AMD and NVIDIA cards
(no crash on i7 with intel graphics).
After applying lachlan's patch still crash on nvidia (I have not tried others):

The crash is due to ghostscript. It looks like it gets a corrupted input file from gl2ps.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 22 Aug 2016 05:15:19 PM UTC, comment #14:

@Dmitri: Does the crash go away if you apply Lachlan's original fix in file 37907?

Rik <rik5>
Project Administrator
Mon 22 Aug 2016 05:04:38 PM UTC, comment #13:

The crash has gone away for me after Andy pushed the second fix mentioned in comment #11. But, there is clearly still an instability that depend on exact hardware and software versions.

Rik <rik5>
Project Administrator
Sun 21 Aug 2016 05:09:30 AM UTC, comment #12:

I still get crash running dump_plot_demos_2:

At least once it froze at the same hold_06 demo instead of a crash. It is not 100% reproducible: if I restart after the crash it tends to go through and finish the script, but if I delete all hold_*.png files and restart it crashes at hold_06
with fairly high reproducibility.

changeset: 22348:9deb86bb5632

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 20 Aug 2016 07:06:21 AM UTC, comment #11:

I've pushed http://hg.savannah.gnu.org/hgweb/octave/rev/2e49ab3d6b48 which should prevent the segfault (but of course doesn't solve the timing problems in the first place)

Andreas Weber <andy1978>
Project Member
Wed 17 Aug 2016 10:39:53 PM UTC, comment #10:

What if you change in ObjectProxy.cc

but I think this is also only a workaround. ObjectProxy::update shouldn't be called before a valid object is set, right?

Andreas Weber <andy1978>
Project Member
Wed 17 Aug 2016 04:44:15 PM UTC, comment #9:

Unfortunately, this still crashes for me as well.

It is fairly repeatable in stopping at axis demo #3. This is a demo that contains 9 subplots so there is going to be a lot of work by the graphics system as it initially places the 9 subplots and then adjusts the positioning slightly as titles are added.

Steps to reproduce

I experimented with adding back in the small delay in graphics.cc that allows for the print routine to grab the mutex on the graphics object. The value that was there before was .05 (50 milliseconds). That definitely helped, but it is not a cure. I experimented with delays up to 1 second, but I still occasionally get segfaults.

Rik <rik5>
Project Administrator
Wed 17 Aug 2016 08:17:08 AM UTC, comment #8:

It still crashes for me as of

changeset: 22326:71dd9d5a5ecd
bookmark: @
tag: tip
user: John W. Eaton <jwe@octave.org>
date: Wed Aug 17 02:57:50 2016 -0400
summary: move more new classes inside octave namespace

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 17 Aug 2016 06:04:48 AM UTC, comment #7:

Pantxo's fix from #44463
http://hg.savannah.gnu.org/hgweb/octave/rev/fc127f0e1ccd

Fixes the segfault for me.

@Dmitri: can you confirm it's fixed on fc127f0e1ccd?

Andreas Weber <andy1978>
Project Member
Wed 17 Aug 2016 12:06:12 AM UTC, comment #6:

I used Andreas Weber

http://josoansi.de/dump_plot_demos_1.m
http://josoansi.de/dump_plot_demos_2.m

and they both coredump of two computers I tried.
Then I modify the scripts by adding 1 sec delay
in front of every tic ();
After that I was able to finish both scripts on
both computers w/o obvious problems.

Looks like some race condition on GL buffer?

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 16 Aug 2016 08:55:57 PM UTC, comment #5:

Marking as confirmed. I used 'dump_demos' to create 'dump_plot_demos.m'. I then ran

The dump_plot_demos script really stresses the graphics system and quickly led to segfaults. It could be software versions. I'm using Qt5.4. I'll try the ObjectProxy fix from Lachlan later.

Rik <rik5>
Project Administrator
Fri 29 Jul 2016 01:07:43 PM UTC, comment #4:

Still present with 8971508e21c8
(I was hoping that e68128601f5e solved this)
@Pantxo: Sorry: forgot to test your patch, I'll do it soon

Andreas Weber <andy1978>
Project Member
Sun 17 Jul 2016 04:35:17 PM UTC, comment #3:

I can't reproduce the bug either but it may have to do with bug #44463, for which the current workaround may not always work. You may want to try the last patch I attached there, I think it is more robust than the current workaround.

Pantxo Diribarne <pantxo>
Project Member
Sun 17 Jul 2016 12:09:50 PM UTC, comment #2:

Hi Lachlan. Your patch clearly avoids the segfault but it looks to me like a workaround for a deeper problem.

The problem is triggered if the previous parameters are restored after "print". I've added some debug output to stdout

which gives before the segfault:

I'm doubt it's in intended that ObjectProxy::init ist called with both obj=0 and m_object=0. This whole QtHandles backend is a unfathomable beast for me...

Andreas Weber <andy1978>
Project Member
Sat 16 Jul 2016 03:19:36 AM UTC, comment #1:

I've tried to reproduce this, and don't seem to be able to.

Thanks for providing a stack trace. That really helps. You can see that slotUpdate is being called on a NULL object. That means the bug must be in QtHandles::ObjectProxy::update or earlier. It seems that ObjectProxy::init is not being called to set m_object.

Can you see if the attached changeset makes a difference?

There are several Qt bugs that are system dependent. One thing you could do to debug it is to look for the other problems with Qt and see if your system reproduces any of them.

(My guess is that this is different, because those crashes were often in the OpenGL drivers and this in in Octave code, but it is something to try.)

(file #37907)

Lachlan Andrew <lachlan>
Fri 15 Jul 2016 08:38:57 AM UTC, original submission:

hg id c8abb2ba4017

This bug is not deterministic and happened with "demo axis", "demo pbaspect" and "demo light"(see below). Perhaps it's some race condition which happens if you make a lot plots in a sequence. In my case I've used 'compare_plot_demos ("toolkits", "qt")' from the scripts/testfun/private dir which basically makes "demo xyz, print demo xyz2, print..."

Is there anything I can do to help debug this?

Andreas Weber <andy1978>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45883:  bug48519_heap-buffer-overflow.diff added by mmuetzel (2KiB - application/octet-stream)
file #45862:  no_callback2.patch added by pantxo (10KiB - text/x-patch)
file #45844:  no_callback.patch added by pantxo (8KiB - text/x-patch)
file #45790:  backtrace.log added by andy1978 (7KiB - text/x-log)
file #45791:  dump_plot_demos.m added by andy1978 (982B - text/x-objcsrc)
file #45741:  dump_plot_demos.m added by pantxo (358KiB - text/x-objcsrc)
file #38322:  hold_06.eps added by dasergatskov (168KiB - application/postscript)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by avinoam (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by lachlan (Updated the item)
  • -email is unavailable- added by andy1978 (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-11 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2019-01-06 mmuetzel Attached File- => Added bug48519_heap-buffer-overflow.diff, #45883
    2019-01-05 rik5 Carbon-Copy- => Added mmuetzel
    2019-01-04 pantxo Attached File- => Added no_callback2.patch, #45862
    2019-01-02 cdf Dependencies- => bugs #55268 is dependent
    2019-01-02 pantxo Attached File- => Added no_callback.patch, #45844
        StatusIn Progress => Patch Submitted
    2018-12-30 andy1978 Attached File- => Added backtrace.log, #45790
        Attached File- => Added dump_plot_demos.m, #45791
    2018-12-26 pantxo Attached File- => Added dump_plot_demos.m, #45741
    2017-01-19 avinoam StatusReady For Test => In Progress
    2016-08-22 dasergatskov Attached File- => Added hold_06.eps, #38322
    2016-08-17 andy1978 StatusConfirmed => Ready For Test
    2016-08-16 rik5 StatusNone => Confirmed
    2016-07-16 lachlan Attached File- => Added bug_48519_qt_invalid_proxy.cset, #37907

    Back to the top


    Powered by Savane 3.4