octave allocator patch

[John W. Eaton]

On  6-Nov-2011, Rik wrote:

| I tried the octave allocator patch you sent out and I get a segfault with
| it when running 'make check'.  It's something in the test suite because
| just invoking run-octave and doing some test calculations/plots works
| fine.  This was with a gnulib pulled on 11/6/11 and a tip
| (13834:227130df89eb) from 11/6/11.  This may go away when Michael G.
| applies his shared ptr patch.  If it doesn't, though, it's not the fault of
| his patch.

I tried the following in my build tree with the patch applied:

  cd test
  ../run-octave  -g --norc --silent --no-history 
/home/jwe/src/octave/test/fntests.m /home/jwe/src/octave/test
  ...
  gdb startup messages
  ...
  (gdb) set print thread-events off
  (gdb) r

and the tests ended with

  *** glibc detected *** /scratch/jwe/build/octave/src/.libs/lt-octave: free(): 
corrupted unsorted chunks: 0x00000000026ec840 ***
  ...
  ...
  ...

The first few frames of the stack trace are:

  #0  0x00007ffff50b0405 in *__GI_raise (sig=<optimized out>)
      at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
  #1  0x00007ffff50b3680 in *__GI_abort () at abort.c:92
  #2  0x00007ffff50e6dbb in __libc_message (do_abort=<optimized out>, 
      fmt=<optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
  #3  0x00007ffff50f0606 in malloc_printerr (action=3, 
      str=0x7ffff51c72d0 "free(): corrupted unsorted chunks", 
      ptr=<optimized out>) at malloc.c:6283
  #4  0x00007ffff50f533c in *__GI___libc_free (mem=<optimized out>)
      at malloc.c:3738
  #5  0x00007ffff70febdf in symbol_table::fcn_info::~fcn_info (this=0x276c788, 
      __in_chrg=<optimized out>) at /home/jwe/src/octave/src/symtab.h:769
  #6  0x00007ffff71010f3 in std::pair<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const, 
symbol_table::fcn_info>::~pair (
      this=0x276c780, __in_chrg=<optimized out>)
      at /usr/include/c++/4.6/bits/stl_pair.h:87
  #7  0x00007ffff73f0460 in __gnu_cxx::new_allocator<std::pair<std::string 
const, symbol_table::fcn_info> >::destroy (this=0x7fffffffd50f, __p=0x276c780)
      at /usr/include/c++/4.6/ext/new_allocator.h:118
  #8  0x00007ffff73efd38 in std::_Rb_tree<std::string, std::pair<std::string 
const, symbol_table::fcn_info>, std::_Select1st<std::pair<std::string const, 
symbol_table::fcn_info> >, std::less<std::string>, 
std::allocator<std::pair<std::string const, symbol_table::fcn_info> > 
>::_M_destroy_node (this=0x7ffff7ddb3e0, 

Moving up to the fcn_info destructor shows this:

  (gdb) up
  #5  0x00007ffff70febdf in symbol_table::fcn_info::~fcn_info (this=0x276c788, 
      __in_chrg=<optimized out>) at /home/jwe/src/octave/src/symtab.h:769
  769           delete rep;
  (gdb) p rep
  $1 = (symbol_table::fcn_info::fcn_info_rep *) 0x26ec840
  (gdb) p *rep
  $2 = {
    name = {
      static npos = <optimized out>, 
      _M_dataplus = {
        <std::allocator<char>> = {
          <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data 
fields>}, 
        members of std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >::_Alloc_hider: 
        _M_p = 0x26b88b8 "afun"
      }
    }, 

Searching for afun in the sources turns up:

  ./scripts/sparse/bicgstab.m:%!function y = afun (x, a)
  ./scripts/sparse/bicgstab.m:%! [x, flag, relres, iter, resvec] = bicgstab 
(@(x) afun (x, A), b,

I checked in the following changeset and it seems to have fixed the
crashes for me.  Does this also fix the problem for you?

  http://hg.savannah.gnu.org/hgweb/octave/rev/2c80bbd87f5d

I also checked in the allocator patch next:

  http://hg.savannah.gnu.org/hgweb/octave/rev/a35d381e22b0

jwe