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

 
 

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

Submitter:  Lynn quam <lhquam>
Submitted:  Tue 30 Oct 2018 05:02:45 PM UTC
   
 
Category:  Plotting with OpenGL Severity:  4 - Important
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  LH Quam Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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:

hg.savannah.gnu.org/hgweb/octave/rev/7bf8036ad3f6

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

Pantxo Diribarne <pantxo>
Group 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>
Group 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.


Direct leak of 8 byte(s) in 1 object(s) allocated from:
    #0 0x7f7b612ea458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f7b5f233601 in octave::type_info::register_type(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, octave_value const&, bool) libinterp/octave-value/ov-typeinfo.cc:154
    #2 0x7f7b5f31f312 in octave_uint8_matrix::register_type(octave::type_info&) libinterp/octave-value/ov-uint8.cc:68
    #3 0x7f7b5f27ae9d in install_types(octave::type_info&) libinterp/octave-value/ov.cc:2937
    #4 0x7f7b5f232279 in octave::type_info::type_info(int) libinterp/octave-value/ov-typeinfo.cc:82
    #5 0x7f7b5fc3d01b in octave::interpreter::interpreter(octave::application*) libinterp/corefcn/interpreter.cc:384
    #6 0x7f7b5e56f581 in octave::application::create_interpreter() libinterp/octave.cc:314
    #7 0x7f7b60be93f2 in octave::octave_interpreter::execute() libgui/src/main-window.cc:115
    #8 0x7f7b60db9be4 in octave::octave_interpreter::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) libgui/src/moc-main-window.cc:89
    #9 0x7f7b591ac121 in QObject::event(QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Core.so.5+0x2ba121)
    #10 0x7f7b59efa82b in QApplicationPrivate::notify_helper(QObject*, QEvent*) (/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5+0x15482b)


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

Rik <rik5>
Group 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>
Group administrator
Fri 21 Dec 2018 05:04:21 PM UTC, comment #23: 

Thanks, I pushed the patch on stable:

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

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>
Group Member
Thu 20 Dec 2018 10:10:26 PM UTC, comment #22: 

No objection from me.  Thanks.

John W. Eaton <jwe>
Group 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>
Group 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>
Group administrator
Mon 05 Nov 2018 05:06:50 PM UTC, comment #19: 

I'm leaving this for jwe to review.

Rik <rik5>
Group 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>
Group 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>
Group 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


--- a/libgui/src/main-window.cc Mon Feb 22 21:07:09 2016 +0100
+++ b/libgui/src/main-window.cc Fri Nov 02 14:04:27 2018 +0100
@@ -2766,7 +2766,7 @@
     // Even if START_GUI is false, we still set up the QApplication so
     // that we can use Qt widgets for plot windows.

-    m_qt_app = new QApplication (m_argc, m_argv);
+    m_qt_app = new octave_qapplication (m_argc, m_argv);

     // set windows style for windows
 #if defined (Q_OS_WIN32)
@@ -3012,4 +3012,18 @@
                                              const QString&, const QString&,
                                              const QString&)));
   }
+
+  bool
+  octave_qapplication::notify (QObject *receiver, QEvent *ev)
+  {
+   try
+     {
+       return QApplication::notify (receiver, ev);
+     }
+   catch (octave::execution_exception& e)
+     {
+       octave_link::post_exception (std::current_exception ());
+     }
+   return false;
+  }
 }
diff -r e3a2ef3dced9 libgui/src/main-window.h
--- a/libgui/src/main-window.h  Mon Feb 22 21:07:09 2016 +0100
+++ b/libgui/src/main-window.h  Fri Nov 02 14:04:27 2018 +0100
@@ -490,6 +490,19 @@
     bool m_connect_to_web;
   };

+  class octave_qapplication : public QApplication
+  {
+  public:
+
+    octave_qapplication (int& argc, char **argv)
+    : QApplication (argc, argv)
+    { }
+
+    virtual bool notify (QObject *receiver, QEvent *e) override;
+
+    ~octave_qapplication (void) { };
+  };
+


And the result I get is


octave:3> crash_bug
octave:4> error: set: "cameratarget" must be finite
error: parse error
octave:4>


Pantxo Diribarne <pantxo>
Group 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>
Group 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:


>> error: function: error message
execution error in graphics callback function


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


#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f92c8412801 in __GI_abort () at abort.c:79
#2  0x00007f92c8a678b7 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007f92c8a6da06 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007f92c8a6da41 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007f92c8a6dc74 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007f92cac334bd in error_1(octave::execution_exception &, std::ostream &, const char *, const char *, const char *, typedef __va_list_tag __va_list_tag *, bool) (e=..., os=..., name=0x7f92cb0639bd "error", id=0x7f92cb06383c "", fmt=0x7f92cb0682cf "set: \"%s\" must be finite",
    args=0x7ffe7e7cce30, with_cfn=false) at libinterp/corefcn/error.cc:548
#7  0x00007f92cac335a0 in error_1(std::ostream &, const char *, const char *, const char *, typedef __va_list_tag __va_list_tag *, bool) (
    os=..., name=0x7f92cb0639bd "error", id=0x7f92cb06383c "", fmt=0x7f92cb0682cf "set: \"%s\" must be finite", args=0x7ffe7e7cce30,
    with_cfn=false) at libinterp/corefcn/error.cc:558
#8  0x00007f92cac335fb in verror (fmt=0x7f92cb0682cf "set: \"%s\" must be finite", args=0x7ffe7e7cce30) at libinterp/corefcn/error.cc:564
#9  0x00007f92cac336ac in error (fmt=0x7f92cb0682cf "set: \"%s\" must be finite") at libinterp/corefcn/error.cc:572
#10 0x00007f92cacbbd22 in array_property::validate (this=0x7f92945a1610, v=...) at libinterp/corefcn/graphics.cc:1514
#11 0x00007f92cade8d5d in array_property::do_set (this=0x7f92945a1610, v=...) at libinterp/corefcn/graphics.h:1454
#12 0x00007f92cade953f in row_vector_property::do_set (this=0x7f92945a1610, v=...) at libinterp/corefcn/graphics.h:1562
#13 0x00007f92cacb9746 in base_property::set (this=0x7f92945a1610, v=..., do_run=true, do_notify_toolkit=true)
    at libinterp/corefcn/graphics.cc:1172
#14 0x00007f92cade9418 in row_vector_property::operator= (this=0x7f92945a1610, val=...) at libinterp/corefcn/graphics.h:1542
#15 0x00007f92cada83be in axes::properties::update_camera (this=0x7f929459fde0) at libinterp/corefcn/graphics.cc:5710
#16 0x00007f92cadf26b0 in axes::properties::update_transform (this=0x7f929459fde0) at libinterp/corefcn/graphics.h:4677
#17 0x00007f92cadc3ebb in axes::properties::unzoom (this=0x7f929459fde0) at libinterp/corefcn/graphics.cc:8901
#18 0x00007f92cadc43c4 in axes::properties::clear_zoom_stack (this=0x7f929459fde0, do_unzoom=true) at libinterp/corefcn/graphics.cc:8945
#19 0x00007f92a02382da in QtHandles::autoscale_axes (ap=...) at libgui/graphics/Canvas.cc:264
#20 0x00007f92a023bac2 in QtHandles::Canvas::canvasMousePressEvent (this=0x563cd1b2a7c0, event=0x7ffe7e7cde30) at libgui/graphics/Canvas.cc:728
#21 0x00007f92a023ab2d in QtHandles::Canvas::canvasMouseDoubleClickEvent (this=0x563cd1b2a7c0, event=0x7ffe7e7cde30)
    at libgui/graphics/Canvas.cc:564
#22 0x00007f92a024f357 in QtHandles::GLCanvas::mouseDoubleClickEvent (this=0x563cd1b2a790, xevent=0x7ffe7e7cde30)
    at libgui/graphics/GLCanvas.cc:216
#23 0x00007f92c74b194f in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#24 0x00007f92c747282c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#25 0x00007f92c747a64f in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#26 0x00007f92c66f49a8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x00007f92c7479622 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#28 0x00007f92c74cc14b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#29 0x00007f92c74ce7ba in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#30 0x00007f92c747282c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#31 0x00007f92c747a0f4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#32 0x00007f92c66f49a8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#33 0x00007f92c6cb66c0 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#34 0x00007f92c6cb7ff5 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#35 0x00007f92c6c8f2eb in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#36 0x00007f92b35ab1c0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
---Type <return> to continue, or q <return> to quit---
#37 0x00007f92beeac287 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#38 0x00007f92beeac4c0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#39 0x00007f92beeac54c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#40 0x00007f92c674d8ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#41 0x00007f92c66f29ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#42 0x00007f92c66fba84 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#43 0x00007f92cb7bb3db in octave::octave_qt_app::exec (this=0x7ffe7e7ce670) at libgui/src/main-window.cc:2853
#44 0x00007f92cb7cdfda in octave::gui_application::execute (this=0x7ffe7e7ce730) at libgui/src/octave-gui.cc:64
#45 0x0000563ccfac78a1 in main (argc=10, argv=0x7ffe7e7cea48) at src/main-gui.cc:103



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

When Octave crashes I am getting the following output:


error: set: "cameratarget" must be finite
terminate called after throwing an instance of 'octave::execution_exception'
fatal: caught signal Aborted -- stopping myself...
Abort (core dumped)


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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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:


graphics_toolkit qt
demo semilogx 3
# Choose Pan tool and pan graph


I get the following messages on stderr


octave:2> error: set: "xlim" must not be nan
terminate called after throwing an instance of 'octave::execution_exception'
fatal: caught signal Aborted -- stopping myself...
Abort (core dumped)


If I run with the FLTK toolkit I get


octave:3> error: set: "xlim" must not be nan
error: parse error
octave:3> error: set: "xlim" must not be nan
error: parse error
octave:3> error: set: "xlim" must not be nan
error: parse error


but at least Octave does not segfault.


Rik <rik5>
Group 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.


function crash_bug ()
  xdata = (0:10);
  figure('toolbar','figure');
  uicontrol('style', 'togglebutton', 'string', "logx",...
            'units','normalized', 'position', [.01,.9,.1,.05],...
            'callback', @logx_callback);
  axes('units', 'normalized', 'position', [.1,.1,.8,.7]);
  line(xdata, xdata);
  zoom('on');
endfunction

function logx_callback (h)
  if get(h,'value')
    set(gca(), 'xscale', 'log');
  else
    set(gca(), 'xscale', 'linear');
  endif
endfunction


Lynn quam <lhquam>

 

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

Attach Files:
   
   
Comment:
   

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

    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 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 or Warning
        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.13-cf05.
    Corresponding source code