bugGNU Octave - Bugs: bug #40469, crash on graphics operation (clf...


bug #40469: crash on graphics operation (clf only ?)

Submitter:  marco atzeri <matzeri>
Submitted:  Mon 04 Nov 2013 02:27:04 PM UTC
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Microsoft Windows
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 19 Aug 2014 05:18:13 PM UTC, comment #15: 

Marco reported on the maintainers mailing list that this issue was solved with cset c9f960441513:


I'm closing this bug report and also mark the bug here http://wiki.octave.org/3.8_Bug_Fix_List as fixed.

Andreas Weber <andy1978>
Project Member
Sun 29 Jun 2014 07:17:23 PM UTC, comment #14: 

I think the variable names are confusing in this regard.  The toolkit_flag is a per-object flag seems to have been related to whether the object was supported by the toolkit.  Now it seems to be an indication tha the graphic object is a figure or menu and thus might contain sub-objects which need updating.

If you want to experiment, change line 1940 of _init_fltk_.cc to

return true;

This will set the flag to true when the particular object, like line or surface, is initialized.  It doesn't seem to make much difference to me in terms of output, but maybe it will help with your segfault.

Rik <rik5>
Project Administrator
Sun 29 Jun 2014 04:57:11 PM UTC, comment #13: 

Question: Is it correct to call Fl::check with
  *obj.rep.toolkit_flag = false  ?

#9  0x0000000522902c12 in _fltk_redraw_ ()
    at ../../octave/libinterp/dldfcn/__init_fltk__.cc:1910
1910          Fl::check ();
(gdb) l
1905                    }
1906                }
1907            }
1909          // it seems that we have to call Fl::check twice to get everything drawn
1910          Fl::check ();
1911          Fl::check ();
1912        }
1914      return 0;
(gdb) p toolkit_loaded
$5 = true
(gdb) p obj
$6 = {rep = 0x600247cb0}
(gdb) p *obj.rep
$8 = {_vptr.base_graphics_object = 0x50ab98a70 <vtable for root_figure+16>, count = {
    count = 2}, toolkit_flag = false}

marco atzeri <matzeri>
Tue 03 Dec 2013 08:56:45 PM UTC, comment #12: 

backtrace on 17131

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8236.0x23ac]
0x68a110f4 in cygX11-xcb-1!XGetXCBConnection () from /usr/bin/cygX11-xcb-1.dll
(gdb) bt
#0  0x68a110f4 in cygX11-xcb-1!XGetXCBConnection ()
   from /usr/bin/cygX11-xcb-1.dll
#1  0x6fea5d5d in cygGL-1!__glXFlushRenderBuffer () from /usr/bin/cygGL-1.dll
#2  0x6feaf939 in cygGL-1!__indirect_glMatrixMode () from /usr/bin/cygGL-1.dll
#3  0x63e0440e in setup_viewport (this=0x6feda000 <dummyContext>, hh=420, ww=0)
    at ../../octave/libinterp/dldfcn/__init_fltk__.cc:168
#4  OpenGL_fltk::resize (this=0x8043c178, xx=0, yy=20, ww=560, hh=420)
    at ../../octave/libinterp/dldfcn/__init_fltk__.cc:138
#5  0x63e084f4 in plot_window::draw (this=0x804c0148)
    at ../../octave/libinterp/dldfcn/__init_fltk__.cc:1228
#6  0x6494179f in flush (this=0x804db290) at ../FL/x.H:160
#7  Fl::flush () at Fl.cxx:741
#8  0x64942599 in Fl::wait (time_to_wait=<optimized out>, time_to_wait@entry=0)
    at Fl.cxx:507
#9  0x6494263d in Fl::check () at Fl.cxx:619
#10 0x63e029d1 in _fltk_redraw_ ()
    at ../../octave/libinterp/dldfcn/__init_fltk__.cc:1862
#11 0x63e140a8 in fltk_graphics_toolkit::redraw_figure (this=0x801cf510,
    go=...) at ../../octave/libinterp/dldfcn/__init_fltk__.cc:1985
#12 0x00e5bcff in redraw_figure (go=..., this=0x28a564)
    at corefcn/graphics.h:2257
#13 Fdrawnow (args=...) at ../../octave/libinterp/corefcn/graphics.cc:9488
#14 0x00c0c06c in octave_builtin::do_multi_index_op (
    this=this@entry=0x801532a0, nargout=nargout@entry=0, args=...,
    at ../../octave/libinterp/octave-value/ov-builtin.cc:131
#15 0x00c0c37f in octave_builtin::do_multi_index_op (this=0x801532a0,
    nargout=0, args=...)
    at ../../octave/libinterp/octave-value/ov-builtin.cc:99
#16 0x00c7543a in octave_value::do_multi_index_op (this=this@entry=0x28a7a0,
    nargout=nargout@entry=0, idx=...)
    at ../../octave/libinterp/octave-value/ov.cc:1351
#17 0x00cc7487 in feval (name=..., args=..., nargout=nargout@entry=0)
    at oct-parse.yy:3866
#18 0x00ea6308 in interactive_input (s=..., eof=@0x28a90a: false)
    at ../../octave/libinterp/corefcn/input.cc:198
#19 0x00ea64d9 in octave_base_reader::octave_gets (this=this@entry=0x80367ef0,
    eof=@0x28a90a: false) at ../../octave/libinterp/corefcn/input.cc:251
#20 0x00ea683c in octave_terminal_reader::get_input (this=0x80367ef0,
    eof=@0x28a90a: false) at ../../octave/libinterp/corefcn/input.cc:611
#21 0x00cbc193 in get_input (eof=@0x28a90a: false, this=0x803aeab0)
    at ../../octave/libinterp/corefcn/input.h:233
#22 octave_lexer::fill_flex_buffer (this=0x803ae950, buf=0x80401308 "",
    max_size=8192) at lex.ll:3185
#23 0x00cbbc47 in yy_get_next_buffer (yyscanner=yyscanner@entry=0x803a7d58)
    at parse-tree/lex.cc:3239
#24 0x00cc262d in octave_lex (yylval_param=yylval_param@entry=0x28a9fc,
    yyscanner=0x803a7d58) at parse-tree/lex.cc:3080
#25 0x00ccec85 in octave_pull_parse (yyps=yyps@entry=0x0, parser=...)
    at parse-tree/oct-parse.cc:2099
#26 0x00cced37 in octave_parse (parser=...) at parse-tree/oct-parse.cc:2069
#27 octave_parser::run (this=this@entry=0x28aaac) at oct-parse.yy:3210
#28 0x00f98e69 in main_loop () at ../../octave/libinterp/corefcn/toplev.cc:567
#29 0x0096474a in octave_execute_interpreter ()
    at ../../octave/libinterp/octave.cc:1016
#30 0x00401785 in main (argc=1, argv=0x28ac5c)
    at ../../octave/src/main-cli.cc:42

marco atzeri <matzeri>
Tue 03 Dec 2013 04:49:38 PM UTC, comment #11: 

Ben's changeset was fixing the fact that the menu was not being displayed.  The menubar is 40 pixels so that would account for the difference in figure sizes.  It still doesn't much explain why there is a crash.  The previous experiments showed that creating a figure and clearing it were not a problem.  It was only when an axes object was added that the problem appeared.

I think we do need a backtrace so I would re-compile with '-g -O0'.  Try running 'gdb octave-cli.exe' to avoid the wrapper executable.  I've had no problems on MinGW getting gdb to follow the correct thread during debugging.

Rik <rik5>
Project Administrator
Tue 03 Dec 2013 01:52:59 PM UTC, comment #10: 

for what I can see the 17131 window is 40 pixel longer than 17130 one

$ gm identify cygwin-X*
cygwin-X_17130.png PNG 576x458+0+0 DirectClass 8-bit 13.4K 0.000u 0:01
cygwin-X_17131.png[1] PNG 576x498+0+0 DirectClass 8-bit 14.0K 0.000u 0:01
cygwin-X_364.png[2] PNG 576x458+0+0 DirectClass 8-bit 12.9K 0.000u 0:01

17130 and previous 3.6.4 have the same size but the menu
is visible only on 17130.

marco atzeri <matzeri>
Mon 02 Dec 2013 06:19:27 PM UTC, comment #9: 

I don't have any thoughts as to why this is causing a crash.  However, I have attached a picture of what a FLTK figure window looked like before 17131 (this is from the 3.6.4 release)

This 17131 changeset took a lot of effort to obtain a working result for MacOS and Linux. Some testing was also done Windows, but I don't recall the detail. Personally, I'd like to see the FLTK toolkit deprecated asap ... and replaced with QtHandles.

My guess is that it will be easier to integrate QtHandles than to make the FLTK toolkit reliable across all platforms. Unfortunately, I don't have the time to work on this.

Ben Abbott <bpabbott>
Project Member
Mon 02 Dec 2013 05:45:30 PM UTC, comment #8: 

Adding Ben to the CC list for this bug.  Maybe he has an idea about what in changeset 17131 would be problematic.

Rik <rik5>
Project Administrator
Mon 02 Dec 2013 04:25:06 PM UTC, comment #7: 

after 4 full days of bisect

$ hg bisect -b
The first bad revision is:
changeset:   17131:ea19ea629a09
user:        Ben Abbott  <bpabbott@mac.com>
date:        Thu Aug 01 07:43:59 2013 -0400
summary:     Proper placement of the menubar, the toolbar and plot canvas.

marco atzeri <matzeri>
Fri 08 Nov 2013 09:23:41 PM UTC, comment #6: 

just noted that fltk is now the default.
So one correction about graphics_toolkit

crashes on ftlk
doesn't on gnuplot

marco atzeri <matzeri>
Fri 08 Nov 2013 09:06:47 PM UTC, comment #5: 

good idea

hf = figure ();
   doesn't crash

hf = figure ();
ha = axes ();

marco atzeri <matzeri>
Fri 08 Nov 2013 03:54:38 PM UTC, comment #4: 

Do any plot commands work?

Maybe you can attempt to narrow it down by building up the graphic objects one by one.

hf = figure ();
clf;  # Crash?
hf = figure ();
ha = axes ();
clf;  # Crash?
hf = figure ();
ha = axes ();
hl = line ();
clf;  # Crash?
hf = figure ();
ha = axes ();
hs = surf ();
clf;  # Crash?

Rik <rik5>
Project Administrator
Fri 08 Nov 2013 11:38:13 AM UTC, comment #3: 

Tested on latest build
changeset:   17872:7d9a4eef8022


make no difference. Same crash

I agree that "rundemos" passing is really weird.

Unfortunately BT on cygwin is seldom useful for
multithread programs.

marco atzeri <matzeri>
Thu 07 Nov 2013 09:56:59 PM UTC, comment #2: 

No problems with this in Fedora 19.

Michael Godfrey <godfrey>
Project Member
Thu 07 Nov 2013 09:42:21 PM UTC, comment #1: 

This is really weird.  'rundemos' and 'make check' repeatedly create figures and use clf() to clear them.

Does it work if the figure is created first?


Unfortunately, the usual way to find out what is happening is to compile with '-g -O0' and run under gdb until you get the segfault.  Then type 'bt' to get the backtrace and figure out where you were in the code when the segfault happened.

Rik <rik5>
Project Administrator
Mon 04 Nov 2013 02:27:04 PM UTC, original submission:  

on cygwin (32bit)

The following 2 commands are enough to crash octave

octave-cli:1> sombrero()
octave-cli:2> clf()

changeset:   17839:2ff47214de72
summary:     datestr.m: Accomodate Mac OS X odd support of %p in strftime.

gcc (GCC) 4.7.3

Built from scratch on clean directories

../octave/configure --disable-java --enable-shared --enable-float-truncate --disable-jit  lt_cv_deplibs_check_method=pass_all LDFLAGS="-Wl,-no-undefined -L/usr/local/lib"

First reported as

But in this case LLVM is not relevant as it fails also without.

- No difference between cli and gui
- make check passed
- rundemos passed
- same result for both graphic toolkits

marco atzeri <matzeri>


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

Attach Files:

Attached Files
file #29769:  cygwin-X_17131.png added by matzeri (14KiB - image/png)
file #29770:  cygwin-X_364.png added by matzeri (13KiB - image/png)
file #29771:  cygwin-X_17130.png added by matzeri (13KiB - image/png)
file #29757:  Before 17131.png added by bpabbott (42KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by andy1978 (Posted a comment)
  • -email is unavailable- added by bpabbott (Updated the item)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by matzeri (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 project members can vote.





    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-08-19 andy1978 StatusNone Fixed
        Open/ClosedOpen Closed
    2013-12-03 matzeri Attached File- Added cygwin-X_17131.png, #29769
        Attached File- Added cygwin-X_364.png, #29770
        Attached File- Added cygwin-X_17130.png, #29771
    2013-12-02 bpabbott Attached File- Added Before 17131.png, #29757
    2013-12-02 rik5 Carbon-Copy- Added bpabbott

    Back to the top

    Powered by Savane 3.9