Comment 2 for bug 286334

It works just under gcc-4.2. If I use -O0 under gcc-4.3 then it is also fine, but even -O1 is sufficient for the crash.

$ ./configure CC=gcc-4.2 # works
$ ./configure OPT="-g -O0" # works
$ ./configure OPT="-g -O1" # splat

Running gdb on the binary I get this:

(gdb) bt
#0 0x00000036c6432fd5 in raise () from /lib/libc.so.6
#1 0x00000036c6434b43 in abort () from /lib/libc.so.6
#2 0x00000036c6473fa8 in ?? () from /lib/libc.so.6
#3 0x00000036c64ff887 in __fortify_fail () from /lib/libc.so.6
#4 0x00000036c64fd750 in __chk_fail () from /lib/libc.so.6
#5 0x00000036c64fde0b in __realpath_chk () from /lib/libc.so.6
#6 0x0000000000478733 in PySys_SetArgv (argc=<value optimized out>, argv=0x7fff2a3f6868) at /usr/include/bits/stdlib.h:44
#7 0x000000000041192e in Py_Main (argc=4, argv=0x7fff2a3f6858) at Modules/main.c:386
#8 0x00000000004112a5 in main (argc=485, argv=0x1e5) at Modules/python.c:23

To get to the code that is crashing, this is effectively what is happening:

    char *argv0="./setup.py"; /* a member of argv passed to main */
    char fullpath[PATH_MAX];

    if(argc > 0 && argv0 != NULL)
       if (realpath(argv0, fullpath))
          argv0=fullpath;

The realpath call is where things are dying. PATH_MAX is 1024 hence that is the size of fullpath. The realpath output will trivially fit in fullpath. Either the realpath implementation really does need more than 1kb of space to do its calculations or this is a false positive with the fortify stuff getting it wrong.

The current Python code uses MAXPATHLEN instead of PATH_MAX and doesn't trigger whatever voodoo is whining in realpath. This is a workaround:

$ ./configure OPT="-O3 -DPATH_MAX=4096"