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

Closing report.

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?

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.

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

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)

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).

@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,

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)

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)

@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...

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

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.

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.

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.

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)

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.

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.

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"

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