[Bug libc/10071] New: 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[Bug libc/10071] New: 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[jason dot vas dot dias at gmail dot com]

After building and installing the latest glibc from CVS, 
programs that link to 'libselinux.so' via GTK (ie. because
libgtk-x11-2.0.so.0.1400.8 links to libselinux) get a SEGV
in libio/genops.c:GI__underflow during the CRT startup BEFORE main() is entered.
I recompiled ALL the libraries this app links to afresh from latest SCM source,
but the problem remains: 

$ ldd ./my_gtk_app
        linux-vdso.so.1 =>  (0x00007fffec9fd000)
        libDayGUI.so.1 => /home/jason/DayGUI/libDayGUI.so.1 (0x00007f5fe4185000)
        libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f5fe3bad000)
        libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f5fe393a000)
        libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f5fe369e000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0
(0x00007f5fe3484000)
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0
(0x00007f5fe3278000)
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f5fe2ff4000)
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f5fe2dc8000)
        libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f5fe2ba9000)
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f5fe2961000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f5fe26e2000)
        libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f5fe249f000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f5fe229c000)
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f5fe1fbc000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f5fe1d36000)
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f5fe1b05000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f5fe18cd000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f5fe16b9000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f5fe149f000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5fe1284000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f5fe1081000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f5fe0d29000)
        libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f5fe0b27000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f5fe091f000)
        libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f5fe0715000)
        libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f5fe0513000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f5fe0301000)
        libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f5fe00ff000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f5fdfefa000)
        libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f5fdfcb4000)
        libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007f5fe4818000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f5fdfaab000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f5fdf772000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f5fdf557000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f5fdf355000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f5fdf150000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f5fdef34000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f5fded1f000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f5fdeaf6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f5fe4756000)

$ gdb  ./my_gtk_app
GNU gdb 6.8.0.20090412-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
(gdb) start
Breakpoint 1 at 0x44b181: file R_0.c, line 9021.
Starting program: /home/jason/D/Dupdate_TEST/DG_TEST/Dupdate_DG_TEST
[Thread debugging using libthread_db enabled]
[New Thread 0x7f6b8a1cc790 (LWP 26058)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f6b8a1cc790 (LWP 26058)]
*__GI___underflow (fp=<value optimized out>) at genops.c:361
361       return _IO_UNDERFLOW(fp);
(gdb) where
#0  *__GI___underflow (fp=<value optimized out>) at genops.c:361
#1  0x0000000a00000001 in ?? ()
#2  0x00007fff9232bc20 in ?? ()
#3  0x00007fff9232bc28 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb) info reg pc
pc: 0x7f6b86755898
(gdb) disass 0x7f6b86755890 0x7f6b86755900
Dump of assembler code from 0x7f6b86755890 to 0x7f6b86755900:
0x00007f6b86755890 <*__GI___underflow+80>:      fadds  (%rax)
0x00007f6b86755892 <*__GI___underflow+82>:      add    %al,(%rax)
0x00007f6b86755894 <*__GI___underflow+84>:      mov    %rbx,%rdi
0x00007f6b86755897 <*__GI___underflow+87>:      pop    %rbx
0x00007f6b86755898 <*__GI___underflow+88>:      mov    0x20(%rax),%r11
0x00007f6b8675589c <*__GI___underflow+92>:      jmpq   *%r11
0x00007f6b8675589f <*__GI___underflow+95>:      nop
(gdb) info reg rax
rax            0x0      0
(gdb)

Somehow, GI__underflow is getting a NULL `_IO_FILE *fp' parameter.

Any ideas anyone ?
TIA, Jason

-- 
           Summary: 2.9.90 (2009-04-14) libio/genops.c : __underflow() does
                    not handle NULL FP
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: jason dot vas dot dias at gmail dot com
                CC: glibc-bugs at sources dot redhat dot com
 GCC build triplet: lx86_64-pc-linux-gnu under linux-2.gcc-4.3.4(2009-04-10)
                    glibc-2
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[jason dot vas dot dias at gmail dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  GCC build triplet|lx86_64-pc-linux-gnu under  |x86_64-pc-linux-gnu under
                   |linux-2.gcc-4.3.4(2009-04-  |linux-2.26.30-rc1 , gcc-
                   |10) glibc-2                 |4.3.4(2009-04-


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[drepper at redhat dot com]

------- Additional Comments From drepper at redhat dot com  2009-04-14 19:08 -------
This is no place to get your self-inflicted problems debugged.  Either you
completely analyze and provide a test case for a sane environment or stick with
a distribution.

Don't expect anyone to care about this unless you do the work.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[jason dot vas dot dias at gmail dot com]

------- Additional Comments From jason dot vas dot dias at gmail dot com  2009-04-15 00:14 -------
Thanks for the response - sorry for not submitting a test case,
but I usually report a bug without a detailed test case first
to see if is a "known problem" and then submit a detailed test
case if it is not - which I am now doing.

BTW - RE: Comment #1 - you state:
 > provide a test case for a sane environment or stick with a distribution
 >
Are you suggesting that linux-2.6.30 + gcc-4.3.4 + binutils-2.19.51.20090412
does not constitute a "sane environment" ? If so, in what way ? Is the glibc 
in the CVS root `:pserver:anoncvs@sources.redhat.com:/cvs/glibc' not meant
to be built under any system other than a Red Hat one ? If so, this should
be stated clearly in the documentation at :
  http://www.gnu.org/software/libc/resources.html
which lists the above CVS root as the primary CVS source for GLIBC . 
I've set up different chroot environments for testing of my software, 
which I do not release until all test cases pass under each chroot 
environment:
  o LATEST of EVERTHING - originally gentoo 2008-02 based
    - this is the one which now has glibc-2.9.90 20090414 installed. 
    It also has multiple versions of GCC and binutils installed so I
    can test older versions against later dependency installations.
  o FC-11     o FC-10   o FC-8  o FC-6
  o RHEL-5    o RHEL-4  o RHEL-3
  o SuSe      o debian  o mandriva  o ubuntu
  o Solaris X86   o FreeBSD   o NetBSD
I try to report all bug reports found - is this somehow wrong to do ?

OK, so here's the test case :

TEST CASE
~~~~~~~~~

Environment:

gcc-4.3.4 ( svn 2009-04-09T00:16:16.646518Z )
binutils  ( CVS 2009-04-13, 2.19.51.20090412)
gtk-2.14.8 & all dependencies rebuilt as of 2000-04-01
Xorg @ 2009-04-01 : EVERYTHING under git://git.freedesktop.org/xorg rebuilt.

The AT&T AST SFIO and vmalloc packages rebuilt and installed from 
http://www.research.att.com/~gsf/download/tgz/sfio.2005-02-01.tgz,
with "posix_memalign" added to vmalloc (source available on request).

#include <gtk/gtk.h>
int main(int argc, char **argv, char **envp)
{
    gtk_init(&argc, &argv);
    GtkWidget *main_win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
    GtkWidget *label    = gtk_label_new("It Works!");
    gtk_container_add(GTK_CONTAINER(main_win),label);
    g_signal_connect (G_OBJECT (main_win), "delete_event",
                      G_CALLBACK (gtk_widget_destroy), main_win);
    g_signal_connect (G_OBJECT (main_win), "destroy",
                      G_CALLBACK (gtk_main_quit), NULL);
    gtk_widget_show_all(main_win);
    gtk_main();
    return(0);
}' > tgtk.c
$ gcc -o tgtk tgtk.c -I${DS_DIR} -L${DS_DIR} \
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2
-I/usr/include/libpng12 \
-Wl,--whole-archive,--export-dynamic /usr/ds_bin/libstdio.a
/usr/ds_bin/libsfio.a /usr/ds_bin/libvmalloc.a -Wl,--no-whole-archive
-lgtk-x11-2.0 -lgio-2.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
-lpangoft2-1.0 -latk-1.0 -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
-lfreetype -lfontconfig -lcrypt -lresolv -lrt -lpthread -ldl -lc
-Wl,-R,/home/jason/DayGUI:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.3.4

$ gdb ./tgtk
GNU gdb 6.8.0.20090412-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu"...
(gdb) start
Breakpoint 1 at 0x4231b0
Starting program: /home/jason/D/tGtk/tgtk
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1434a07790 (LWP 10561)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1434a07790 (LWP 10561)]
*__GI___underflow (fp=<value optimized out>) at genops.c:361
361       return _IO_UNDERFLOW (fp);
(gdb) quit


Now, if I replace the new glibc-2.9.90-20090414 files with those from
glibc-2.9.90-20090320 , and repeat the test case, the above problem does not
occur, and a gtk window displays the string "It Works!" when run .

Yes, this problem is something to do with including the SFIO packages, and
I can sort this out myself.

But ONLY an install of the new glibc is necessary to trigger the problem -
all other software remains unchanged.

So what changed in glibc between 20090320 and 20090414 that would cause these
SFIO glibc function overrides to cause a SIGSEGV in _start ( GI__underflow ) ?

This is what I am now investigating - any assistance or suggestions 
that the GLIBC developers might make would be most gratefully received.

But IMHO it is a bug that GI__underflow() does not detect a NULL fp argument -
if it did, it could use the new libunwind support to print a stack backtrace
that might greatly help track down the root cause of this problem.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[pasky at suse dot cz]

------- Additional Comments From pasky at suse dot cz  2009-04-15 11:10 -------
Note that you might use the git mirror
(http://sources.redhat.com/glibc/wiki/GlibcGit) to quickly bisect glibc to see
exactly which commit broke it. (On the other hand, bisecting might be a bit of a
challenge since unfortunately, Ulrich usually does not commit change to multiple
files all at once but separately for each file, so many revisions might not
compile - but I'm not sure how big portion in practice, so it's something to try
and see.)

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[jason dot vas dot dias at gmail dot com]

------- Additional Comments From jason dot vas dot dias at gmail dot com  2009-04-19 07:28 -------
Sorry, this bug was actually caused by ldconfig(1) after installation making
gtk+-2.0 pick up the new libselinux.so.1 which in its init() constructor 
refers to the GLIBC extension 
     `__getdelim'
 (via  'getline')
which with the newer headers is now defined for x86_64 ; but getline() is not
in the older stdio standard used by 2005 vintage libstdio + libsfio - it is in
the newer libast (2006+) , so the glibc __getdelim is NOT over-ridden by any
SFIO getdelim or similar - it is now in the version used by my app. Sorry, 
but this database app has to link with a certain version of SFIO and this
caused confusion.  

Incidentally, perhaps this might lead to some propagation of the ld(1) 
 '-z (no?)muldefs' 
 options to ld.so(1) ? ie. Perhaps some new:
 '-z dynamic-(no?)muldefs' option -
 I mean, what is to stop subsequent load modules loaded with dlopen(3) 
with RTLD_GLOBAL options set overriding for instance glibc functions
such as __getdelim or fopen() etc. that are to be used by subsequently 
loaded with dlopen() modules ? If such an option had been available, then
the whole app could have been compiled with '-z defs' (default) ? 
Even programs built with '-z defs' can load modules that contain
their own definition of global symbols that will subsequently be
used by modules loaded later ? What about supporting something like
Solaris "interposer" object groups in Linux ld-linux.so.2 ?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[jason dot vas dot dias at gmail dot com]

------- Additional Comments From jason dot vas dot dias at gmail dot com  2009-04-19 08:46 -------
To clarify : 
  Only relinking after ldconfig(1) with new glibc and recompilation
  of app now containing __getdelim references, with SAME gtk+ objects - why ?

my app MUST be linked with '-z muldefs' because it MUST use another stdio 
implementation . 

For some reason, ONLY replacing the new glibc installed objects and running
ldconfig(1), without rebuilding, causes gtk+ to link to newer versions of
libselinux.so.1 that use __getdelim() that gets invoked in its init() section.

But ld(1) and ld.so(1) on Solaris are capable of detecting such mistakes 
at link time - why can't Linux ld(1) and ld.so(1) be equally capable?

Because on Solaris you can define the SFIO libraries as an "interposer" so 
that if objects are not found within them to satisfy links required by other
groups of objects before libc objects are used could trigger a link time error.
Then the whole app could be linked with '-z,defs' (the default) and just
the linkage order is enough to ensure that ONLY SFIO objects are used for
SFIO input/output; use of the SFIO object returned by fopen() with glibc
stdio triggers an early stack corruption on new glibc UNLESS __getdelim() is
defined - it now is!

If ld(1) and perhaps also ld.so(1) had some kind of "--interposer" or
"--dynamic-(no?)muldefs" option that both honored, then if a symbol not
found in that module did not satisfy the load requirments of another
group, then ld.so(1) could raise an error with '--dynamic-nomuldefs' if
a symbol that is defined or by in an object in a interposer group ( eg. 
SFIO's stdio file descriptor global definitions ( or perhaps even
 was created by malloc within the scope of functions defined in
objects in that group!)) and is then found ONLY in glibc 
then an error could be raised ; with '--dynamic-muldefs', the FIRST
interposer for eg the 'stdio' group of objects will always be
used ( the current default ). ie. by including the SFIO module first, while
with the required '--whole-archive,-z,muldefs' ld option + ld.so 
--dynamic-muldefs option, all of its objects MUST override the references to
them in all subsequent load modules, including in init() sections. Possible?

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10071

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10071] 2.9.90 (2009-04-14) libio/genops.c : __underflow() does not handle NULL FP

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10071

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.