Red Hat Bugzilla – Bug 11554
setbuf coredumps when linked against libstdc++
Last modified: 2008-05-01 11:37:55 EDT
jik:/tmp!300> rpm -q libstdc++
jik:/tmp!301> rpm -q gcc
jik:/tmp!302> rpm -q glibc
jik:/tmp!303> cat foo.c
static char buf[BUFSIZ];
jik:/tmp!304> gcc foo.c -lstdc++
Segmentation fault (core dumped)
This happens with the libstdc++ version shown above or the previous Raw
Hide version, after glibc is upgraded to the version shown above, so I
suspect some sort of incompatibility between libstdc++ and the newest
I tracked this down to the call to _IO_WSETBUF in _IO_setbuffer in
libio/iosetbuffer.c in the glibc sources. It appears that this code
believes that fp->_wide_data should be non-null when in fact it is null. I
was unable to determine the reason for the discrepancy; perhaps someone who
understands the code better can do so.
I discovered this because most groff applications will fail when linked
against the new libstdc++ because of this problem, because they call
setbuf(stderr, ...) right at the start of main().
Another problem which I'm willing to bet is related to this bug....
Run "ed /etc/profile" with glibc-2.1.90-11 installed. Type "1" and hit return,
which should cause ed to display the first line of text. It doesn't. Type "q"
and hit return and note that ed then displays all the text it should have
This behavior goes away if you comment out the line "setbuffer (stdin, stdinbuf,
1);" in buf.c in the ed source code. Or if you replace it with the "setvbuf"
call below it.
A simpler example.... The following program will sleep for 2 seconds and then
print and 'a' and a newline; it should have printed the 'a' and the newline
*before* sleeping for two seconds. Interestingly enough, if you remove the
"putchar('a');" so that all it's printing is the newline, then the newline
*does* get printed before the two-second sleep, as it should.
static char buf;
setbuffer(stdin, buf, 1);
assign to jakub
Both of these were fixed on 2000-05-21.