bugGNU Octave - Bugs: bug #41244, Segfault using the figure() command

 
 

bug #41244: Segfault using the figure() command

Submitted by:  Michael C. Grant <mcgrant>
Submitted on:  Wed 15 Jan 2014 10:49:48 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Duplicate Assigned to:  None
Originator Name:  Michael C. Grant Open/Closed:  Closed
Release:  3.8.0 Operating System:  Mac OS

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)

Thu 16 Jan 2014 04:57:08 PM UTC, comment #15: 

I had to rebuild because earlier I removed FLTK from the build.

But I did so, and indeed, ./run-octave -cli with native graphics works fine. I do get these warnings occasionally, but that's it:

2014-01-16 10:56:11.003 octave-cli[2946:d0f] CoreText performance note: Client called CTFontCreateWithName() using name "Arial" and got font with PostScript name "ArialMT". For best performance, only use PostScript names when calling this API.

Michael C. Grant <mcgrant>
Thu 16 Jan 2014 04:54:31 PM UTC, comment #14: 

Since this is a duplicate of bug #40242, let's continue the discussion over there.

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
Thu 16 Jan 2014 04:47:58 PM UTC, comment #13: 

You you should not have to rebuild. I can't remember the option that must be passed to run-octave, but you always have the option to install octave (make install) and launch "octave-cli" (that will be in the bin directory of your install path).

Pantxo Diribarne <pantxo>
Project Member
Thu 16 Jan 2014 04:41:27 PM UTC, comment #12: 

OK, I understand better now that ./run-octave does not automatically select the cli build unless I ask for it. To test cli/fltk I will have to rebuild, and I will do that.

Michael C. Grant <mcgrant>
Thu 16 Jan 2014 03:35:13 PM UTC, comment #11: 

Ah, that's good to know, but since fltk seems problematic on both, perhaps the default toolkit should be gnuplot for both.

Michael C. Grant <mcgrant>
Thu 16 Jan 2014 03:20:51 PM UTC, comment #10: 

Oops, I forgot that octave --no-gui and use
of fltk are incompatible on OS X.

It seems a bit boring, but maybe the graphics_toolkit
setup code should check for system type and not allow
fltk on OS X if executing octave, not octave-cli.

Michael Godfrey <godfrey>
Project Member
Thu 16 Jan 2014 02:57:19 PM UTC, comment #9: 

The "--no-gui" option in run-octave runs octave (and thus fltk graphics toolkit) in a second thread, after launching a QApplication in the mains thread. This implies gui operations (graphics) in another thread than the main one, which is not allowed on apple platform.

Sorry for insisting: in order to test pure cli, with octave and fltk in the main thread, you have to install and launch octave-cli binary. If this is what you did there is a regression: fltk used to work in pure cli mode.

Pantxo Diribarne <pantxo>
Project Member
Thu 16 Jan 2014 02:35:48 PM UTC, comment #8: 

I may not have my terminology right, but this occurs in both GUI and CLI mode with native graphics. I've switched over to gnuplot though and it is fine for me. I will ensure that the Homebrew formula uses gnuplot until this can be nailed down.

Michael C. Grant <mcgrant>
Thu 16 Jan 2014 02:31:23 PM UTC, comment #7: 

AFAICS, this is a duplicate of [1]. I am even surprised that the crash does not occur immediately at the first figure. With the "--no-gui" option, the problem is expected to remain, but not in cli mode.

[1]https://savannah.gnu.org/bugs/?40242

Pantxo Diribarne <pantxo>
Project Member
Thu 16 Jan 2014 02:02:53 AM UTC, comment #6: 

The fact that it appears from the assertion error
that it is a locking problem is also not a surprise.

At least one bit of information to think about.

Michael Godfrey <godfrey>
Project Member
Thu 16 Jan 2014 01:57:06 AM UTC, comment #5: 

I'm honestly not surprised. I certainly understand that debugging these things is not trivial. There's a reason, I'm sure, that the Mac binary builds use gnuplot!

If it's remotely useful to anyone, if I quit before a segfault, I often get this assertion error:

2014-01-15 19:56:27.881 octave-gui[3853:240b] *** Assertion failure in -[NSThemeFrame lockFocus], /SourceCache/AppKit/AppKit-1265/AppKit.subproj/NSView.m:7041
2014-01-15 19:56:27.881 octave-gui[3853:240b] unlockFocus called too many times. Called on <NSThemeFrame: 0x7f8232f85c70>.
2014-01-15 19:56:27.882 octave-gui[3853:240b] -[NSThemeFrame(0x7f8232f85c70) lockFocus] failed with window=0x7f82345029f0, windowNumber=549, [self isHiddenOrHasHiddenAncestor]=0
2014-01-15 19:56:27.891 octave-gui[3853:240b] (
        0   CoreFoundation                      0x00007fff8cb7c41c __exceptionPreprocess + 172
        1   libobjc.A.dylib                     0x00007fff8c88de75 objc_exception_throw + 43
        2   CoreFoundation                      0x00007fff8cb7c1f8 +[NSException raise:format:arguments:] + 104
        3   Foundation                          0x00007fff8cd83c61 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 189
        4   AppKit                              0x00007fff9301ec6d -[NSView lockFocus] + 233
        5   AppKit                              0x00007fff9301cbf4 -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 1271
        6   AppKit                              0x00007fff92ffc63a -[NSView displayIfNeeded] + 1680
        7   AppKit                              0x00007fff9306189e _handleWindowNeedsDisplayOrLayoutOrUpdateConstraints + 884
        8   AppKit                              0x00007fff93635cd1 __83-[NSWindow _postWindowNeedsDisplayOrLayoutOrUpdateConstraintsUnlessPostingDisabled]_block_invoke1331 + 46
        9   CoreFoundation                      0x00007fff8caad0a7 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
        10  CoreFoundation                      0x00007fff8caad017 __CFRunLoopDoObservers + 391
        11  CoreFoundation                      0x00007fff8ca9e7b8 __CFRunLoopRun + 776
        12  CoreFoundation                      0x00007fff8ca9e275 CFRunLoopRunSpecific + 309
        13  HIToolbox                           0x00007fff95f8ef0d RunCurrentEventLoopInMode + 226
        14  HIToolbox                           0x00007fff95f8eb85 ReceiveNextEventCommon + 173
        15  HIToolbox                           0x00007fff95f8eabc _BlockUntilNextEventMatchingListInModeWithFilter + 65
        16  AppKit                              0x00007fff92ec528e _DPSNextEvent + 1434
        17  AppKit                              0x00007fff92ec48db -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
        18  AppKit                              0x00007fff92eb89cc -[NSApplication run] + 553
        19  QtGui                               0x0000000111cad037 _ZN19QEventDispatcherMac13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE + 519
        20  QtCore                              0x00000001118dc6e7 _ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE + 79
        21  QtCore                              0x00000001118dc84a _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE + 346
        22  QtCore                              0x00000001118df4f9 _ZN16QCoreApplication4execEv + 199
        23  liboctgui.0.dylib                   0x000000010d47d463 _Z16octave_start_guiiPPcb + 351
        24  libdyld.dylib                       0x00007fff951f65fd start + 1
        25  ???                                 0x0000000000000009 0x0 + 9
)

Michael C. Grant <mcgrant>
Thu 16 Jan 2014 01:52:35 AM UTC, comment #4: 

Michael,

I just tried several scripts which did
lots of figure(k) calls, using devel
system on fedora 20 x86_64.

After hundreds of calls, with and without drawnow()'s,
I could not cause any problem.

So, this could be an OS X specific problem.

Sorry.

Could anyone else with an OS X system try some tests?

Michael Godfrey <godfrey>
Project Member
Thu 16 Jan 2014 01:30:02 AM UTC, comment #3: 

I am pretty sure that drawnow is called from
figure(), but...

What happens if you follow each figure() by a
drawnow()?

Experience on Linux machines is that fltk plotting
is much more stable than gnuplot, and quicker.
The gnuplot pipe mechanism becomes a problem if you
try to output a long (like 30-40) series of complex plots.
Something gets comfused and the plots become incorrect.

Your mileage may differ on OS X.

Michael Godfrey <godfrey>
Project Member
Thu 16 Jan 2014 12:34:16 AM UTC, comment #2: 

Yes, I'm using fltk. I suppose 41216 could be related, but do note I'm not actually attempting to use printing here---indeed I can get this without even creating a plot, just by calling figure(1), figure(2), ... etc. (though not necessarily reliably).

Without more direct instructions on how this might be traced I will be unable to do so. This is going to have to go to the folks who have experience building this GUI.

In the meanwhile it's clear we'll have to stick with gnu plot for Mac OS, which is fine.

Michael C. Grant <mcgrant>
Thu 16 Jan 2014 12:23:07 AM UTC, comment #1: 

First, are you using gnuplot of fltk?
This may be another manifestation of some
malfunction, possibly a race condition,
associated with drawnow.

The most recent bug report on this is 41216,
but there have been quite a few others.

There was a time when this problem seemed to have
"gone away" but I do not think a precise fix was
ever found. So, it appears to be back as expected.

If you look into this you will find that the
drawnow related flow of control is fairly hard to
follow.

Good luck!

Michael Godfrey <godfrey>
Project Member
Wed 15 Jan 2014 10:49:48 PM UTC, original submission:  

I'm running the gui-release build here, and I can cause Octave to segfault periodically simply by using the figure() command. I also see interesting behavior where the first figure window is initially rendered upside down (screenshot attached); that behavior is far more consistent.

I basically do this:

figure(1)
figure(2)
figure(3)
....

If it doesn't crash after the first three or four figures, I quit and try again. Sometimes quitting itself will do it.

This happens, by the way, with the "--no-gui" setting.

Look at Thread 9 of the crash dump; it seems that's where the crash is triggered, by what looks to be some sort of drawnow-like command. I'm not the most skilled lldb user out there but I can try and get more debug information if that's helpful.

Michael C. Grant <mcgrant>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #30283:  crash.dump added by mcgrant (61KiB - application/octet-stream)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by mcgrant (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-16 jordigh StatusNone => Duplicate
        Open/ClosedOpen => Closed
        Releasedev => 3.8.0
        Dependencies- => Depends on bugs #40242
    2014-01-15 mcgrant Attached File- => Added crash.dump, #30283
        Attached File- => Added Screen Shot 2014-01-15 at 4.42.32 PM.png, #30284

    Back to the top


    Powered by Savane 3.5