This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Various] libc/1208: segfault in fclose on fdopen'ed FILE pointer



I'm clueless now - and neither have time to investigate further:-(.
Sascha send a bug report and we've exchanged a number of emails.  I'm
appending all of them.

I'd really appreciate if somebody would look into this and help to fix 
the problem.

Thanks,
Andreas



Topics:
   libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
   Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer


----------------------------------------------------------------------

Date: Sat, 17 Jul 1999 13:24:39 -0400
From: sascha@schumann.cx
To: bugs@gnu.org
Subject: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-Id: <199907171724.NAA32293@delysid.gnu.org>


>Number:         1208
>Category:       libc
>Synopsis:       segfault in fclose on fdopen'ed FILE pointer
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    libc-gnats
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Sat Jul 17 13:30:01 EDT 1999
>Last-Modified:
>Originator:     sascha@schumann.cx
>Organization:
net
>Release:        2.1.1
>Environment:
Alpha, egcs 1.1.2, Linux 2.2.10
>Description:
The following program segfaults on Alpha, but not on x86. We eventually hit 
this particular bug in one program on x86, but I'm not able to produce a short 
test program which works on that platform.

$ gdb fd
GNU gdb 4.17.0.11 with Linux support
...

(gdb) r
Starting program: /home/sas/fd
Program received signal SIGSEGV, Segmentation fault.
0x20000183000 in _IO_new_fclose ()
(gdb) bt
#0  0x20000183000 in _IO_new_fclose ()
#1  0x120000580 in main () at fd.c:14
#2  0x2000014f990 in __libc_start_main ()

(14 is the fclose statement)

>How-To-Repeat:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

main() {
        int f;
        FILE *f2;

        f = open("/dev/stdin", O_RDONLY);
        f2 = fdopen(f, "r");
        fclose(f2);
        close(f);
}%0
>Fix:
>Audit-Trail:
>Unformatted:


------------------------------

Date: Sat, 17 Jul 1999 15:50:02 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-Id: <199907171950.PAA02950@mescaline.gnu.org>

The following reply was made to PR libc/1208; it has been noted by GNATS.

From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: sascha@schumann.cx
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Date: 17 Jul 1999 20:58:42 +0200

 >>>>> sascha  writes:
 
 >> Number:         1208
 >> Category:       libc
 >> Synopsis:       segfault in fclose on fdopen'ed FILE pointer
 
  > The following program segfaults on Alpha, but not on x86. We eventually hit 
  > this particular bug in one program on x86, but I'm not able to produce a short 
  > test program which works on that platform.
 
 
  > $ gdb fd
  > GNU gdb 4.17.0.11 with Linux support
  > ...
 
  > (gdb) r
  > Starting program: /home/sas/fd
  > Program received signal SIGSEGV, Segmentation fault.
  > 0x20000183000 in _IO_new_fclose ()
  > (gdb) bt
  > #0  0x20000183000 in _IO_new_fclose ()
  > #1  0x120000580 in main () at fd.c:14
  > #2  0x2000014f990 in __libc_start_main ()
 
  > (14 is the fclose statement)
 
 >> How-To-Repeat:
  > #include <stdio.h>
  > #include <sys/types.h>
  > #include <sys/stat.h>
  > #include <fcntl.h>
  > #include <unistd.h>
 
  > main() {
  >         int f;
  >         FILE *f2;
 
  >         f = open("/dev/stdin", O_RDONLY);
  >         f2 = fdopen(f, "r");
 
 Please check the results of fdopen and open.  If f2 is NULL, fclose
 might give a segfault.  And if it's NULL, you should check why
 /dev/stdin can't be opened.
 
  >         fclose(f2);
  >         close(f);
  > }%0
 
 Btw. the program runs fine on alpha (at least on the one where I
 checked it;-).
 
 Andreas
 -- 
  Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
   for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de


------------------------------

Date: Sat, 17 Jul 1999 23:35:05 +0200
From: sascha@schumann.cx
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-ID: <19990717233505.A5183@schumann.cx>
References: <199907171724.NAA32293@delysid.gnu.org> <u8g12nnlwd.fsf@arthur.rhein-neckar.de>
Content-Type: text/plain; charset=us-ascii

> Please check the results of fdopen and open.  If f2 is NULL, fclose
> might give a segfault.  And if it's NULL, you should check why
> /dev/stdin can't be opened.

Because that Alpha is running devfs and there is no /dev/stdin by
default. Please ignore my sample program.

I've just verified that our program works correctly on Solaris
2.7. Here is the backtrace and additional data from gdb
demonstrating the bug we see on Linux/x86 and Linux/Alpha, both
with glibc-2.1.1 and egcs-1.1.2.

Program received signal SIGSEGV, Segmentation fault.
0x400bcb39 in _IO_old_file_close_it (fp=0x80dfbc8) at oldfileops.c:143

line 143 of libio/oldfileops.c is

	close_status = _IO_SYSCLOSE (fp);

(gdb) bt
#0  0x400bcb39 in _IO_old_file_close_it (fp=0x80dfbc8) at oldfileops.c:143
#1  0x400b9de0 in _IO_old_fclose (fp=0x80dfbc8) at oldiofclose.c:43
#2  0x40180ead in apache_php_module_main (r=0x80ca80c, fd=19,
    display_source_mode=1) at main.c:1154
#3  0x4017efde in send_php () from /home/sas/httpd/libexec/libphp4.so
#4  0x4017f068 in send_parsed_php_source ()
   from /home/sas/httpd/libexec/libphp4.so
#5  0x8069ddb in ap_invoke_handler ()
#6  0x807c955 in process_request_internal ()
#7  0x807c9b4 in ap_process_request ()
#8  0x80747fd in child_main ()
#9  0x8074990 in make_child ()
#10 0x8074aeb in startup_children ()
#11 0x80750fc in standalone_main ()
#12 0x807584f in main ()
#13 0x4007f492 in __libc_start_main (main=0x8075534 <main>, argc=2,
    argv=0xbffffd14, init=0x804dfb4 <_init>, fini=0x808ec90 <_fini>,
    rtld_fini=0x4000a830 <_dl_fini>, stack_end=0xbffffd0c)
    at ../sysdeps/generic/libc-start.c:78

fp (which was opened by fdopen() before) in particular is

(gdb) p *fp
$1 = {_flags = -72538984, _IO_read_ptr = 0x40232000 "",
  _IO_read_end = 0x40232000 "", _IO_read_base = 0x40232000 "",
  _IO_write_base = 0x40232000 "", _IO_write_ptr = 0x40232000 "",
  _IO_write_end = 0x40232000 "", _IO_buf_base = 0x40232000 "",
  _IO_buf_end = 0x40233000 <Address 0x40233000 out of bounds>,
  _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0,
  _markers = 0x0, _chain = 0x80b3e98, _fileno = 19, _blksize = 0,
  _old_offset = 0, _cur_column = 0, _vtable_offset = 0 '\000', _shortbuf = "",
  _lock = 0x80dfc60}

libphp4.so is (as the name implies) dynamically linked. Linking
it statically into Apache makes the problem disappear. Since it
also works correctly on Solaris (static and dynamic), I doubt
that this is an error on our side.

If you need more information (i.e. the source of the program),
please let me know.

- - 

          Regards,

                            Sascha Schumann
                                 Consultant


------------------------------

Date: Sun, 18 Jul 1999 03:20:02 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-Id: <199907180720.DAA20539@mescaline.gnu.org>

The following reply was made to PR libc/1208; it has been noted by GNATS.

From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: sascha@schumann.cx
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Date: 18 Jul 1999 08:51:06 +0200

 >>>>> sascha  writes:
 
 >> Please check the results of fdopen and open.  If f2 is NULL, fclose
 >> might give a segfault.  And if it's NULL, you should check why
 >> /dev/stdin can't be opened.
 
  > Because that Alpha is running devfs and there is no /dev/stdin by
  > default. Please ignore my sample program.
 
  > I've just verified that our program works correctly on Solaris
  > 2.7. Here is the backtrace and additional data from gdb
  > demonstrating the bug we see on Linux/x86 and Linux/Alpha, both
  > with glibc-2.1.1 and egcs-1.1.2.
 
  > Program received signal SIGSEGV, Segmentation fault.
  > 0x400bcb39 in _IO_old_file_close_it (fp=0x80dfbc8) at oldfileops.c:143
 
 Please recompile libphp4.so and also apache against glibc 2.1.1.  This 
 might be an instance of the problem described in FAQ 2.27.
 
 Andreas
 -- 
  Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
   for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de


------------------------------

Date: Sun, 18 Jul 1999 14:44:17 +0200
From: sascha@schumann.cx
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-ID: <19990718144417.A688@schumann.cx>
References: <199907171724.NAA32293@delysid.gnu.org> <u8g12nnlwd.fsf@arthur.rhein-neckar.de> <19990717233505.A5183@schumann.cx> <u8btdaih7p.fsf@arthur.rhein-neckar.de>
Content-Type: text/plain; charset=us-ascii

On Sun, Jul 18, 1999 at 08:51:06AM +0200, Andreas Jaeger wrote:
> >>>>> sascha  writes:
> 
> >> Please check the results of fdopen and open.  If f2 is NULL, fclose
> >> might give a segfault.  And if it's NULL, you should check why
> >> /dev/stdin can't be opened.
> 
>  > Because that Alpha is running devfs and there is no /dev/stdin by
>  > default. Please ignore my sample program.
> 
>  > I've just verified that our program works correctly on Solaris
>  > 2.7. Here is the backtrace and additional data from gdb
>  > demonstrating the bug we see on Linux/x86 and Linux/Alpha, both
>  > with glibc-2.1.1 and egcs-1.1.2.
> 
>  > Program received signal SIGSEGV, Segmentation fault.
>  > 0x400bcb39 in _IO_old_file_close_it (fp=0x80dfbc8) at oldfileops.c:143
> 
> Please recompile libphp4.so and also apache against glibc 2.1.1.  This 
> might be an instance of the problem described in FAQ 2.27.

They are both compiled against glibc 2.1.1. 

Is it possible that other dynamic libraries compiled against
2.0.x influence the linker?

- - 

          Regards,

                            Sascha Schumann
                                 Consultant


------------------------------

Date: Sun, 18 Jul 1999 15:04:21 +0200
From: sascha@schumann.cx
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-ID: <19990718150421.A851@schumann.cx>
References: <199907171724.NAA32293@delysid.gnu.org> <u8g12nnlwd.fsf@arthur.rhein-neckar.de> <19990717233505.A5183@schumann.cx> <u8btdaih7p.fsf@arthur.rhein-neckar.de> <19990718144417.A688@schumann.cx>
Content-Type: text/plain; charset=us-ascii

> > Please recompile libphp4.so and also apache against glibc 2.1.1.  This 
> > might be an instance of the problem described in FAQ 2.27.
> 
> They are both compiled against glibc 2.1.1. 
> 
> Is it possible that other dynamic libraries compiled against
> 2.0.x influence the linker?

I've removed support for all extensions now which depend on
libraries compiled against 2.0.x. 

$ ldd httpd
        libm.so.6 => /lib/libm.so.6 (0x4001b000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40037000)
        libdl.so.2 => /lib/libdl.so.2 (0x40064000)
        libc.so.6 => /lib/libc.so.6 (0x40067000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

$ ldd libphp4.so
        libdb.so.3 => /lib/libdb.so.3 (0x400a7000)
        libdl.so.2 => /lib/libdl.so.2 (0x400e2000)
        libm.so.6 => /lib/libm.so.6 (0x400e5000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x40101000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4012f000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x40144000)
        libc.so.6 => /lib/libc.so.6 (0x40152000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

Still, the same error can be observed.

- - 

          Regards,

                            Sascha Schumann
                                 Consultant


------------------------------

Date: Sun, 18 Jul 1999 17:13:05 +0200
From: sascha@schumann.cx
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-ID: <19990718171305.A1180@schumann.cx>
References: <199907171724.NAA32293@delysid.gnu.org> <u8g12nnlwd.fsf@arthur.rhein-neckar.de> <19990717233505.A5183@schumann.cx> <u8btdaih7p.fsf@arthur.rhein-neckar.de> <19990718144417.A688@schumann.cx> <19990718150421.A851@schumann.cx> <u8iu7ighyr.fsf@arthur.rhein-neckar.de>
Content-Type: text/plain; charset=us-ascii

On Sun, Jul 18, 1999 at 04:17:48PM +0200, Andreas Jaeger wrote:
> >>>>> sascha  writes:
> 
> >> > Please recompile libphp4.so and also apache against glibc 2.1.1.  This 
> >> > might be an instance of the problem described in FAQ 2.27.
> >> 
> >> They are both compiled against glibc 2.1.1. 
> >> 
> >> Is it possible that other dynamic libraries compiled against
> >> 2.0.x influence the linker?
> 
> Sascha> I've removed support for all extensions now which depend on
> Sascha> libraries compiled against 2.0.x. 
> Sascha> [...]
> 
> Sascha> Still, the same error can be observed.
> Strange. :-(
> 
> Could you check with LD_DEBUG=bindings set in your environment (for
> details check `LD_DEBUG=help ls') which library binds fclose to
> _IO_old_fclose (or fopen to _IO_old_fopen?).

No library, apparently.

out was produced with 

LD_DEBUG=bindings ./httpd -X >out 2>&1

$ grep IO_old out | wc -l
      0
$ grep GLIBC_2.0 out|wc -l
    669
$ grep GLIBC_2.1 out|wc -l
    191

That run produced the "standard" core dump:

#0  0x400bcb39 in _IO_old_file_close_it (fp=0x80c7d50) at oldfileops.c:143
...

gdb on that machine was also linked against glibc 2.1.1, if that
should play any role.

The complete `out' file is available under

http://mirror.schell.de/other/httpd_ld_bindings.gz

- - 

          Regards,

                            Sascha Schumann
                                 Consultant


------------------------------

Date: Sun, 18 Jul 1999 10:30:02 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Message-Id: <199907181430.KAA28966@mescaline.gnu.org>

The following reply was made to PR libc/1208; it has been noted by GNATS.

From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: sascha@schumann.cx
Cc: bugs@gnu.org
Subject: Re: libc/1208: segfault in fclose on fdopen'ed FILE pointer
Date: 18 Jul 1999 16:17:48 +0200

 >>>>> sascha  writes:
 
 >> > Please recompile libphp4.so and also apache against glibc 2.1.1.  This 
 >> > might be an instance of the problem described in FAQ 2.27.
 >> 
 >> They are both compiled against glibc 2.1.1. 
 >> 
 >> Is it possible that other dynamic libraries compiled against
 >> 2.0.x influence the linker?
 
 Sascha> I've removed support for all extensions now which depend on
 Sascha> libraries compiled against 2.0.x. 
 Sascha> [...]
 
 Sascha> Still, the same error can be observed.
 Strange. :-(
 
 Could you check with LD_DEBUG=bindings set in your environment (for
 details check `LD_DEBUG=help ls') which library binds fclose to
 _IO_old_fclose (or fopen to _IO_old_fopen?).
 
 Andreas
 -- 
  Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
   for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de


------------------------------

End of forwardgLBDVe Digest
***************************



-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]