Bug 11554 - setbuf coredumps when linked against libstdc++
setbuf coredumps when linked against libstdc++
Product: Red Hat Raw Hide
Classification: Retired
Component: libstdc++ (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2000-05-21 13:40 EDT by Jonathan Kamens
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-22 10:53:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Kamens 2000-05-21 13:40:02 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
#include <stdio.h>

  static char buf[BUFSIZ];

  setbuf(stderr, buf);

jik:/tmp!304> gcc foo.c -lstdc++
jik:/tmp!305> ./a.out
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().
Comment 1 Jonathan Kamens 2000-05-22 00:54:59 EDT
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
displayed before.

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.

#include <stdio.h>

  static char buf[1];

  setbuffer(stdin, buf, 1);
Comment 2 Cristian Gafton 2000-05-22 10:53:59 EDT
assign to jakub
Comment 3 Jakub Jelinek 2000-09-05 04:48:03 EDT
Both of these were fixed on 2000-05-21.

Note You need to log in before you can comment on or make changes to this bug.