Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 542610 - dev-lang/ruby-2.2.1 - make: *** [.rbconfig.time] Segmentation fault
Summary: dev-lang/ruby-2.2.1 - make: *** [.rbconfig.time] Segmentation fault
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Ruby Team
URL: https://bugs.ruby-lang.org/issues/11030
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-09 00:18 UTC by Bertrand Jacquin
Modified: 2015-04-24 08:17 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,45.73 KB, text/x-log)
2015-03-09 00:19 UTC, Bertrand Jacquin
Details
emerge --info (info.log,17.56 KB, text/x-log)
2015-03-09 00:19 UTC, Bertrand Jacquin
Details
emerge --info (captaincrutches) (emerge-info,5.93 KB, text/plain)
2015-03-09 23:48 UTC, Captain Crutches
Details
build.log (captaincrutches) (build.log,72.83 KB, text/x-log)
2015-03-09 23:49 UTC, Captain Crutches
Details
An strace of the segmentation fault. (strace.log,6.50 KB, text/x-log)
2015-03-23 23:41 UTC, Eric Gisse
Details
gcc-4.8-hardened emerge --info (emergeinfo,6.10 KB, text/plain)
2015-03-30 05:52 UTC, Christopher Jones
Details
gcc-4.8.3-hardened build.log (build.log,44.90 KB, text/x-log)
2015-03-30 05:54 UTC, Christopher Jones
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Jacquin 2015-03-09 00:18:12 UTC
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
Comment 1 Bertrand Jacquin 2015-03-09 00:19:04 UTC
Created attachment 398438 [details]
build.log
Comment 2 Bertrand Jacquin 2015-03-09 00:19:17 UTC
Created attachment 398440 [details]
emerge --info
Comment 3 Hans de Graaff gentoo-dev 2015-03-09 06:40:51 UTC
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.
Comment 4 Bertrand Jacquin 2015-03-09 14:17:04 UTC
(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.
Comment 5 Hans de Graaff gentoo-dev 2015-03-09 18:25:22 UTC
(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?
Comment 6 Bertrand Jacquin 2015-03-09 18:28:09 UTC
(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
Comment 7 Captain Crutches 2015-03-09 23:47:43 UTC
I can confirm this same issue, will attach my own emerge --info and build.log
Comment 8 Captain Crutches 2015-03-09 23:48:20 UTC
Created attachment 398560 [details]
emerge --info (captaincrutches)
Comment 9 Captain Crutches 2015-03-09 23:49:53 UTC
Created attachment 398562 [details]
build.log (captaincrutches)
Comment 10 Hans de Graaff gentoo-dev 2015-03-10 19:02:18 UTC
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 ?
Comment 11 Captain Crutches 2015-03-10 21:49:55 UTC
ruby-2.2.0-r1 builds fine on the same setup.
Comment 12 Captain Crutches 2015-03-10 22:07:07 UTC
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.
Comment 13 Bertrand Jacquin 2015-03-11 14:04:49 UTC
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
Comment 14 Vadim A. Misbakh-Soloviov (mva) gentoo-dev 2015-03-19 04:36:34 UTC
I can confirm that too, although, I'm using Hardened GCC and UTF-8 too.
Is it any useful, that I can provide?
Comment 15 Eric Gisse 2015-03-23 23:40:24 UTC
(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.
Comment 16 Eric Gisse 2015-03-23 23:41:04 UTC
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.
Comment 17 Nicolas Peyron 2015-03-24 14:32:13 UTC
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.
Comment 18 Christopher Jones 2015-03-30 05:49:51 UTC
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
Comment 19 Christopher Jones 2015-03-30 05:52:58 UTC
Created attachment 400116 [details]
gcc-4.8-hardened emerge --info
Comment 20 Christopher Jones 2015-03-30 05:54:36 UTC
Created attachment 400118 [details]
gcc-4.8.3-hardened build.log
Comment 21 Vadim A. Misbakh-Soloviov (mva) gentoo-dev 2015-04-10 16:21:44 UTC
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).
Comment 22 Vadim A. Misbakh-Soloviov (mva) gentoo-dev 2015-04-10 16:50:01 UTC
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
Comment 23 Attila Tóth 2015-04-14 10:30:49 UTC
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.
Comment 24 Manuel Rüger (RETIRED) gentoo-dev 2015-04-14 16:20:51 UTC
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.
Comment 25 Miroslav Šulc gentoo-dev 2015-04-14 20:29:06 UTC
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.
Comment 26 Hans de Graaff gentoo-dev 2015-04-19 17:27:07 UTC
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?
Comment 27 Attila Tóth 2015-04-19 18:32:03 UTC
(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
Comment 28 Magnus Granberg gentoo-dev 2015-04-19 21:59:15 UTC
(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
Comment 29 Attila Tóth 2015-04-21 19:16:26 UTC
(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.
Comment 30 Hans de Graaff gentoo-dev 2015-04-24 08:17:09 UTC
I have backported the upstream patch to ruby-2.1.6-r1 and ruby-2.2.2-r1.