Bug#35389: glibc2.1 segfaults for C++ stream code from glibc2.0 system
John> I'm not sure what version of libstdc++ is installed on the system
John> that has glibc2.1 (Dirk should be able to clarify this point).
Just to recap, here is my _glibc 2.0_ system (mostly slink) where I compiled:
ii libc6 2.0.7.19981211 GNU C Library: shared libraries
ii libc6-dev 2.0.7.19981211 GNU C Library: Development libraries and hea
ii libstdc++2.9 2.91.60-5 The GNU stdc++ library (egcs version)
ii libstdc++2.9 2.91.60-5 The GNU stdc++ library (egcs version)
No packages found matching libstdc++2.9-glibc2.1.
No packages found matching libstdc++2.9-glibc2.1-dev.
and here is Colin's _glibc 2.1_ machine (potato, but IIRC not current) where
the seg fault occurs:
ii libc6 2.1.1-0pre1.2 GNU C Library: shared libraries
ii libc6-dev 2.1.1-0pre1.2 GNU C Library: Development libraries and hea
ii libstdc++2.9 2.91.61-1 The GNU stdc++ library (egcs version)
ii libstdc++2.9 2.91.61-1 The GNU stdc++ library (egcs version)
ii libstdc++2.9-gl 2.91.63-1.1 The GNU stdc++ library (egcs version)
ii libstdc++2.9-gl 2.91.63-1.1 The GNU stdc++ library (development files)
Zack> If both libc and libstdc++ have been updated, then yes, there is a
Zack> bug.
So is it, or isn't it?
Zack> I wonder if this is the problem with lseek that got patched upstream
Zack> about three days ago.
Hm, why would that matter for this problem? Recall that we trigger the bug
by
#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;
}
Thanks, 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
Reply to: