[Octave-bug-tracker] [bug #62207] segfault in bug-35881/bug-35881.tst in 32-bit ARM and MIPS

[Sébastien Villemot]

Follow-up Comment #10, bug #62207 (project octave):

It’s indeed possible that I’m experiencing several different random bugs.
But I also observe that with Octave 6 there was barely any testsuite crash on
Debian build daemons, while with Octave 7 crashes have been quite frequent (1
over 9 builds with 7.0.90, 4 over 12 builds with 7.0.92). As I already said,
the current situation with Octave 7 is really problematic from Debian’s
point of view, and I don’t really know what we are going to do if they are
not fixed before the final release.

I finally got a backtrace for the initial problem reported in this bug
(segfault in bug-35881/bug-35881.tst). I got it with 7.0.92 on mipsel:


  fixed/bug-35881/bug-35881.tst ..................................            
                                                                             
Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.            
                                                                             
0x7755daf4 in octave::tree_statement::line (this=<optimized out>) at
libinterp/parse-tree/pt-stmt.cc:123                                  
123                 : (m_expression ? m_expression->line () : -1));           
                                                                             
(gdb) bt                                                                      
                                                                             
#0  0x7755daf4 in octave::tree_statement::line (this=<optimized out>) at
libinterp/parse-tree/pt-stmt.cc:123                                         
#1  octave::tree_statement::line (this=<optimized out>) at
libinterp/parse-tree/pt-stmt.cc:119
#2  0x7751cd24 in octave::tree_breakpoint::visit_statement (stmt=...,
this=0x7fff0600) at libinterp/parse-tree/pt-bp.cc:322
#3  octave::tree_breakpoint::visit_statement (this=0x7fff0600, stmt=...) at
libinterp/parse-tree/pt-bp.cc:312
#4  0x7751bcd0 in octave::tree_statement::accept (tw=..., this=<optimized
out>) at libinterp/parse-tree/pt-stmt.h:124
#5  octave::tree_breakpoint::visit_statement_list (this=0x7fff0600, lst=...)
at libinterp/parse-tree/pt-bp.cc:337
#6  0x7755eaf0 in octave::tree_statement_list::accept (tw=...,
this=0x55b64ae0) at libinterp/parse-tree/pt-stmt.h:201                        
              
#7  octave::tree_statement_list::list_breakpoints (this=0x55b64ae0) at
libinterp/parse-tree/pt-stmt.cc:224       
#8  0x7755f44c in octave::tree_statement_list::remove_all_breakpoints
(this=0x55b64ae0, evmgr=...,                                                  
       
    file="/home/sebastien/octave7092/share/octave/7.0.92/m/gui/listdlg.m") at
libinterp/parse-tree/pt-stmt.cc:284
#9  0x7740acc4 in octave_user_code::~octave_user_code (this=0x55e5ab00,
__in_chrg=<optimized out>) at libinterp/octave-value/ov-usr-fcn.cc:81         
     
#10 0x7740b0b4 in octave_user_function::~octave_user_function
(this=0x55e5ab00, __in_chrg=<optimized out>) at
libinterp/octave-value/ov-usr-fcn.cc:237
…


As you can see, this is an optimized build because this hardware is so slow
that repeateadly running the testsuite on an unoptimized build takes forever.
However, if you need more information about the contents of the data
structures, I can try to see if I can reproduce it without optimization.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62207>

_______________________________________________
  Message posté via Savannah
  https://savannah.gnu.org/