Project

General

Profile

Backport #5851

make check fails when compiling with GCC 4.7 - *** longjmp causes uninitialized stack frame ***

Added by vo.x (Vit Ondruch) over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
[ruby-core:41941]

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


Related issues

Related to Ruby master - Bug #5933: thin と Rack::FiberPool で SEGV が発生Closed01/26/2012Actions
Related to Ruby master - Bug #5076: Mac OS X Lion Support Closed03/14/2011Actions

Associated revisions

Revision 34278
Added by naruse (Yui NARUSE) over 7 years ago

  • cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
    reserving a memory space with ALLOCA_N for restoring machine stack
    stored in cont->machine_stack, but clang optimized out it (and
    maybe #5851 is also caused by this).
    This affected TestContinuation#test_check_localvars.

  • cont.c (cont_restore_1): revert workaround introduced in r32201.

Revision 34278
Added by naruse (Yui NARUSE) over 7 years ago

  • cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
    reserving a memory space with ALLOCA_N for restoring machine stack
    stored in cont->machine_stack, but clang optimized out it (and
    maybe #5851 is also caused by this).
    This affected TestContinuation#test_check_localvars.

  • cont.c (cont_restore_1): revert workaround introduced in r32201.

Revision 34278
Added by naruse (Yui NARUSE) over 7 years ago

  • cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
    reserving a memory space with ALLOCA_N for restoring machine stack
    stored in cont->machine_stack, but clang optimized out it (and
    maybe #5851 is also caused by this).
    This affected TestContinuation#test_check_localvars.

  • cont.c (cont_restore_1): revert workaround introduced in r32201.

Revision 34278
Added by naruse (Yui NARUSE) over 7 years ago

  • cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
    reserving a memory space with ALLOCA_N for restoring machine stack
    stored in cont->machine_stack, but clang optimized out it (and
    maybe #5851 is also caused by this).
    This affected TestContinuation#test_check_localvars.

  • cont.c (cont_restore_1): revert workaround introduced in r32201.

Revision 34278
Added by naruse (Yui NARUSE) over 7 years ago

  • cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
    reserving a memory space with ALLOCA_N for restoring machine stack
    stored in cont->machine_stack, but clang optimized out it (and
    maybe #5851 is also caused by this).
    This affected TestContinuation#test_check_localvars.

  • cont.c (cont_restore_1): revert workaround introduced in r32201.

Revision 34278
Added by naruse (Yui NARUSE) over 7 years ago

  • cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
    reserving a memory space with ALLOCA_N for restoring machine stack
    stored in cont->machine_stack, but clang optimized out it (and
    maybe #5851 is also caused by this).
    This affected TestContinuation#test_check_localvars.

  • cont.c (cont_restore_1): revert workaround introduced in r32201.

Revision 34288
Added by kosaki (Motohiro KOSAKI) over 7 years ago

merge revision(s) 34278:

* cont.c (cont_restore_0): prevent optimizing out `sp'. sp is used for
  reserving a memory space with ALLOCA_N for restoring machine stack
  stored in cont->machine_stack, but clang optimized out it (and
  maybe #5851 is also caused by this).
  This affected TestContinuation#test_check_localvars.

* cont.c (cont_restore_1): revert workaround introduced in r32201.

History

#1

Updated by kosaki (Motohiro KOSAKI) over 7 years ago

Please send us patch.

#2

Updated by luislavena (Luis Lavena) over 7 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) over 7 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) over 7 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) over 7 years ago

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

Updated by Anonymous over 7 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) over 7 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) over 7 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) over 7 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) over 7 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?

#11

Updated by naruse (Yui NARUSE) over 7 years ago

  • Tracker changed from Bug to Backport
  • Project changed from Ruby master to Backport193

Updated by kosaki (Motohiro KOSAKI) over 7 years ago

  • Status changed from Open to Closed

backported as r34288.

Also available in: Atom PDF