Re: segfault and onCleanup()

[John W. Eaton]

On  8-Dec-2011, Ben Abbott wrote:

| On Dec 8, 2011, at 1:00 PM, John W. Eaton wrote:
| 
| > 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
| 
| I had noticed that I have a problem with the debug info ... First, "catch 
throw" gives me ...
| 
| >> fntests
| Reading symbols for shared libraries . done
| 
| Integrated test scripts:
| 
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
| Reading symbols for shared libraries . done
|   src/DLD-FUNCTIONS/__contourc__.cc ...................... PASS    1/1   
|   src/DLD-FUNCTIONS/__delaunayn__.cc ..................... PASS    1/1   
|   src/DLD-FUNCTIONS/__dispatch__.cc ...................... PASS    1/1   
|   src/DLD-FUNCTIONS/__dsearchn__.cc ...................... PASS    1/1   
|   src/DLD-FUNCTIONS/__fltk_uigetfile__.cc ................ PASS    1/1   
|   src/DLD-FUNCTIONS/__glpk__.cc .......................... PASS    1/1   
|   src/DLD-FUNCTIONS/__lin_interpn__.cc ................... PASS    1/1   
|   src/DLD-FUNCTIONS/__magick_read__.cc ................... PASS    4/4   
|   src/DLD-FUNCTIONS/__pchip_deriv__.cc ................... PASS    1/1   
|   src/DLD-FUNCTIONS/__qp__.cc ............................ PASS    1/1   
|   src/DLD-FUNCTIONS/__voronoi__.cc ....................... PASS    1/1   
|   src/DLD-FUNCTIONS/besselj.cc ...........................Reading symbols for 
shared libraries . done
|  PASS  180/180 
|   src/DLD-FUNCTIONS/betainc.cc ...........................Reading symbols for 
shared libraries . done
|  PASS    6/6   
|   src/DLD-FUNCTIONS/bsxfun.cc ............................Reading symbols for 
shared libraries . done
| Reading symbols for shared libraries . done
| 
| Catchpoint 1 (exception thrown).
| Catchpoint 1 (exception caught), throw location unknown, catch location 
unknown, exception type octave_execution_exception
| 0x00000001071c603d in __cxa_throw ()

So this crash is happening because an exception is thrown somewhere
and isn't caught, not when quit is called explicitly?  So maybe this
is not related to my recent changes since I would expect a problem due
to that to only happen when quit is called to exit Octave.

| Second, regarding the debug info, I'm missing something that should be 
obvious. My configure script is below, can you (someone?) spot what I've done 
wrong?
| 
| export PREFIX=/opt/local
| export CC=/opt/local/bin/gcc-mp-4.5
| export CXX=/opt/local/bin/g++-mp-4.5
| export CXXCPP="/opt/local/bin/g++-mp-4.5 -E"
| export F77=/opt/local/bin/gfortran-mp-4.5
| export FC=/opt/local/bin/gfortran-mp-4.5
| export CXXFLAGS="-pipe -O2 -g -m64 -gstabs"
| export FFLAGS="$CXXFLAGS -D_THREAD_SAFE -pthread -gstabs"
| export CFLAGS="$FFLAGS -lstdc++"
| export LDFLAGS=-L$PREFIX/lib
| export CPPFLAGS=-I$PREFIX/include
| export BLAS_LIBS="-lcblas -lf77blas -latlas"
| export LAPACK_LIBS=-llapack
| 
| ./configure --prefix="/opt/local" --without-framework-carbon --with-x \
|             --with-cholmod="-lcholmod -lmetis"

Why did you choose -gstabs?  I don't know what is best for your
system, but I always use -ggdb3:

`-ggdb'
     Produce debugging information for use by GDB.  This means to use
     the most expressive format available (DWARF 2, stabs, or the
     native format if neither of those are supported), including GDB
     extensions if at all possible.

`-gstabs'
     Produce debugging information in stabs format (if that is
     supported), without GDB extensions.  This is the format used by
     DBX on most BSD systems.  On MIPS, Alpha and System V Release 4
     systems this option produces stabs debugging output which is not
     understood by DBX or SDB.  On System V Release 4 systems this
     option requires the GNU assembler.

`-gLEVEL'
`-ggdbLEVEL'
`-gstabsLEVEL'
`-gcoffLEVEL'
`-gxcoffLEVEL'
`-gvmsLEVEL'
     Request debugging information and also use LEVEL to specify how
     much information.  The default level is 2.

     Level 0 produces no debug information at all.  Thus, `-g0' negates
     `-g'.

     Level 1 produces minimal information, enough for making backtraces
     in parts of the program that you don't plan to debug.  This
     includes descriptions of functions and external variables, but no
     information about local variables and no line numbers.

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.

     `-gdwarf-2' does not accept a concatenated debug level, because
     GCC used to support an option `-gdwarf' that meant to generate
     debug information in version 1 of the DWARF format (which is very
     different from version 2), and it would have been too confusing.
     That debug format is long obsolete, but the option cannot be
     changed now.  Instead use an additional `-gLEVEL' option to change
     the debug level for DWARF2.

jwe