From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
Description of problem:
malloc crashes with SIGSEGV at -1 when calling indirect through __morecore.
__morecore was set to (int)_IO_pos_BAD by perror using a casted stderr, when the
value of stderr was _IO_stderr_ instead of _IO_2_1_stderr_
/* We don't have to do any special hacks regarding the file
position. Since the stderr stream wasn't used so far we just
write to the descriptor. */
perror_internal (fp, s, errnum);
/* Close the stream. */
((_IO_FILE *) stderr)->_offset = _IO_pos_BAD;
_dl_relocate_object first set stderr to _IO_2_1_stderr_, but the value of stderr
was changed to _IO_stderr_ by _IO_check_libio, called from __libc_global_ctors,
called from init, called from _dl_init_internal.
(_IO_stdin_used was 0, so _IO_check_libio [libio/oldstdfiles.c] changed stderr.)
This created a problem because sizeof(_IO_stderr_) is less than
sizeof(_IO_2_1_stderr_); in particular the assignment by perror [using the
casted pointer] clobbers 4 bytes beyond _IO_stderr_, and those 4 bytes happen to
Anyway, how can perror be sure that stderr is _IO_2_1_stderr_, and is not
This might be related to bug81259.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run proprietary application linked on phoebe-3 (i686 [athlon] using
Actual Results: Program received signal SIGSEGV, Segmentation fault.
0xffffffff in ?? ()
#0 0xffffffff in ?? ()
#1 0x42074112 in malloc () from /lib/tls/libc.so.6
#2 0x42029552 in qsort () from /lib/tls/libc.so.6
Expected Results: No SIGSEGV.
Should be fixed in the CVS glibc version.
Should be fixed in RHL9 errata, test version at