bugGNU Octave - Bugs: bug #54920, AutoScale in xscale = log mode may...


bug #54920: AutoScale in xscale = log mode may lead to an unexpected error

Submitted by:  Lynn quam <lhquam>
Submitted on:  Tue 30 Oct 2018 05:02:45 PM UTC  
Category:  Plotting with OpenGL Severity:  4 - Important
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Fixed Assigned to:  None
Originator Name:  LH Quam 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)

Wed 09 Jan 2019 08:07:53 AM UTC, comment #27:

I pushed this a simple change that fixes the issue:


The problem was that we were performing an "unzoom" as part of the autoscale process.

Pantxo Diribarne <pantxo>
Project Member
Tue 01 Jan 2019 02:55:05 AM UTC, comment #26:

I went back before changeset 26277 and the leak is still there so it is not related to Pantxo's changes to the notify routine.

Rik <rik5>
Project Administrator
Mon 31 Dec 2018 05:36:18 AM UTC, comment #25:

I compiled with ASAN to look for memory leaks and I'm finding this 8-byte leak repeated multiple times.

I haven't verified yet by going back before changeset 26277:e92a44730a6e, but it looks related to this report.

Rik <rik5>
Project Administrator
Mon 31 Dec 2018 04:40:52 AM UTC, comment #24:

Since this no longer causes a crash, and I don't think there is time to do much on the remaining issue before the 5.0 release, I propose to mark this as won't fix on the bug fix list at https://wiki.octave.org/Bug_Fix_List_-_5.0_Release#Bugs_with_severity_.3E.3D_4.

Rik <rik5>
Project Administrator
Fri 21 Dec 2018 05:04:21 PM UTC, comment #23:

Thanks, I pushed the patch on stable:


Now we can concentrate on the original issue which is that in certain conditions triggerring an autoscale from the GUI leads to an error, while in the same situation "axis auto" works as expected from the command line.

Updating the title, the item group and the release.

Pantxo Diribarne <pantxo>
Project Member
Thu 20 Dec 2018 10:10:26 PM UTC, comment #22:

No objection from me. Thanks.

John W. Eaton <jwe>
Project Administrator
Thu 20 Dec 2018 08:16:26 PM UTC, comment #21:

@jwe: Do you have an objection to pushing this change which will prevent Octave own exceptions from crashing the GUI?

Pantxo Diribarne <pantxo>
Project Member
Mon 05 Nov 2018 07:22:12 PM UTC, comment #20:

On a related note, see bug #54953. It is possible to create figures which can't be closed because there is an exception during the creation of the figure object. Probably the creation code needs to be wrapped in a try/catch in C++ which closes the partially constructed figure if the application of properties with set(xxx,yyy) fails.

Rik <rik5>
Project Administrator
Mon 05 Nov 2018 05:06:50 PM UTC, comment #19:

I'm leaving this for jwe to review.

Rik <rik5>
Project Administrator
Fri 02 Nov 2018 09:49:22 PM UTC, comment #18:

I attached a patch. With this approach we will still probably need to catch exceptions here and there (e.g. after printing we want to do some cleanup), but it will at least avoid hard crashes.

(file #45350)

Pantxo Diribarne <pantxo>
Project Member
Fri 02 Nov 2018 06:34:09 PM UTC, comment #17:

Pantxo: That looks promising. Thanks. Do you want to create a proper changeset for this? If not, or if you don't have time, I will work on it but it may take a few days.

John W. Eaton <jwe>
Project Administrator
Fri 02 Nov 2018 01:09:13 PM UTC, comment #16:

@jwe: I tried the approach that post people recommend for exception handling in qt, which is overloading QApplication and reimplementing the "notify" method. For this bug I get good results.

The change I made is

And the result I get is

Pantxo Diribarne <pantxo>
Project Member
Fri 02 Nov 2018 09:53:41 AM UTC, comment #15:

@jwe: Yes, you are right, and we are back at handling exceptions locally with try/catch blocks.

Pantxo Diribarne <pantxo>
Project Member
Fri 02 Nov 2018 09:27:08 AM UTC, comment #14:

Sorry if it's unrelated but would the discussed changes also allow to display the stack trace when an error occurs in GUI callback? Currently, one only gets:

which makes it hard to debug.

Guillaume <gyom>
Thu 01 Nov 2018 06:57:17 PM UTC, comment #13:

Panxto: I started thinking about your suggestion a bit more and I'm wondering just how it would work. Suppose some code running in the GUI thread calls a function that results in a call to Octave's error function. With your suggested change, the error function would determine that it was not running in the interpreter thread call octave_link function that would ultimately call error again, but in the interpreter thread. That part I can understand working, but then what happens in the GUI thread? Presumably we are in a situation where we should not continue because there was an error, but how do we detect that?

John W. Eaton <jwe>
Project Administrator
Wed 31 Oct 2018 09:22:05 PM UTC, comment #12:

There appear to be two separate problems:

1) The (lack of) error handling in the graphics thread causing the process to abort.

2) The problem triggered by AutoScale

error: set: "cameratarget" must be finite

What is wrong with the state of the axis transform parameters
due to change to the transform before switching to log mode?

Lynn quam <lhquam>
Wed 31 Oct 2018 05:03:49 PM UTC, comment #11:

Panxto: thanks for the suggestion. Yes, we could try that and if it works, then it seems like a much better solution than trying to use tr/catch blocks around every possible call to "error". Also, I've been wondering whether printing the message immediately is the correct thing to do, or whether we should be accumulating information in an exception object, then using that information when needed. That way, I think we would have better control over what happens with error messages when implementing something like "debug_on_error".

John W. Eaton <jwe>
Project Administrator
Wed 31 Oct 2018 04:47:45 PM UTC, comment #10:

@jwe: Would it be possible to make the "error" function thread safe instead. AFAIU this function first prints the message to stderr and then throws an appropriate exception. Would it be difficult to check in which thread the function is being called and if it is not the interpreter thread use the octave_link to put the error call in the interpreter event queue so that it is handled correctly.

For graphics we currently workaround the issue by using try/catch and octave_link::post_exception (which basically rethrows the exception in the interpreter thread). This has the disadvantage that we must put try/catch blocks in every sensible place (where "error" could be called).

Pantxo Diribarne <pantxo>
Project Member
Wed 31 Oct 2018 03:29:22 AM UTC, comment #9:

Rik: Yes, I think you are correct. It doesn't happen for fltk because the toolbar action for autoscale is executed as a callback to the Octave interpreter. You can see that this approach also works for the qt toolkit by using the autoscale item in the tools menu instead of the autoscale button.

I can fix this by wrapping the actions in try/catch blocks. There are probably other places where these problems could happen and we could attempt handle them all individually. But this seems like a difficult thing to do since there are probably many actions that call functions from the interpreter could potentially result in an error.

Also, should the be implemented using an Octave ui object as they are with the fltk plotting window?

John W. Eaton <jwe>
Project Administrator
Wed 31 Oct 2018 01:21:24 AM UTC, comment #8:

Here is a backtrace. It confirms my suspicions in comment #7. The interesting part begins with the double-click event (#22) which causes an auto-scale of the axes.

Rik <rik5>
Project Administrator
Wed 31 Oct 2018 01:15:50 AM UTC, comment #7:

When Octave crashes I am getting the following output:

One plausible hypothesis is that the validation on the set command (add_constraint in graphics.in.h) is throwing an error. And then Octave is experiencing the familiar problem that an error in one thread (say the GUI) is not caught by the exception handler in the main thread and so the whole program aborts.

Rik <rik5>
Project Administrator
Wed 31 Oct 2018 01:03:38 AM UTC, comment #6:

I have tested the sequence of actions that the original reporter documented. I experienced a segfault with version 4.4.1, octave-stable, and the development version of Octave. Marking bug as confirmed.

Rik <rik5>
Project Administrator
Wed 31 Oct 2018 01:02:12 AM UTC, comment #5:

My problem on the dev branch was fixed by jwe. See https://hg.savannah.gnu.org/hgweb/octave/rev/9618c2f96e7a. Apparently, just a typo.

Rik <rik5>
Project Administrator
Tue 30 Oct 2018 07:08:49 PM UTC, comment #4:

@jwe: go ahead. I have to work on other things this afternoon.

Rik <rik5>
Project Administrator
Tue 30 Oct 2018 07:07:25 PM UTC, comment #3:

The issue I reported in comment #1 is probably different. I filed a separate bug report about that as bug #54923.

Rik <rik5>
Project Administrator
Tue 30 Oct 2018 07:05:07 PM UTC, comment #2:

Rik: I will take a look at this unless you want to work on it.

John W. Eaton <jwe>
Project Administrator
Tue 30 Oct 2018 06:39:13 PM UTC, comment #1:

I have a similar segfault on the development branch of Octave

Steps to reproduce:

I get the following messages on stderr

If I run with the FLTK toolkit I get

but at least Octave does not segfault.

Rik <rik5>
Project Administrator
Tue 30 Oct 2018 05:02:45 PM UTC, original submission:

The following code demonstrates a bug that crashes Octave 4.4.1 on Fedora-27 X86-64.
graphics_toolkit is qt.

The following steps consistently crashes Octave with signal-6:
1. Run crash_bug ().
2. Select a rectangular window in plot using mouse, OR "Pan" the plot.
3. Click on 'logx' toggle button to switch to 'xscale' = 'log' mode.
4. AutoScale the plot by clicking middle-mouse button or double-click.

It appears that any mouse actions that change the plot-to-window transform while 'xscale' = 'linear' will cause problems when the axes are switches to 'xscale' = 'log' mode, and then autoscale_axes is called.

The following sequence DOES NOT cause Octave to crash:

1. Run crash_bug ().
2. Click on 'logx' toggle button to switch to 'xscale' = 'log' mode.
3. Zoom, Pan, or Autoscale the plot.
4. Click on 'logx' toggle button to switch to 'xscale' = 'linear' mode.
5. Autoscale the plot
6. Click on 'logx' toggle button to switch to 'xscale' = 'log' mode.
7. Zoom, Pan, or Autoscale the plot.
8. ...

If Zoom or Pan are not invoked while 'xscale' = 'linear', everything works fine
switching between 'log' and 'linear' modes and doing Zoom, Pan, or Autoscale in 'log' mode.

Lynn quam <lhquam>


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

Attach Files:

Attached Files
file #45350:  gui_exceptions.patch added by pantxo (4KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by gyom (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by lhquam (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-01-11 pantxo StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2019-01-09 pantxo StatusConfirmed => Ready For Test
    2018-12-21 pantxo Item GroupSegfault, Bus Error, etc. => Unexpected Error
        Release4.4.1 => dev
        Summarysigabrt (signal-6) crash with AutoScale in xscale = log mode => AutoScale in xscale = log mode may lead to an unexpected error
    2018-11-02 pantxo Attached File- => Added gui_exceptions.patch, #45350
    2018-11-02 pantxo CategoryPlotting => Plotting with OpenGL
    2018-10-31 rik5 StatusNone => Confirmed
    2018-10-30 rik5 Severity3 - Normal => 4 - Important

    Back to the top

    Powered by Savane 3.4