headers
Translation Project Robot | 2 Sep 2007 12:52

New Dutch PO file for 'm4' (version 1.4o)

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'm4' has been submitted
by the Dutch team of translators.  The file is available at:

    http://translationproject.org/latest/m4/nl.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/m4/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/m4.html

If any question arises, please contact the translation coordinator.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alf mel | 15 Sep 2007 16:26

Configure problem when compiling with -D_FORTIFY_SOURCE

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]
(Continue reading)

Permalink | Reply | 12 comments |
headers
Eric Blake | 15 Sep 2007 19:30
Gravatar

Re: Configure problem when compiling with -D_FORTIFY_SOURCE


According to Alf mel on 9/15/2007 8:26 AM:
> 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".

Thanks for the report.  This might be a bug in Bruno's code for checking
the characteristics of the system printf, so I'm forwarding it to the
gnulib list for him to comment on.

> 
> 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]
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bruno Haible | 15 Sep 2007 23:31

Re: Configure problem when compiling with -D_FORTIFY_SOURCE

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
(Continue reading)

Permalink | Reply | 8 comments |
headers
Greg Schafer | 16 Sep 2007 03:09
Picon
Picon

Re: Configure problem when compiling with -D_FORTIFY_SOURCE

Bruno Haible wrote:

> 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?

Posting here for review first:

$ cat foo.c
#include <stdio.h>

static char buf[100];
int main ()
{
#  define LDBL80_WORDS(exponent,manthi,mantlo)      { mantlo, manthi, exponent }
  { /* Pseudo-Infinity.  */
    static union { unsigned int word[4]; long double value; } x =
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bruno Haible | 16 Sep 2007 03:36

Re: Configure problem when compiling with -D_FORTIFY_SOURCE

Greg Schafer wrote:
> Posting here for review first:

Thanks.

> $ cat foo.c
> #include <stdio.h>
> 
> static char buf[100];
> int main ()
> {
> #  define LDBL80_WORDS(exponent,manthi,mantlo)      { mantlo, manthi, exponent }
>   { /* Pseudo-Infinity.  */
>     static union { unsigned int word[4]; long double value; } x =
>       { LDBL80_WORDS (0xFFFF, 0x00000000, 0x00000000) };
>     if (sprintf (buf, "%Lf", x.value) < 0)
>       return 1;
>   }
>   return 0;
> }

It could be that the buffer that is too small is this 'buf' here, not
something in glibc. Does the buffer overflow persist if you increase
its size from 100 to 1000000, and/or if you use asprintf instead of sprintf?

Bruno
Permalink | Reply | 4 comments |
headers
Greg Schafer | 16 Sep 2007 03:48
Picon
Picon

Re: Configure problem when compiling with -D_FORTIFY_SOURCE

Bruno Haible wrote:

> It could be that the buffer that is too small is this 'buf' here, not
> something in glibc. Does the buffer overflow persist if you increase
> its size from 100 to 1000000, and/or if you use asprintf instead of sprintf?

Size of 10000 seems to work. Size of 1000 doesn't. Using asprintf also
seems to not crash with a size of 100.

Regards
Greg
Permalink | Reply | 2 comments |
headers
Bruno Haible | 16 Sep 2007 13:41

Re: Configure problem when compiling with -D_FORTIFY_SOURCE

Greg Schafer wrote:
> Size of 10000 seems to work. Size of 1000 doesn't. Using asprintf also
> seems to not crash with a size of 100.

OK, then the bug is in gnulib's tests, not in glibc. Thanks for these tests.

I'm applying this:

2007-09-16  Bruno Haible  <bruno <at> clisp.org>

	* m4/printf.m4 (gl_PRINTF_LONG_DOUBLE, gl_PRINTF_INFINITE,
	gl_PRINTF_INFINITE_LONG_DOUBLE): Increase buf's size from 100 to 10000.
	Needed on glibc-2.6.1 with -fstack-protector -D_FORTIFY_SOURCE=2.
	Reported by Greg Schafer <gschafer <at> zip.com.au>.

--- m4/printf.m4	13 Jun 2007 01:28:35 -0000	1.35
+++ m4/printf.m4	16 Sep 2007 11:40:01 -0000
 <at>  <at>  -1,4 +1,4  <at>  <at> 
-# printf.m4 serial 15
+# printf.m4 serial 16
 dnl Copyright (C) 2003, 2007 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
 <at>  <at>  -95,7 +95,7  <at>  <at> 
       AC_TRY_RUN([
 #include <stdio.h>
 #include <string.h>
-static char buf[100];
+static char buf[10000];
 int main ()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Piotr Tarnowski | 27 Sep 2007 10:26
Picon
Favicon

m4 tests failed


<pre>
Machine hardware:   sun4u
OS version:         5.10
Processor type:     sparc
Hardware:           SUNW,Sun-Fire-V890

The following components are installed on your system:

Sun Studio 12
        Sun Studio 12 C Compiler
        Sun Studio 12 C++ Compiler
        Sun Studio 12 Tools.h++ 7.1
        Sun Studio 12 C++ Standard 64-bit Class Library
        Sun Studio 12 Garbage Collector
        Sun Studio 12 Fortran 95
        Sun Studio 12 Debugging Tools (including dbx)
        Sun Studio 12 IDE
        Sun Studio 12 Debugger GUI
        Sun Studio 12 Performance Analyzer (including collect, ...)
        Sun Studio 12 X-Designer
        Sun Studio 12 VIM editor
        Sun Studio 12 XEmacs editor
        Sun Studio 12 Performance Library
        Sun Studio 12 LockLint
        Sun Studio 12 Building Software (including dmake)
        Sun Studio 12 Documentation Set
        Sun Studio 12 /usr symbolic links and GNOME menu item

version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Blake | 27 Sep 2007 14:14
Gravatar

Re: m4 tests failed


According to Piotr Tarnowski on 9/27/2007 2:26 AM:

Hi Piotr, and thanks for the report.  Can you please rerun with 'make -k
check' to ensure the rest of the testsuite is okay?

> Machine hardware:   sun4u
> OS version:         5.10
> Processor type:     sparc
> Hardware:           SUNW,Sun-Fire-V890
> 
> version of "/opt/SUNWspro/bin/../prod/bin/../../bin/cc": Sun C 5.9
> SunOS_sparc Patch 124867-01 2007/07/12
> test-vasprintf-posix.c:164: assertion failed
> /bin/bash: line 1: 22623 Abort                   (core dumped) EXEEXT=''
> EXEEXT='' EXEEXT='' srcdir='.' EXEEXT='' srcdir='.' EXEEXT='' srcdir='.'
> ${dir}$tst
> FAIL: test-vasprintf-posix

This would indicate a bug in the gnulib *printf replacements.  That
particular line is:

    char *result;
    int retval =
      my_asprintf (&result, "%Lg %d", (long double) 1.5, 33, 44, 55);
    ASSERT (result != NULL);
    ASSERT (strcmp (result, "1.5 33") == 0);

So, what _did_ your compiler/C library print instead of the expected "1.5"
when printing the long double value 1.5?  Also, attaching config.log would
(Continue reading)

Permalink | Reply | 0 comments |

Gmane