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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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:

http://octave.1599824.n4.nabble.com/Overhaul-FLTK-toolkit-resize-redraw-functions-tp4665662p4665790.html

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>
Group 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>
Group 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            }
1908
1909          // it seems that we have to call Fl::check twice to get everything drawn
1910          Fl::check ();
1911          Fl::check ();
1912        }
1913
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=...,
    lvalue_list=lvalue_list@entry=0x0)
    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>
Group 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>
Group 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>
Group 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 ();
clf;   
   doesn't crash

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

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>
Group administrator
Fri 08 Nov 2013 11:38:13 AM UTC, comment #3: 

Tested on latest build
changeset:   17872:7d9a4eef8022

figure
sombrero
clf

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


figure
sombrero
clf


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>
Group 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
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2013-November/037155.html

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

Additional
- 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:
   
   
Comment:
   

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 group 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.13-f8d8.
    Corresponding source code