| Summary: | dev-lang/ruby-2.2.1 - make: *** [.rbconfig.time] Segmentation fault | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bertrand Jacquin <bertrand> |
| Component: | [OLD] Development | Assignee: | Gentoo Ruby Team <ruby> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | atoth, bertrand, c.apeltauer, captaincrutches, fordfrog, gentoo, hardened, jowr.pi, lucy, mike, mva |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.ruby-lang.org/issues/11030 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
emerge --info emerge --info (captaincrutches) build.log (captaincrutches) An strace of the segmentation fault. gcc-4.8-hardened emerge --info gcc-4.8.3-hardened build.log |
||
Created attachment 398438 [details]
build.log
Created attachment 398440 [details]
emerge --info
Looking at emerge --info it might be related to hardened and/or gcc 4.9. It might be helpful to test with gcc 4.8 if that is an option for you so we can narrow down where the problem is. (In reply to Hans de Graaff from comment #3) > Looking at emerge --info it might be related to hardened and/or gcc 4.9. It > might be helpful to test with gcc 4.8 if that is an option for you so we can > narrow down where the problem is. The same happens with gcc 4.8 hardened or not, or gcc 4.9 hardened or not. (In reply to Bertrand Jacquin from comment #4) > The same happens with gcc 4.8 hardened or not, or gcc 4.9 hardened or not. It works fine for me with gcc 4.8, so I guess we need to look elsewhere. I see in emerge --info output that you have LC_MESSAGES=C. I've tried building with that but that works fine for me. I'm guessing here but do you have any UTF8 locale configured on this machine? (In reply to Hans de Graaff from comment #5) > (In reply to Bertrand Jacquin from comment #4) > > > The same happens with gcc 4.8 hardened or not, or gcc 4.9 hardened or not. > > It works fine for me with gcc 4.8, so I guess we need to look elsewhere. I > see in emerge --info output that you have LC_MESSAGES=C. I've tried building > with that but that works fine for me. > > I'm guessing here but do you have any UTF8 locale configured on this machine? en_US ISO-8859-1 and en_US.UTF-8 UTF-8 are configured on the machine I can confirm this same issue, will attach my own emerge --info and build.log Created attachment 398560 [details]
emerge --info (captaincrutches)
Created attachment 398562 [details]
build.log (captaincrutches)
It would be helpful if someone who can reproduce this issue can try to narrow this down further by trying to debug that miniruby invocation. I'm also curious whether this also happens with ruby 2.2.0 ? ruby-2.2.0-r1 builds fine on the same setup. I'd love to try to help debug that miniruby call, but I'll admit this is a little out of my league. I'll do what I can from here, if anyone wants me to run/do something specific feel free to tell me here, or email me if you'd prefer not to clutter the bug thread. From what I can tell, no matter what arguments I give miniruby (including no arguments at all) it segfaults. Opening it up in gdb, I can't really get it to do much at all (which may be because I don't know much about how to use gdb), however it seems to happen after stepping through exactly 13 instructions. 0x00005555555784dd in main () (gdb) nexti Program received signal SIGSEGV, Segmentation fault. 0x0000555555737967 in reserve_stack () Maybe that means something to someone more versed in low-level debugging than me, but I'm afraid that's about all I can offer without further prompting. Here is a gdb trace:
$ gdb /var/tmp/portage/dev-lang/ruby-2.2.1/work/ruby-2.2.1/miniruby
..
(gdb) r -I./lib -I. -I.ext/common ./tool/mkconfig.rb -timestamp=.rbconfig.time \
-install_name=ruby22 \
-so_name=ruby22 rbconfig.rb
Starting program: /var/tmp/portage/dev-lang/ruby-2.2.1/work/ruby-2.2.1/miniruby -I./lib -I. -I.ext/common ./tool/mkconfig.rb -timestamp=.rbconfig.time -install_name=ruby22 -so_name=ruby22 rbconfig.rb
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00005555556fcfbf in reserve_stack (limit=0x7fffff7ff100 "", size=8384256) at thread_pthread.c:683
683 limit = alloca(buf - limit);
(gdb) bt
#0 0x00005555556fcfbf in reserve_stack (limit=0x7fffff7ff100 "", size=8384256) at thread_pthread.c:683
#1 0x00005555556ffe63 in ruby_init_stack (addr=<optimized out>) at thread_pthread.c:713
#2 0x0000555555576ec2 in main (argc=9, argv=0x7fffffffde38) at main.c:34
(gdb) fr 0
#0 0x00005555556fcfbf in reserve_stack (limit=0x7fffff7ff100 "", size=8384256) at thread_pthread.c:683
683 limit = alloca(buf - limit);
(gdb) info args
limit = 0x7fffff7ff100 ""
size = 8384256
(gdb) fr 1
#1 0x00005555556ffe63 in ruby_init_stack (addr=<optimized out>) at thread_pthread.c:713
713 reserve_stack(stackaddr, size);
(gdb) info args
addr = <optimized out>
(gdb) fr 2
#2 0x0000555555576ec2 in main (argc=9, argv=0x7fffffffde38) at main.c:34
34 RUBY_INIT_STACK;
(gdb) info args
argc = 9
argv = 0x7fffffffde38
I can confirm that too, although, I'm using Hardened GCC and UTF-8 too. Is it any useful, that I can provide? (In reply to Hans de Graaff from comment #10) > It would be helpful if someone who can reproduce this issue can try to > narrow this down further by trying to debug that miniruby invocation. > > I'm also curious whether this also happens with ruby 2.2.0 ? This issue did not occur for me with 2.2.0, however it is dinging me on 2.2.1. Here's an strace of the miniruby failure. Created attachment 399580 [details]
An strace of the segmentation fault.
If you need more in depth debugging, guide me a bit and I'll help out.
I am having the same error on a gcc-4.8 hardened system. However on another system not hardened with gcc 4.9 I have no problems. I tracked down a little the problem. It come from a call to alloca (to reserve space on the stack) with a size too big. alloca segfault when too much memory is asked ( see the man page ). The call come frome the reserve_stack function. This function was added in ruby 2.2.1 by this commit http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/tags/v2_2_1/thread_pthread.c?r1=48992&r2=49578&diff_format=h . From what I understand this function force the kernel to fully allocate the maximum stack size available to avoid futur SIGBUS. I think there is a bug in the way the function compute the size it passes to alloca because if I substract 10k to the size it work. Also removing the call to reserve_stack works too. ( I suppose that if you did not have any SIGBUS problem with 2.0.0 you won't with 2.1.0 and you can remove the call as a temporary *dangerous* fix ) I think the bug is trigger on hardened system by a protection against stack overflow. So it seems to a bug for upstream ruby rather than gentoo. I too can verify this breakage with GCC ~ $ gcc --version gcc (Gentoo Hardened 4.8.3 p1.1, pie-0.5.9) 4.8.3 Created attachment 400116 [details]
gcc-4.8-hardened emerge --info
Created attachment 400118 [details]
gcc-4.8.3-hardened build.log
Btw, I just discussed with Hardened Team and they suggested to patch buildsystem to use paxmark.sh for paxmarking miniruby. (I guess, they mean paxmark.sh from elfix package). Although, nevermind the comment about paxmarking. It's not enough for fix :(. Anyway, I already reported bug upstream: https://bugs.ruby-lang.org/issues/11030 These changes(In reply to Vadim A. Misbakh-Soloviov (mva) from comment #22) > Although, nevermind the comment about paxmarking. It's not enough for fix > :(. Anyway, I already reported bug upstream: > https://bugs.ruby-lang.org/issues/11030 Even pEmrs marking is not enough. Moreover, there we go: dev-lang/ruby-2.1.6 and dev-lang/ruby-2.2.2 fails exactly the same way. So they probably propagated that commit to everywhere. Hurray! I just took a quick look at on how I may completely wipe ruby from my systems, but qt-webkit and texlive depends on it unconditionally. That makes me a sad panda... So I just hope for some larger user base will be affected, therefore the bug may eventually receive more attention. BR: Dw. zorry told me in IRC, that the issue is related to -fstack-check.
I was able to reproduce the error with CFLAGS="${CFLAGS} -fstack-check" on a non-hardened system.
CFLAGS="${CFLAGS} -fno-stack-check" makes it compile on a hardened system.
i was able to compile ruby on hardened system using following command as suggested by Manuel Rüger:
CFLAGS="${CFLAGS} -fno-stack-check" emerge -va1q =dev-lang/ruby-2.2.2 =dev-lang/ruby-2.1.6
without change in cflags, both packages failed.
Upstream has a patch for this now, but I got the impression on IRC that our hardened team was not convinced that that was the right was to fix things. Did anyone from the hardened team already get a chance to review this? (In reply to Hans de Graaff from comment #26) > Upstream has a patch for this now, but I got the impression on IRC that our > hardened team was not convinced that that was the right was to fix things. > Did anyone from the hardened team already get a chance to review this? For the record: here is the upstream commit https://github.com/ruby/ruby/commit/78c75612f07fdf4acfb148a3f0a4e129101eb124 (In reply to Hans de Graaff from comment #26) > Upstream has a patch for this now, but I got the impression on IRC that our > hardened team was not convinced that that was the right was to fix things. > Did anyone from the hardened team already get a chance to review this? Looks okay for me (In reply to Magnus Granberg from comment #28) > (In reply to Hans de Graaff from comment #26) > > Upstream has a patch for this now, but I got the impression on IRC that our > > hardened team was not convinced that that was the right was to fix things. > > Did anyone from the hardened team already get a chance to review this? > Looks okay for me The proposed fix seems to do the trick and solves the issue. I have backported the upstream patch to ruby-2.1.6-r1 and ruby-2.2.2-r1. |
dev-lang/ruby-2.2.1 fail with the following error: dtrace -G -C -I. -I.ext/include/x86_64-linux -I./include -I. -s ./probes.d -o probes.o x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -fno-strict-aliasing -fPIC -L. -Wl,-O1 -Wl,--as-needed -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,--no-undefined -fstack-protector -Wl,-O1 -Wl,--as-needed main.o dmydln.o miniinit.o miniprelude.o array.o bignum.o class.o compar.o complex.o dir.o dln_find.o encoding.o enum.o enumerator.o error.o eval.o load.o proc.o file.o gc.o hash.o inits.o io.o marshal.o math.o node.o numeric.o object.o pack.o parse.o process.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o regexec.o regparse.o regsyntax.o ruby.o safe.o signal.o sprintf.o st.o strftime.o string.o struct.o symbol.o time.o transcode.o util.o variable.o version.o compile.o debug.o iseq.o vm.o vm_dump.o vm_backtrace.o vm_trace.o thread.o cont.o probes.o ascii.o us_ascii.o unicode.o utf_8.o newline.o setproctitle.o strlcat.o strlcpy.o addr2line.o dmyext.o dmyenc.o -lpthread -lgmp -ldl -lcrypt -lm -o miniruby ./miniruby -I./lib -I. -I.ext/common ./tool/mkconfig.rb -timestamp=.rbconfig.time \ -install_name=ruby22 \ -so_name=ruby22 rbconfig.rb ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -c -o encdb.h ./template/encdb.h.tmpl ./enc enc uncommon.mk:581: recipe for target '.rbconfig.time' failed make: *** [.rbconfig.time] Segmentation fault make: *** Waiting for unfinished jobs.... uncommon.mk:763: recipe for target 'encdb.h' failed make: *** [encdb.h] Segmentation fault * ERROR: dev-lang/ruby-2.2.1::gentoo failed (compile phase): * emake failed full build.log and emerge --info attached Reproducible: Always