Re: segfault and onCleanup()

[John W. Eaton]

On  8-Dec-2011, Ben Abbott wrote:

| 
| On Dec 8, 2011, at 11:07 AM, John W. Eaton wrote:
| 
| > On  8-Dec-2011, Ben Abbott wrote:
| > 
| > | With the change above, I still see a segfault.
| > | 
| > | panic: Segmentation fault: 11 -- stopping myself...
| > | attempting to save variables to `octave-core'...
| > | terminate called after throwing an instance of 'std::length_error'
| > |   what():  basic_string::_S_create
| > | panic: attempted clean up apparently failed -- aborting...
| > | make[1]: *** [check] Abort trap: 6
| > | make: *** [check] Error 2
| > | 
| > | I tried (naively?) restoring the patches to ov-typeinfo.cc and 
graphics.cc, but the segfault persists.
| > 
| > Is there an onCleanup.oct file from a previous build still present?
| > 
| > jwe
| 
| After  (1) deleted everything named onCleanup.*, (2) maintainter-clean, (3) 
hg pull ; hg update -C, and (4) building octave.  I still see a segfault (a bit 
different now).
| 
| panic: Segmentation fault: 11 -- stopping myself...
| attempting to save variables to `octave-core'...
| octave(38952,0x7fff72320960) malloc: *** mmap(size=3458773283022905344) 
failed (error code=12)
| *** error: can't allocate region
| *** set a breakpoint in malloc_error_break to debug
| terminate called after throwing an instance of 'std::bad_alloc'
|   what():  std::bad_alloc
| panic: attempted clean up apparently failed -- aborting...
| make[1]: *** [check] Abort trap: 6
| make: *** [check] Error 2

Does this happen when starting Octave?  Exiting?  Running tests?

| >From gdb ...
| 
| Program received signal EXC_BAD_ACCESS, Could not access memory.
| Reason: KERN_INVALID_ADDRESS at address: 0x0000000111f23118
| 0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string const, 
graphics_toolkit>, std::_Select1st<std::pair<std::string const, 
graphics_toolkit> >, std::less<std::string>, 
std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
| (gdb) bt
| #0  0x00000001001ee9d7 in std::_Rb_tree<std::string, std::pair<std::string 
const, graphics_toolkit>, std::_Select1st<std::pair<std::string const, 
graphics_toolkit> >, std::less<std::string>, 
std::allocator<std::pair<std::string const, graphics_toolkit> > >::_M_erase ()
| #1  0x00007fff8526c7c8 in __cxa_finalize ()
| #2  0x00007fff8526c652 in exit ()
| #3  0x00000001003918ff in clean_up_and_exit ()
| #4  0x0000000100392420 in main_loop ()
| #5  0x0000000100324fdf in octave_main ()
| #6  0x0000000100000f44 in start ()

Are you building without -g?

If this really is a case of an uncaught bad_alloc exception, then we
need to know where it is thrown.  In gdb, do

  (gdb) catch throw

then trigger the bug and gdb should stop at the point where the
exception is thrown.

jwe