bugGNU Octave - Bugs: bug #45540, Segfault when moving the mouse...

 
 

bug #45540: Segfault when moving the mouse over Qt figures

Submitter:  Michael Godfrey <godfrey>
Submitted:  Mon 13 Jul 2015 11:29:47 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:  Godfrey Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 26 Sep 2015 09:34:35 AM UTC, comment #37: 

I pushed the last patch I had proposed in comment #29. It happened to also fix bug #46053.

Closing report.

Pantxo Diribarne <pantxo>
Group Member
Tue 08 Sep 2015 10:05:45 AM UTC, comment #36: 

Pantxo: Yes, this is all correct. Sorry for the confusion.
I think that a new bug report may be best. #45863 originally
reported from a system that had other symptoms (gnuplot
did not work all).

In any case, handle this in the way that you think is best.
You are (thanks very much) doing the work!!

Thanks,
Michael

Michael Godfrey <godfrey>
Group Member
Tue 08 Sep 2015 09:52:18 AM UTC, comment #35: 

Ok so I think there is a misunderstanding: the patches I have brought up to now are supposed to act only on mouse tracking mechanism (when hovering the figure with mouse), not on selection mechanism (when clicking).

So here is my proposition: any crash that involves a click (not simply hovering) on a Qt figure is not relevant for this bug and should be tracked in another bug report, either bug #45863 or a brand new one. This is how this bug was initially reported ("no mouse click") and also consistent with the title ("moving the mouse over figure"). Is it ok?

Pantxo Diribarne <pantxo>
Group Member
Tue 08 Sep 2015 09:26:23 AM UTC, comment #34: 

I believe that what I said is correct. I had to click on the
figure as soon as it showed up and multiple times. As
you can see, graphics_toolkit said 'qt'.

The earlier part of the dump is attached as
qt_seg_faultfirst_part.gdb


(file #34834)

Michael Godfrey <godfrey>
Group Member
Tue 08 Sep 2015 07:26:22 AM UTC, comment #33: 

Are you sure you posted the good back-trace? AFAICS, the one in comment #32 is using Qt (QtHandles::Canvas...) and select mode (GLCanvas::selectFromAxes) which has no reason to happen unless you clicked in the canvas.

Pantxo Diribarne <pantxo>
Group Member
Tue 08 Sep 2015 12:14:09 AM UTC, comment #32: 

Here is a bt of a crash run using:
./run-octave -g --silent --no-gui

This is a standard build of the devel, no -g

qt_seg_fault.gdb

Hope it helps anyhow.

One mystery: when running under gdb the seg fault seems only
to happen if the toolkit is fltk.


(file #34831)

Michael Godfrey <godfrey>
Group Member
Mon 07 Sep 2015 07:10:25 PM UTC, comment #31: 

Can you attach a back-trace of the crash? As the one you attached in comment #23 does not contain very useful info, I suspect you don't have debug symbols enabled.

Here is the nasty way I use to produce back-traces with the gui:

  • build default Octave with debug symbols:

$ ./configure CXXFLAGS="... -g -O0"; make

  • run gdb on octave-gui binary directly:

$ gdb ./src/.libs/octave-gui

  • then in gdb run Octave and produce the backtrace after the crash:

$ run
...
$ bt

Pantxo Diribarne <pantxo>
Group Member
Mon 07 Sep 2015 06:35:15 PM UTC, comment #30: 

Pantxo: I installed your patch, but sorry to say I get:
[godfrey@pbdsl4 octave]$ oct

>> graphics_toolkit('qt')
>> plot(1:2000)
>> panic: Segmentation fault -- stopping myself...

attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault (core dumped)

If I wait until Figure is drawn all is OK.

Michael Godfrey <godfrey>
Group Member
Mon 07 Sep 2015 05:38:42 PM UTC, comment #29: 

Ok, I was able to reproduce the segfault by forcing Octave to take time to draw, using the following script and hovering the figure with mouse:


figure
theta = 0:0.01:2*pi;
rho = (sin(3*theta)).^2;
for ii = 1:20
polar(theta,rho);
end


The attached patch fixes the bug for

(file #34830)

Pantxo Diribarne <pantxo>
Group Member
Thu 03 Sep 2015 10:39:31 PM UTC, comment #28: 

Pantxo: I think that #45863 is different from this report.
#45863 reports the qt crashes unconditionally and gnuplot
does not work at all. This is quite different from this report.

Maybe both should be left open. Or, if you prefer, a new
report describing the qt crash if the figure is clicked
on while it has not been full drawn should be opened.
This would focus on the problem that exists on my system.
And, this report, which started with a different problem,
could be closed.

Finally, there is some chance that #45348 is related to this
problem. In any case, it is another serious defect with the
current OpenGL graphics.

So, tell me, or just open it if you want a new report for the
current problem on this report.


Michael Godfrey <godfrey>
Group Member
Thu 03 Sep 2015 08:55:13 PM UTC, comment #27: 

Michael should I close this report (about simply moving the mouse over the canvas)? If so could you post the available back-traces in bug #45863 (or a link to this report).

Pantxo Diribarne <pantxo>
Group Member
Thu 03 Sep 2015 01:48:00 PM UTC, comment #26: 

@Pantxo: When I said that before I was not aware of the
difference between clicking while the figure was being
rendered and waiting. Now, if I wait qt does not crash
after using fltk. But, if I use fltk (to draw and then close
the polar plot) and then use qt, but click while
rendering, qt crashes. But, for some odd reason, it
does not produce the bt. It just says:

>> mesa_fltk_mouse
>> mesa_fltk_mouse
>> mesa_qt_mouse
>> panic: Segmentation fault -- stopping myself...

attempting to save variables to 'octave-workspace'...
Segmentation fault (core dumped)

Michael Godfrey <godfrey>
Group Member
Thu 03 Sep 2015 11:07:13 AM UTC, comment #25: 

@Michael: you wrote in your original report that the segfault didn't happen if you first ran fltk before trying to use qt. Is it also true now that clicking is needed to trigger the segfault?

Pantxo Diribarne <pantxo>
Group Member
Thu 03 Sep 2015 10:49:06 AM UTC, comment #24: 

So AFAIU moving the mouse over the figure is no more an issue right? If so this report can be closed and we can discuss the remaining issue in bug #45863.

The problem may still be related to GL_SELECT mode: as explained in comment #7 clicking on the figure will trigger the object selection mechanism in order to be able to honor buttonxxxfcn.

Pantxo Diribarne <pantxo>
Group Member
Thu 03 Sep 2015 10:06:51 AM UTC, comment #23: 

@Pantxo,

OK. Here is what definitely happens on my Fedora22
system:

I run the script:

graphics_toolkit('qt')
theta = 0:0.01:2*pi;
rho = (sin(3*theta)).^2;
polar(theta,rho);


1. I wait until the figure is completed.  No problem

2. As soon as the figure appears I move the cursor over the
   figure but do not click any mouse buttons. No problem.

3. As soon as the figure appears I move the cursor over
   the figure and click on a mouse button. BT is
   attached as mesa_qt_dump.


(file #34802)

Michael Godfrey <godfrey>
Group Member
Wed 02 Sep 2015 11:11:05 PM UTC, comment #22: 

It was actually bug #45863 I was talking about.

I am reopening the report. The patch I pushed didn't fix the issue.

Pantxo Diribarne <pantxo>
Group Member
Wed 02 Sep 2015 11:01:28 PM UTC, comment #21: 

Well, I tried again and it failed. I think the
reason is that this time I moved the cursor over the
figure as it was being drawn.

The crash output is attached.

This is all I can do tonight.


(file #34799)

Michael Godfrey <godfrey>
Group Member
Wed 02 Sep 2015 10:54:24 PM UTC, comment #20: 

I just reran the test:
(copy paste from history)

graphics_toolkit('qt')
theta = 0:0.01:2*pi;
rho = (sin(3*theta)).^2;
polar(theta,rho);
quit


And it ran just fine! I cannot explain why it crashed
earlier today. I have made no changes to my system or Octave
since the test that failed.

Michael Godfrey <godfrey>
Group Member
Wed 02 Sep 2015 10:23:49 PM UTC, comment #19: 

@Pantxo

I am using the same graphics (Intel HD 6000 in a NUC5i5RYH
box) as before.

For,

grep -rl "if (xlim(0) < p0(0) && xlim(1) > p0(0)" ./libgui/
I get
./libgui/graphics/Canvas.cc


I will try to discover why the patch worked when I applied it
manually (before it was pushed as you say) but does not now.

By the way, did you mean bug #45683? This does not seem
relevant...

Michael Godfrey <godfrey>
Group Member
Wed 02 Sep 2015 09:33:16 PM UTC, comment #18: 

The patch I pushed was supposed to fix a very intensive use of GL_SELECT mechanism (while hovering a window with the mouse)  introduced by this cset:

http://hg.savannah.gnu.org/hgweb/octave/rev/062422f2e399

... which in turn is on default. So the "fix" (more of a workaround) I pushed is completely tied to default.
As bug #45683 is against 4.0, I suppose we should now find the root cause of the segfault. Maybe some hardware specific driver issue.

@Michael: are you using the same family of graphics card as mentioned in bug #45683 ? What does a grep in the source tree return, e.g.:


grep -rl "if (xlim(0) < p0(0) && xlim(1) > p0(0)" ./libgui/


Pantxo Diribarne <pantxo>
Group Member
Wed 02 Sep 2015 08:00:06 PM UTC, comment #17: 

It appears to me that the patch mentioned below
was never pushed. The devel branch still seg faults
on my system.

Michael Godfrey <godfrey>
Group Member
Wed 02 Sep 2015 06:55:04 PM UTC, comment #16: 

Should the fix have been pushed to stable rather than the development branch?  Generally anything which causes a segfault is worthy of being pushed to stable.  There is a new bug report, bug #45683, which is a possible duplicate of this bug but it appears with version 4.0.0.

Rik <rik5>
Group administrator
Mon 31 Aug 2015 10:07:34 PM UTC, comment #15: 

Finally, as getting rid of the cast would involve many more changes, I pushed the patch with only a sligh mod:

http://hg.savannah.gnu.org/hgweb/octave/rev/2d415c68213f

Closing report.

Pantxo Diribarne <pantxo>
Group Member
Mon 27 Jul 2015 05:50:48 AM UTC, comment #14: 

OK, sounds good.  Enjoy the break.

Dan Sebald <sebald>
Sun 26 Jul 2015 10:29:51 AM UTC, comment #13: 

I'll rework the patch in a few weeks (I'll be in vacations) and eventually transform the QList<graphics_object> into a QList<axes> (checking with graphics_object::isa method that we indeed store an axes object) so that cast is no more needed.

Pantxo Diribarne <pantxo>
Group Member
Sun 26 Jul 2015 09:18:29 AM UTC, comment #12: 

A graphics_object is a generic (proxy) class that only features the base_graphics_object methods. axes, figure ... are derivatives classes of base_graphics_object that have more properties and methods. Properties can be accessed from graphics_object using the generic "get" method, but specific methods (like pixels2coord) can't. Hence the need for cast. See [1-2] for a general overview.

Now about the fact that the warning disappeared, it is expected as we don't use GL_SELECT anymore for retrieving mouse coordinates. On the other hand, to handle the "buttondownfcn" property (function that is called when a specific object is clicked) or "uicontextmenu" the selection mechanism is needed, hence clicking triggers the overflow warning.

[1] http://octave.org/doxygen/4.0/d0/d37/classgraphics__object.html
[2] http://octave.org/doxygen/4.0/dc/d22/classbase__graphics__object.html

Pantxo Diribarne <pantxo>
Group Member
Sat 25 Jul 2015 04:58:05 PM UTC, comment #11: 

Could the dynamic_cast be removed from this somehow?  (Looking around the source tree just now my guess is the answer is "not easily".):


+      for (QList<graphics_object>::ConstIterator it = axesList.begin ();
+           it != axesList.end (); ++it)
+        {
+          const axes::properties& ap =
+            dynamic_cast<const axes::properties&> ((*it).get_properties ());
+


That looks a little dodgy.  Or is this the generic way of handling graphics objects?  Presumably if something is on the axesList it is in fact an axes object and the cast is safe.  Another approach would be to use an iterator that is an axes object rather than the more generic graphics object.  C++ constructs exist to avoid this kind of casting, but it seems a big change.

Well, going back to the original comment, it does appear that _init_fltk_ does do a lot of work with axes properties.  A grep for "axes::properties" produces a mound of hits including:


grep "axes::properties" */*/*
[snip]
libinterp/dldfcn/__init_fltk__.cc:        axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:          dynamic_cast<axes::properties&>(ax_obj.get_properties ());
libinterp/dldfcn/__init_fltk__.cc:            axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:              dynamic_cast<axes::properties&>(go.get_properties ());
libinterp/dldfcn/__init_fltk__.cc:        axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:          dynamic_cast<axes::properties&> (ax.get_properties ());
libinterp/dldfcn/__init_fltk__.cc:        axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:          dynamic_cast<axes::properties&> (ax.get_properties ());
libinterp/dldfcn/__init_fltk__.cc:        axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:          dynamic_cast<axes::properties&> (ax.get_properties ());
libinterp/dldfcn/__init_fltk__.cc:                      axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:                        dynamic_cast<axes::properties&>
libinterp/dldfcn/__init_fltk__.cc:                    axes::properties& ap =
libinterp/dldfcn/__init_fltk__.cc:                      dynamic_cast<axes::properties&> (ax.get_properties ());
libinterp/dldfcn/__init_fltk__.cc:                          axes::properties& ap = dynamic_cast<axes::properties&>


Also, the behavior from this patch changes slightly what is happening in https://savannah.gnu.org/bugs/?45604 .  No longer does hovering over the dense set of points produce the warning:


warning: opengl_selector::select: selection buffer overflow


That warning now only appears when I position the cursor above the pixels where the dense data is and select using the left mouse button.  I will write a note at that bug report and see if the patch fixes the crash problem for the Windows user.  If not, there may still be an initialization issue.

Dan Sebald <sebald>
Sat 25 Jul 2015 11:50:13 AM UTC, comment #10: 

The patch works just fine for me;
fedora 22 x86_64 Intel NUC5i5RYH
with HD 6000 graphics.

Definitely recommend pushing this patch.

I will also tell the mesa folks.

Michael Godfrey <godfrey>
Group Member
Sat 25 Jul 2015 11:31:11 AM UTC, comment #9: 

I attached a preliminary patch that avoids using the GL_SELECT mechanism when we are only looking for axes objects.
AFAICS it works for me but does it avoid the crash for those who see it ?

(file #34517)

Pantxo Diribarne <pantxo>
Group Member
Fri 24 Jul 2015 08:26:15 PM UTC, comment #8: 

The backtrace: you can see how many things are involved with the opengl call.  Took me a long time to build all the tools needed for the driver before I could debug some things in swrast.

Anyway, the comments I made about


warning: opengl_selector::select: selection buffer overflow


here https://savannah.gnu.org/bugs/?45604#comment7 pertain to the technique described in comment #7.  Basically, with a very dense plot, the Select mode can overflow.  If as you describe, only the axes hover is important, the warning message could be removed because an overflowing Select mode isn't a concern--you just want to know if there is activity there, which an overflow inherently indicates.

There might be some technique whereby a bogus object the size of the axes is put on the screen and all the other objects do not cause select events (but if ever the day comes where the dream scenario of hand-decorating plots is reality then individual object selection is of interest).  But, in principle opengl is indicating selection which is what is wanted, albeit verbosely.  My suspicion is that this is a threading issue.  From what I've seen of this Qt plotting, it hasn't had the semaphore protection necessary from keeping threads from conflicting with one another.  I'm guessing opengl events are in one thread, Octave core in another, GUI maybe another.

Dan Sebald <sebald>
Fri 24 Jul 2015 11:23:47 AM UTC, comment #7: 

In order to display the cursor coordinates, I needed to know what axes was hovered. I used the object selection mechanism that was already in place in Qt.
The routine (selectFromAxes) is called extensively (each time a mouse movement is detected over the canvas by Qt) and involves switching to Select mode, drawing fake objects, switching to Render mode and then redrawing the canvas. This is probably overkill since we only need to know the axes that is hovered, not the objects it contains.

I don't know how it is done in fltk but a much simpler method would be: retrieving the position of all axes in the figure, transforming those in pixel units and comparing with current mouse event coordinates.


Pantxo Diribarne <pantxo>
Group Member
Fri 24 Jul 2015 09:31:05 AM UTC, comment #6: 

Maybe a fact would help. bt is attached.
The Mesa folks are looking at it and they
indicated that they may have a problem.
But, it must be something unique to qt since fltk
does not show the problem.

This indicates that it could help if qt and fltk
were brought closer together.


(file #34501)

Michael Godfrey <godfrey>
Group Member
Fri 24 Jul 2015 05:07:23 AM UTC, comment #5: 

It's not certain that the opengl driver is seg-faulting.  It could be, but at the same time it might be that Octave is getting some bogus pointer value or error message back from the opengl call and then doesn't react accordingly and segfaults.  This


panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault (core dumped)


is the Octave seg-fault catch message.  That in itself doesn't indicate where the segfault is occurring.

Anyway, from bug https://savannah.gnu.org/bugs/index.php?45604 I found an issue with a warning message appearing under opengl/Qt, but as I wrote I concluded it isn't related to this bug.  Read my explanation in the other bug thread if you like.

Dan Sebald <sebald>
Sat 18 Jul 2015 10:15:17 PM UTC, comment #4: 

By the way, I reported this problem to the Mesa bug site,
since while it is most likely an Octave bug, Mesa
should not cause a seg fault.

Michael Godfrey <godfrey>
Group Member
Fri 17 Jul 2015 08:43:18 AM UTC, comment #3: 

I've been doing loads of plotting with qt lately and never hit this bug, but that was with lines / patches that have "coordinates".

Indeed, as soon as I try to "plot" (imshow) something (.jpg, .png pictures) w/o clear coordinates I get a segfault on Windows.
So Pantxo's guess that it is related to mouse coordinates display seems to make sense.

OS -> "Any"

Philip Nienhuis <philipnienhuis>
Group Member
Thu 16 Jul 2015 09:03:42 AM UTC, comment #2: 

Hi,

I would look first in the recent changes I brought in order to have mouse coordinates displayed in Qt figures (http://hg.savannah.gnu.org/hgweb/octave/rev/062422f2e399).
I did see crashes when moving the mouse over figures during development stages but it never happened to me after polishing the patch, so I pushed it.
Unfortunately, I most probably won't be able to work on this during the coming month.
Marking the bug "confirmed" even though I can't confirm it myself, and retitling to better describe the bug.

Pantxo Diribarne <pantxo>
Group Member
Mon 13 Jul 2015 12:30:43 PM UTC, comment #1: 

I have also seen graphics_toolkit('qt') crash when moving the mouse pointer over the window.
I will try and repeat it and post more info here.
Doug

Doug Stewart <dastew>
Mon 13 Jul 2015 11:29:47 AM UTC, original submission:  

The segfault sometimes says:

>> graphics_toolkit('qt')
>> plot(1:100)
>> Mesa 10.6.1 implementation error: invalid target in _swrast_choose_texture_sample_func
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
Mesa 10.6.1 implementation error: invalid target in _swrast_choose_texture_sample_func
Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa
panic: Segmentation fault -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Segmentation fault (core dumped)


octave-4.0.0 does not seg fault. And, I think that
fairly recent builds were OK.

And, the crash only occurs if the mouse is moved
to the plot window. (No mouse click is needed for crash)

Additional plotting can be done from the
command line.

I will try to learn more, but cannot right away.

Important: graphics_toolkit('fltk') still works.
And, I just did:

>> graphics_toolkit

ans = fltk

>> plot(1:100)
>> graphics_toolkit('qt')
>> plot(1:100)
>>

which then worked OK. So, the problem has something
to do with initialization. If fltk is used first
then qt works.

Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34834:  qt_seg_faultfirst_part.gdb added by godfrey (14KiB - application/octet-stream)
file #34831:  qt_seg_fault.gdb added by godfrey (6KiB - application/octet-stream)
file #34830:  check_fig.patch added by pantxo (2KiB - text/x-diff)
file #34802:  mesa_qt_dump added by godfrey (24KiB - application/octet-stream)
file #34799:  mesa_new_fail added by godfrey (3KiB - application/octet-stream)
file #34517:  no_select_45540.patch added by pantxo (3KiB - text/x-diff)
file #34501:  qt_seg_fault_bt added by godfrey (16KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by godfrey (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-09-26 pantxo StatusNone Fixed
        Open/ClosedOpen Closed
    2015-09-08 godfrey Attached File- Added qt_seg_faultfirst_part.gdb, #34834
    2015-09-08 godfrey Attached File- Added qt_seg_fault.gdb, #34831
    2015-09-07 pantxo Attached File- Added check_fig.patch, #34830
    2015-09-03 godfrey Attached File- Added mesa_qt_dump, #34802
    2015-09-02 pantxo StatusFixed None
        Open/ClosedClosed Open
    2015-09-02 godfrey Attached File- Added mesa_new_fail, #34799
    2015-08-31 pantxo StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2015-07-27 pantxo StatusConfirmed In Progress
    2015-07-25 pantxo Attached File- Added no_select_45540.patch, #34517
    2015-07-24 godfrey Attached File- Added qt_seg_fault_bt, #34501
    2015-07-17 philipnienhuis Operating SystemGNU/Linux Any
    2015-07-16 pantxo StatusNone Confirmed
        Summarygraphics_toolkit(\'qt\') segfaults on plot(1:100) Segfault when moving the mouse over Qt figures

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code