http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54012
--- Comment #9 from Sergey Rodionov <astroseger at gmail dot com> 2012-10-30
19:35:15 UTC ---
>
> This does not look like a libgfortran issue. Do you have
> valgrind on your system? Can you run the good and bad
> executable under valgrind? This appears to be a buffer
> issue in your libc.
1. I have this bug on 3 different computers with installed magiea 2 x86_64
2. Yes, it is very strange. It not look like libgfortran issue, but if I
compile without -l gfortran it works.
3. If I compile with -static it always works.
4. Just in case
"ldd good" looks like:
linux-vdso.so.1 => (0x00007fffe4f54000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc68961c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc6899a8000)
"ldd bad":
linux-vdso.so.1 => (0x00007fffd97ff000)
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f74e86ad000)
libc.so.6 => /lib64/libc.so.6 (0x00007f74e8321000)
libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f74e80ec000)
libm.so.6 => /lib64/libm.so.6 (0x00007f74e7e6a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f74e89c3000)
so they use the same libc
5. valgrind with "bad" says:
==26497== Memcheck, a memory error detector
==26497== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==26497== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==26497== Command: ./a.out
==26497==
==26497== Invalid read of size 1
==26497== at 0x51A58F2: __parse_one_specmb (in /lib64/libc-2.14.1.so)
==26497== by 0x518722F: vfprintf (in /lib64/libc-2.14.1.so)
==26497== by 0x5191178: printf (in /lib64/libc-2.14.1.so)
==26497== by 0x400519: main (in /home/seger/TEMP/a.out)
==26497== Address 0x4023b3 is not stack'd, malloc'd or (recently) free'd
==26497==
==26497==
==26497== Process terminating with default action of signal 11 (SIGSEGV)
==26497== Access not within mapped region at address 0x4023B3
==26497== at 0x51A58F2: __parse_one_specmb (in /lib64/libc-2.14.1.so)
==26497== by 0x518722F: vfprintf (in /lib64/libc-2.14.1.so)
==26497== by 0x5191178: printf (in /lib64/libc-2.14.1.so)
==26497== by 0x400519: main (in /home/seger/TEMP/a.out)
==26497== If you believe this happened as a result of a stack
==26497== overflow in your program's main thread (unlikely but
==26497== possible), you can try to increase the size of the
==26497== main thread stack using the --main-stacksize= flag.
==26497== The main thread stack size used in this run was 16777216.
==26497==
==26497== HEAP SUMMARY:
==26497== in use at exit: 3,769 bytes in 15 blocks
==26497== total heap usage: 19 allocs, 4 frees, 11,909 bytes allocated
==26497==
==26497== LEAK SUMMARY:
==26497== definitely lost: 0 bytes in 0 blocks
==26497== indirectly lost: 0 bytes in 0 blocks
==26497== possibly lost: 0 bytes in 0 blocks
==26497== still reachable: 3,769 bytes in 15 blocks
==26497== suppressed: 0 bytes in 0 blocks
==26497== Rerun with --leak-check=full to see details of leaked memory
==26497==
==26497== For counts of detected and suppressed errors, rerun with: -v
==26497== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
6. valgrind with good says that all ok...
quite strange :)
