Backport #5851
closedmake check fails when compiling with GCC 4.7 - *** longjmp causes uninitialized stack frame ***
Description
I am experiencing strange test error [1] when compiling Ruby 1.9.3-p0/1.9.3-p19/2.0.0 rev 34217 with GCC 4.7 in Fedora Rawhide [2]. Everything worked just fine with GCC 4.6.
Vit
[1] https://gist.github.com/1564328
[2] http://koji.fedoraproject.org/koji/taskinfo?taskID=3624339
Updated by luislavena (Luis Lavena) almost 13 years ago
Can you provide a simple example that reproduces this?
Have you tried compiling with debug symbols and go over GDB?
Can you provide information of the resulting GCC flags of configure that were used to generate the libruby.so and ruby executable?
Have you tried -fno-omit-frame-pointer?
Updated by vo.x (Vit Ondruch) almost 13 years ago
Hi Luis,
You can find the GCC glags in the build.log [1]. I was using the following settings: CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables'. I will try the flags you are suggesting.
BTW with -O0, it passes (unfortunately fails in other test) and with -O1, I get a bit more verbose output [2]. And this [3] is the backtrace I obtained using GBD.
[1] http://koji.fedoraproject.org/koji/getfile?taskID=3624341&name=build.log
[2] https://gist.github.com/1582632
[3] https://gist.github.com/1582640
Updated by vo.x (Vit Ondruch) almost 13 years ago
It reminds me issue #5244. I would say that the _setjmp/_longjmp is causing the troubles, but I am not yet sure why :/
Updated by naruse (Yui NARUSE) almost 13 years ago
It works on FreeBSD 9.0 amd 64 with gcc47 (FreeBSD Ports Collection) 4.7.0 20111217 (experimental)
Updated by Anonymous almost 13 years ago
This test fails for me, too - using "gcc version 4.7.0 20120106 (Red Hat 4.7.0-0.5) (GCC)".
If I, however, compile the file cont.c with CFLAG -O0, the test passes, so I guess the problem has to be somewhere in it.
Updated by vo.x (Vit Ondruch) almost 13 years ago
Valgrind output when compiling with -O1:
Running tests:¶
==8685== Invalid write of size 8
==8685== at 0x4FDA9E8: cont_restore_1 (cont.c:675)
==8685== by 0x4FDAA12: cont_restore_0 (cont.c:771)
==8685== by 0x4FDAB0E: rb_cont_call (cont.c:910)
==8685== by 0x4FB8D90: call_cfunc (vm_insnhelper.c:317)
==8685== by 0x4FB96A8: vm_call_cfunc (vm_insnhelper.c:404)
==8685== by 0x4FB9D7F: vm_call_method (vm_insnhelper.c:534)
==8685== by 0x4FBF772: vm_exec_core (insns.def:1015)
==8685== by 0x4FCCF77: vm_exec (vm.c:1220)
==8685== by 0x4FCB870: invoke_block_from_c (vm.c:624)
==8685== by 0x4FCB986: vm_yield (vm.c:654)
==8685== by 0x4FC7D93: rb_yield_0 (vm_eval.c:740)
==8685== by 0x4FC7DCD: rb_yield (vm_eval.c:750)
==8685== Address 0x7feffad00 is not stack'd, malloc'd or (recently) free'd
==8685==
*** longjmp causes uninitialized stack frame ***: ./ruby terminated
Updated by naruse (Yui NARUSE) almost 13 years ago
Can you disassemble cont_restore_0?
I doubt your gcc 4.7 optimized out the content of cont_restore_0.
Updated by naruse (Yui NARUSE) almost 13 years ago
Yui NARUSE wrote:
Can you disassemble cont_restore_0?
I doubt your gcc 4.7 optimized out the content of cont_restore_0.
Maybe r34278 fixes this.
Updated by vo.x (Vit Ondruch) almost 13 years ago
Yes, it fixes the SEGV it seems. Thank you! Could you backport it for 1.9.3? Should I open new ticket for backport?
Updated by naruse (Yui NARUSE) almost 13 years ago
- Tracker changed from Bug to Backport
- Project changed from Ruby master to Backport193
Updated by kosaki (Motohiro KOSAKI) almost 13 years ago
- Status changed from Open to Closed
backported as r34288.