bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configure problem when compiling with -D_FORTIFY_SOURCE


From: Bruno Haible
Subject: Re: Configure problem when compiling with -D_FORTIFY_SOURCE
Date: Sat, 15 Sep 2007 23:31:58 +0200
User-agent: KMail/1.5.4

Alf mel wrote:
> > While trying out the lastest offerings in Glibc (2.6.1) and GCC (4.2.1) via
> > the DIY-Linux project (www.diy-linux-.org), I encountered the following
> > error in the configure script when compiled with
> >
> >     CFLAGS="-O2 -fstack-protector -D_FORTIFY_SOURCE=2".
> >
> > Here is what I get:
> >
> > checking whether printf supports size specifiers as in C99... yes
> > checking whether printf supports 'long double' arguments... yes
> > checking whether printf supports infinite 'double' arguments... yes
> > checking whether printf supports infinite 'long double' arguments... ***
> > buffer overflow detected ***: ./conftest terminated
> > ======= Backtrace: =========
> > /lib/libc.so.6(__chk_fail+0x41)[0xb7ed4191]
> > /lib/libc.so.6[0xb7ed3998]
> > /lib/libc.so.6(_IO_default_xsputn+0xb7)[0xb7e53d47]
> > /lib/libc.so.6(__printf_fp+0x6a9)[0xb7e30559]
> > /lib/libc.so.6(_IO_vfprintf+0x3c7)[0xb7e2b877]
> > /lib/libc.so.6(__vsprintf_chk+0xad)[0xb7ed3a4d]
> > /lib/libc.so.6(__sprintf_chk+0x30)[0xb7ed3980]
> > ./conftest[0x8048d11]
> > /lib/libc.so.6(__libc_start_main+0xe0)[0xb7e03f90]
> > ./conftest[0x8048311]
> > ======= Memory map: ========
> > 08048000-0804a000 r-xp 00000000 08:06
> > 6295768    /var/local/slim/build/m4/source/m4-1.4.10/conftest
> > 0804a000-0804b000 rw-p 00001000 08:06
> > 6295768    /var/local/slim/build/m4/source/m4-1.4.10/conftest
> > 0804b000-0806c000 rw-p 0804b000 00:00 0          [heap]
> > b7de2000-b7dec000 r-xp 00000000 08:01 134        /usr/lib/libgcc_s.so.1
> > b7dec000-b7ded000 rw-p 00009000 08:01 134        /usr/lib/libgcc_s.so.1
> > b7ded000-b7dee000 rw-p b7ded000 00:00 0
> > b7dee000-b7f2d000 r-xp 00000000 08:01 20983511   /lib/libc-2.6.1.so
> > b7f2d000-b7f2f000 r--p 0013f000 08:01 20983511   /lib/libc-2.6.1.so
> > b7f2f000-b7f30000 rw-p 00141000 08:01 20983511   /lib/libc-2.6.1.so
> > b7f30000-b7f34000 rw-p b7f30000 00:00 0
> > b7f37000-b7f53000 r-xp 00000000 08:01 20983504   /lib/ld-2.6.1.so
> > b7f53000-b7f54000 r--p 0001b000 08:01 20983504   /lib/ld-2.6.1.so
> > b7f54000-b7f55000 rw-p 0001c000 08:01 20983504   /lib/ld-2.6.1.so
> > bfad6000-bfaec000 rw-p bfad6000 00:00 0          [stack]
> > ffffe000-fffff000 r-xp 00000000 00:00 0          [vdso]
> > no

This configure test and how glibc should handle printing of random bitpatterns
was subject of a bug report
  http://sourceware.org/bugzilla/show_bug.cgi?id=4586
and a lengthy discussion. The bug was fixed by Jakub Jelinek in July 2007;
the fix should be contained in glibc-2.6.1. Summarizing the discussion:
While Ulrich Drepper and Andreas Schwab denied that glibc was doing anything
wrong, others thought that glibc should not crash on random bitpatterns passed
as floating-point numbers.

It appears that the crash is gone, but either a buffer overflow is still
present, or some source code annotations for bounds checking needs to be
added to __printf_fp and related functions.

Can you first reduce the failed configure program (copy & paste from config.log)
to a test case as small as possible, and then report it in the glibc bug
tracker?

> > The buffer overflow doesn't seem to change the result of the test in our
> > systems.

It is normal that this test says "no" on glibc systems: The gnulib test
expects some particular output for invalid numbers; glibc only guarantees
not to crash, and returns output that does not make much sense.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]