make check goes to core dump when compiled with CFLAGS="-m64 -O2" within others

[GoogleCodeExporter]

$ export CFLAGS="-m64 -L/usr/lib64 -march=native -funroll-loops -O2 -pipe 
-fstack-protector"
$ ./configure --prefix=/usr --manprefix=/usr/share 
--examplesdir="/usr/share/turnserver/examples" --disable-rpath && make -j4 && 
make check

...skip
bin/turnutils_rfc5769check
RFC 5769 message fingerprint test(0) result: success
...skip all tests succeeded
RFC 5769 IPv6 encoding result: success
*** stack smashing detected ***: bin/turnutils_rfc5769check terminated
======= Backtrace: =========
/usr/lib/libc.so.6(+0x72d7f)[0x7fb92b011d7f]
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7fb92b094b17]
/usr/lib/libc.so.6(__fortify_fail+0x0)[0x7fb92b094ae0]
bin/turnutils_rfc5769check[0x40290e]
/usr/lib/libc.so.6(__libc_start_main+0xf5)[0x7fb92afc0b05]
bin/turnutils_rfc5769check[0x402949]
======= Memory map: ========
00400000-0040e000 r-xp 00000000 08:02 2204459                            
/tmp/turnserver/src/turnserver-3.2.2.5/bin/turnutils_rfc5769check
0060d000-0060e000 r--p 0000d000 08:02 2204459                            
/tmp/turnserver/src/turnserver-3.2.2.5/bin/turnutils_rfc5769check
0060e000-0060f000 rw-p 0000e000 08:02 2204459                            
/tmp/turnserver/src/turnserver-3.2.2.5/bin/turnutils_rfc5769check
0060f000-0061f000 rw-p 00000000 00:00 0 
0184c000-0186d000 rw-p 00000000 00:00 0                                  [heap]
7fb92a96f000-7fb92a984000 r-xp 00000000 08:02 306963                     
/usr/lib/libgcc_s.so.1
7fb92a984000-7fb92ab84000 ---p 00015000 08:02 306963                     
/usr/lib/libgcc_s.so.1
7fb92ab84000-7fb92ab85000 rw-p 00015000 08:02 306963                     
/usr/lib/libgcc_s.so.1
7fb92ab85000-7fb92ab9a000 r-xp 00000000 08:02 307007                     
/usr/lib/libz.so.1.2.8
7fb92ab9a000-7fb92ad99000 ---p 00015000 08:02 307007                     
/usr/lib/libz.so.1.2.8
7fb92ad99000-7fb92ad9a000 r--p 00014000 08:02 307007                     
/usr/lib/libz.so.1.2.8
7fb92ad9a000-7fb92ad9b000 rw-p 00015000 08:02 307007                     
/usr/lib/libz.so.1.2.8
7fb92ad9b000-7fb92ad9e000 r-xp 00000000 08:02 968266                     
/usr/lib/libdl-2.18.so
7fb92ad9e000-7fb92af9d000 ---p 00003000 08:02 968266                     
/usr/lib/libdl-2.18.so
7fb92af9d000-7fb92af9e000 r--p 00002000 08:02 968266                     
/usr/lib/libdl-2.18.so
7fb92af9e000-7fb92af9f000 rw-p 00003000 08:02 968266                     
/usr/lib/libdl-2.18.so
7fb92af9f000-7fb92b13f000 r-xp 00000000 08:02 968235                     
/usr/lib/libc-2.18.so
7fb92b13f000-7fb92b33f000 ---p 001a0000 08:02 968235                     
/usr/lib/libc-2.18.so
7fb92b33f000-7fb92b343000 r--p 001a0000 08:02 968235                     
/usr/lib/libc-2.18.so
7fb92b343000-7fb92b345000 rw-p 001a4000 08:02 968235                     
/usr/lib/libc-2.18.so
7fb92b345000-7fb92b349000 rw-p 00000000 00:00 0 
7fb92b349000-7fb92b361000 r-xp 00000000 08:02 968202                     
/usr/lib/libpthread-2.18.so
7fb92b361000-7fb92b560000 ---p 00018000 08:02 968202                     
/usr/lib/libpthread-2.18.so
7fb92b560000-7fb92b561000 r--p 00017000 08:02 968202                     
/usr/lib/libpthread-2.18.so
7fb92b561000-7fb92b562000 rw-p 00018000 08:02 968202                     
/usr/lib/libpthread-2.18.so
7fb92b562000-7fb92b566000 rw-p 00000000 00:00 0 
7fb92b566000-7fb92b58f000 r-xp 00000000 08:02 411890                     
/usr/lib/libevent_core-2.0.so.5.1.9
7fb92b58f000-7fb92b78f000 ---p 00029000 08:02 411890                     
/usr/lib/libevent_core-2.0.so.5.1.9
7fb92b78f000-7fb92b790000 r--p 00029000 08:02 411890                     
/usr/lib/libevent_core-2.0.so.5.1.9
7fb92b790000-7fb92b791000 rw-p 0002a000 08:02 411890                     
/usr/lib/libevent_core-2.0.so.5.1.9
7fb92b791000-7fb92b7f7000 r-xp 00000000 08:02 316976                     
/usr/lib/libssl.so.1.0.0
7fb92b7f7000-7fb92b9f6000 ---p 00066000 08:02 316976                     
/usr/lib/libssl.so.1.0.0
7fb92b9f6000-7fb92b9fa000 r--p 00065000 08:02 316976                     
/usr/lib/libssl.so.1.0.0
7fb92b9fa000-7fb92ba00000 rw-p 00069000 08:02 316976                     
/usr/lib/libssl.so.1.0.0
7fb92ba00000-7fb92ba01000 rw-p 00000000 00:00 0 
7fb92ba01000-7fb92bc14000 r-xp 00000000 08:02 316979                     
/usr/lib/libcrypto.so.1.0.0
7fb92bc14000-7fb92be13000 ---p 00213000 08:02 316979                     
/usr/lib/libcrypto.so.1.0.0
7fb92be13000-7fb92be2e000 r--p 00212000 08:02 316979                     
/usr/lib/libcrypto.so.1.0.0
7fb92be2e000-7fb92be3a000 rw-p 0022d000 08:02 316979                     
/usr/lib/libcrypto.so.1.0.0
7fb92be3a000-7fb92be3e000 rw-p 00000000 00:00 0 
7fb92be3e000-7fb92be5e000 r-xp 00000000 08:02 968218                     
/usr/lib/ld-2.18.so
7fb92c018000-7fb92c019000 rw-p 00000000 00:00 0 
7fb92c019000-7fb92c01a000 rw-p 00000000 00:00 0 
7fb92c01a000-7fb92c01b000 rw-p 00000000 00:00 0 
7fb92c01b000-7fb92c01c000 rw-p 00000000 00:00 0 
7fb92c01c000-7fb92c01d000 rw-p 00000000 00:00 0 
7fb92c01d000-7fb92c01e000 rw-p 00000000 00:00 0 
7fb92c05b000-7fb92c05c000 rw-p 00000000 00:00 0 
7fb92c05c000-7fb92c05d000 rw-p 00000000 00:00 0 
7fb92c05d000-7fb92c05e000 r--p 0001f000 08:02 968218                     
/usr/lib/ld-2.18.so
7fb92c05e000-7fb92c05f000 rw-p 00020000 08:02 968218                     
/usr/lib/ld-2.18.so
7fb92c05f000-7fb92c060000 rw-p 00000000 00:00 0 
7fff45646000-7fff45668000 rw-p 00000000 00:00 0                          [stack]
7fff457f0000-7fff457f2000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  
[vsyscall]
Makefile:90: ошибка выполнения рецепта для цели 
«check»
make: *** [check] Аварийный останов (сделан дамп 
памяти)

Linux di 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 
GNU/Linux
turnserver-3.2.2.5
archlinux

I don`t know could that produce a bug in a working app, but at least it will be 
usefull to put warnings about compilation flags to the docs.

Original issue reported on code.google.com by dimitri....@gmail.com on 8 Feb 2014 at 2:19

[GoogleCodeExporter]

Thanks for reporting.

I am trying to reproduce the problem on exactly the same system (archlinux 
3.12.9-2 SMP with all the same libraries, and I use exactly the same command 
lines) and I failed to see any problem. The only difference is that I used 
version 3.2.2.6 (pre-release) but that must make no difference.

There are several very strange things:

1) The line "RFC 5769 IPv6 encoding result: success" means that the program 
completed successfully - the next instruction is just "return 0" from the main 
function - so how come there may be a problem AFTER that ?

2) If you are running it on a x86_64 system, then what are you trying to 
achieve with options "-m64 -march=native" ?

3) Is that possible that you ran the configuration and the compilation with 
option -m32, then you did not run "make clean" and then you tried immediately 
"-m64" ? That would explain the problem.

4) The Makefile was written for sequential execution - it was not designed for 
parallel tasks and it was not tested as such. May be "make -j4" is the problem 
in your case.

So, I am sking you to:

1) Do "make clean" before the build process.
2) Remove -j4 option.
3) If the problem still exist, could you please run it in the debugger ? Add 
option -g and run the program bin/turnutils_rfc5769check in gdb.

Thanks
Oleg

Original comment by mom040...@gmail.com on 8 Feb 2014 at 11:38

• Changed state: Cannotreproduceneedmoreinformation

[GoogleCodeExporter]

Original comment by mom040...@gmail.com on 8 Feb 2014 at 11:39

• Changed state: CannotReproduceNeedMoreInformation

[GoogleCodeExporter]

Another thing that I suspect is that the stack protector may be somehow is 
responsible for the message. 

Original comment by mom040...@gmail.com on 9 Feb 2014 at 12:08

[GoogleCodeExporter]

I'll fix it if I'll have information how to reproduce it reliably.

Original comment by mom040...@gmail.com on 9 Feb 2014 at 7:23

• Changed state: WontFix

[GoogleCodeExporter]

Can`t reproduce this morning.
I think that behaviour was caused by the kernel updated in previous step 
without rebooting.
I`m sorry. You can close the bug.

Original comment by dimitri....@gmail.com on 9 Feb 2014 at 9:00