Bug 257279 – configure scripts dump "%n in writable segment detected" when using _FORTIFY_SOURCE

• Status: RESOLVED INVALID
• Product: Gentoo Linux

[Description Martin Walch 2009-02-01 19:41:40 UTC]

At least in the configure scripts of sys-apps/coreutils-6.10-r2 and sys-devel/m4-1.4.12 (probably there are more packages) an error message is thrown:

*** %n in writable segment detected ***

They seem to compile and work fine, but this error message is very ugly as in a bash it can not be caught by piping stdout or stderr. The code snippet from config.log is in both cases:

| #include <stdio.h>
| #include <string.h>
| static char fmtstring[10];
| static char buf[100];
| int main ()
| {
|   int count = -1;
|   /* Copy the format string.  Some systems (glibc with _FORTIFY_SOURCE=2)
|      support %n in format strings in read-only memory but not in writable
|      memory.  */
|   strcpy (fmtstring, "%d %n");
|   if (sprintf (buf, fmtstring, 123, &count, 33, 44, 55) < 0
|       || strcmp (buf, "123 ") != 0
|       || count != 4)
|     return 1;
|   return 0;
| }

Probably this is just the case that is described in the C comment: glibc was compiled with gcc 4.3.3.

[Comment 1 Martin Walch 2009-02-01 19:43:07 UTC]

Created attachment 180602 [details]
/var/tmp/portage/sys-devel/m4-1.4.12/work/m4-1.4.12/config.log

config.log from interrupted (Ctrl+C) configure script

[Comment 2 Martin Walch 2009-02-01 19:44:06 UTC]

Created attachment 180603 [details]
/var/tmp/portage/sys-apps/coreutils-6.12-r2/work/coreutils-6.12/config.log

config.log from interrupted (Ctrl+C) configure script

[Comment 3 Rafał Mużyło 2009-02-02 21:07:52 UTC]

From the posts on mailing list, seems it was an intended change
in gcc 4.3.3 (it's in one of the patches).

Though, for anybody NOT tracking that list, it was a not really
pleasant surprise.

[Comment 4 Ryan Hill (RETIRED) 2009-02-02 22:52:39 UTC]

i would say it's working exactly as advertised.

[Comment 5 SpanKY 2009-02-03 00:59:28 UTC]

yep, not a glibc bug, nor gcc.  as Ryan says, everything is operating as designed.

[Comment 6 Martin Walch 2009-02-03 02:40:38 UTC]

In any case: I do not think it is a good idea to have random messages on bash that can not be controlled. So if gcc and glibc are working as they should - maybe I should ask upstream what they think about this. But who would be the right one? autoconf? automake? coreutils/m4? gcc? glibc?

[Comment 7 SpanKY 2009-02-03 05:25:05 UTC]

glibc itself opens up /dev/tty and writes the error/abort message to it thus bypassing stderr/stdout redirection.  it might be ugly, but it was done on purpose, and the glibc guys arent about to change it.

[Comment 8 Martin Walch 2009-02-03 09:51:07 UTC]

So I will ask autconf/automake (upstream) to change their test case with sprintf.

[Comment 9 SpanKY 2009-02-03 16:50:58 UTC]

except the test case in question is testing for this exact behavior.  it needs to know if using %n in a writable segment will fail.

[Comment 10 Zac Medico 2009-10-26 19:18:53 UTC]

When bug 278895 is fixed, this should no longer be an issue since we'll use a pty device for /dev/tty.

[Comment 11 SpanKY 2012-03-21 16:30:09 UTC]

*** Bug 408715 has been marked as a duplicate of this bug. ***