Backport #5851: make check fails when compiling with GCC 4.7 - *** longjmp causes uninitialized stack frame ***

• Status: Closed
• Assignee: -

[vo.x (Vit Ondruch)]

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

[kosaki (Motohiro KOSAKI)]

Please send us patch.

[luislavena (Luis Lavena)]

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?

[vo.x (Vit Ondruch)]

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

[vo.x (Vit Ondruch)]

It reminds me issue #5244. I would say that the _setjmp/_longjmp is causing the troubles, but I am not yet sure why :/

[naruse (Yui NARUSE)]

It works on FreeBSD 9.0 amd 64 with gcc47 (FreeBSD Ports Collection) 4.7.0 20111217 (experimental)

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.

[vo.x (Vit Ondruch)]

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

[naruse (Yui NARUSE)]

Can you disassemble cont_restore_0?
I doubt your gcc 4.7 optimized out the content of cont_restore_0.

[naruse (Yui NARUSE)]

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.

[vo.x (Vit Ondruch)]

Yes, it fixes the SEGV it seems. Thank you! Could you backport it for 1.9.3? Should I open new ticket for backport?

[naruse (Yui NARUSE)]

• Tracker changed from Bug to Backport
• Project changed from Ruby to 13

[kosaki (Motohiro KOSAKI)]

• Status changed from Open to Closed

backported as r34288.