Bug#35389: glibc2.1 segfaults for C++ stream code from glibc2.0 system

[Dirk Eddelbuettel <edd@debian.org>]

Package: libc6
Version: 2.1.1-0pre1.2

Two bugs were reported against Octave as the glibc2-compiled version
segfaults under glibc2.1.  Compiling with debugging enabled, and running
under gdb revealed that the segfault is not caused by Octave itself, but
rather by an interaction between glibc2.1 and stdlibc++.  John Eaton
distilled the following little program:

  #include <iostream.h>
  #include <strstream.h>

  int
  main (void)
  {
    ostrstream buf;
    for (int i = 32; i < 127; i++)
      buf << (char) i;
    buf << endl;
    buf << ends;
    cout << buf.str ();
    return 0;
  }

This is motivated by the actual code causing the segfault:

	  buf << (char) c;

where buf is an ostrstream and c is some integer.  The handle_string routine
is just trying to read a character string and store it in a buffer.

On my mostly-slink system 'sonny' with glibc2:

    edd@sonny:~/progs/C++> ./jwe
    !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

whereas on a potato-system with glibc2.1 

    edd@telmer:~/octave> ./jwe
    Segmentation fault
    edd@telmer:~/octave> 

and gdb shows:

    edd@telmer:~/octave> gdb jwe
    GNU gdb 4.17.19981224.m68k.objc.threads.hwwp.fpu.gnat
    Copyright 1998 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i686-pc-linux-gnu"...
    (gdb) run
    Starting program: /home/edd/octave/jwe 

    Program received signal SIGSEGV, Segmentation fault.
    0x400d7973 in   ()
    (gdb) backtrace
    #0  0x400d7973 in   ()
    #1  0x400d4fe3 in putc ()
    #2  0x4003efae in ostream::operator<< ()
    #3  0x804884f in main () at jwe-ostream-test.cc:9

which is identical to the backtrace we got from Octave.

I hope this information is helpful in advancing glibc2.1.

Regards, Dirk

-- 
If the current stylistic distinctions between  open-source and commercial
software persist,  an open-software  revolution could lead to yet another
divide between haves and have-nots: those with the skills and connections 
to make  use of free  software,  and those  who must pay high  prices for
increasingly dated commercial offerings.           -- Scientific American