Octave crashes with std:bad_alloc since Jul20

[Ben Abbott]

I'm seeing a crash, "std:bad_alloc" ...

../../run-octave -f -q -H ./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS 
../../src/DOCSTRINGS || { rm -f doc-cache; exit 1; }
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
/bin/sh: line 1:  4222 Abort trap              ../../run-octave -f -q -H 
./mk_doc_cache.m doc-cache ../../scripts/DOCSTRINGS ../../src/DOCSTRINGS
make[3]: *** [doc-cache] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

 done
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

>From gdb, the backtrace gives ...

Program received signal SIGABRT, Aborted.
0x911fbef6 in __kill ()
(gdb) bt
#0  0x911fbef6 in __kill ()
#1  0x911fbee8 in kill$UNIX2003 ()
#2  0x9128e62d in raise ()
#3  0x912a46e4 in abort ()
#4  0x94979fda in __gnu_cxx::__verbose_terminate_handler ()
#5  0x9497817a in __cxxabiv1::__terminate ()
#6  0x949781ba in std::terminate ()
#7  0x949782b8 in __cxa_throw ()
#8  0x012debda in dim_vector::safe_numel (this=0xbffe7d54) at dim-vector.cc:102
#9  0x012dd244 in Array<std::string>::Array (this=0xbffe7d44, address@hidden) 
at Array.h:205
#10 0x012dd428 in Array [inlined] () at 
/Users/bpabbott/Development/mercurial/local_clone/liboctave/Array.h:973
#11 0x012dd428 in Array<std::string>::resize (this=0x1f78740, r=3, c=1, 
address@hidden) at Array.cc:973
#12 0x012dc81b in string_vector::string_vector (this=0x1f78740, s=0x1f733c0) at 
str-vec.cc:91
#13 0x012dcab4 in string_vector::string_vector (this=0x1f78740, s=0x1f733c0) at 
str-vec.cc:95
#14 0x012dbaff in __static_initialization_and_destruction_0 
(__initialize_p=<value temporarily unavailable, due to optimizations>, 
__priority=<value temporarily unavailable, due to optimizations>) at 
file-ops.cc:119
#15 0x012dbb68 in global constructors keyed to _ZN8file_ops8instanceE () at 
file-ops.cc:795
#16 0x8fe0ed6d in 
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE 
()
#17 0x8fe0d31e in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#18 0x8fe0d2c2 in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#19 0x8fe0d2c2 in 
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEj ()
#20 0x8fe0d3d1 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE 
()
#21 0x8fe024a9 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#22 0x8fe07950 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#23 0x8fe018b1 in __dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKcl ()
#24 0x8fe01057 in __dyld__dyld_start ()
(gdb) 

I tried several successive builds to try to isolate the changeset that 
introduced this behavior for me.

I dont' see this problem with "hg revert -r85cbd239fce2 --all"

        http://hg.savannah.gnu.org/hgweb/octave/rev/85cbd239fce2

Including the next changeset, "hg revert --all -d 7/20", results in octave 
crashing.

        http://hg.savannah.gnu.org/hgweb/octave/rev/6683f0c9d742
        
Some details of my system are ...

MacOS X 10.6.4
Xcode 3.2.2
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
GNU Fortran (GCC) 4.4.4

Does anyone else see this?

Ben