Forum: Ruby 1.8.7 segfault

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
86a01abd9d77ebfc577b2890623c6170?d=identicon&s=25 Izit Izit (izit)
on 2008-12-03 21:10
Hi,

I have a Rails app that keeps on segfaulting if I request a very
intensive task. The task involves reading a lot of DB records and
parsing each record in hashes and arrays.

If I limit the DB record scope the segfault does not happen but with a
larger set it happens every time. Strange thing is it only happens on my
linux system not on my OS X dev system. Both run ruby 1.8.7 latest
version compiled from source. The process eats a lot of memory, keeps
growing and then the fault occurs.

I ran gdb on the faulty process, here is some output:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 48005413886848 (LWP 29060)]
ruby_re_compile_pattern (pattern=0x10f3070 ":", size=<value optimized
out>,
    bufp=0x96f51f0) at regex.c:2730
2730      skip[c] = m;
(gdb) whe
#0  ruby_re_compile_pattern (pattern=0x10f3070 ":",
    size=<value optimized out>, bufp=0x96f51f0) at regex.c:2730
#1  0x0000000000461cae in rb_reg_initialize (obj=48005969553640,
    s=0x10f3070 ":", len=1, options=<value optimized out>) at re.c:643
#2  0x0000000000461f51 in rb_reg_new (s=0x10f3070 ":", len=1, options=0)
    at re.c:1459
#3  0x0000000000461fba in rb_reg_regcomp (str=0) at re.c:1480
#4  0x0000000000476abd in rb_str_split_m (argc=<value optimized out>,
    argv=<value optimized out>, str=48005969558200) at string.c:3560
#5  0x000000000041b84a in rb_call0 (klass=48005399435280,
recv=48005969558200,
    id=4665, oid=4665, argc=1, argv=0x7fffff953900, body=0x2ba920c7c9b0,
    flags=<value optimized out>) at eval.c:5904
#6  0x000000000041c598 in rb_call (klass=48005399435280,
recv=48005969558200,
    mid=4665, argc=1, argv=0x7fffff953900, scope=0, self=48005506071920)
    at eval.c:6151
#7  0x000000000041713b in rb_eval (self=48005506071920,
    n=<value optimized out>) at eval.c:3492
#8  0x0000000000417047 in rb_eval (self=48005506071920,
    n=<value optimized out>) at eval.c:3486
#9  0x0000000000416701 in rb_eval (self=48005506071920,
    n=<value optimized out>) at eval.c:2997
#10 0x0000000000417641 in rb_eval (self=48005506071920,
    n=<value optimized out>) at eval.c:3047
#11 0x0000000000418b1e in rb_eval (self=48005506071920,
    n=<value optimized out>) at eval.c:3332

#12 0x000000000041c0b3 in rb_call0 (klass=48005434552560,
recv=48005506071920,
    id=51241, oid=<value optimized out>, argc=32767,
argv=0x7fffff955df0,
    body=0x2ba922eb97a8, flags=<value optimized out>) at eval.c:6055
#13 0x000000000041c598 in rb_call (klass=48005434552560,
recv=48005506071920,
    mid=51241, argc=2, argv=0x7fffff955de0, scope=1,
self=48005506071920)
    at eval.c:6151
#14 0x0000000000417273 in rb_eval (self=<value optimized out>,
    n=<value optimized out>) at eval.c:3507
#15 0x00000000004164ec in rb_eval (self=48005506071920,
    n=<value optimized out>) at eval.c:3677
#16 0x000000000041c0b3 in rb_call0 (klass=48005434552560,
recv=48005506071920,
    id=3769, oid=<value optimized out>, argc=32767, argv=0x7fffff957070,
    body=0x2ba922e69050, flags=<value optimized out>) at eval.c:6055
#17 0x000000000041c598 in rb_call (klass=48005434552560,
recv=48005506071920,
    mid=3769, argc=2, argv=0x7fffff957060, scope=1, self=48005506071920)
    at eval.c:6151
#18 0x0000000000417273 in rb_eval (self=<value optimized out>,
    n=<value optimized out>) at eval.c:3507
#19 0x000000000041c0b3 in rb_call0 (klass=48005457401280,
recv=48005506071920,
    id=54129, oid=<value optimized out>, argc=11177,
argv=0x7fffff957c90,
    body=0x2ba924411fb0, flags=<value optimized out>) at eval.c:6055


Does anyone have an idea ?

thanks

Jeroen
Aa8a811205e47df967a2f27ad98fd6a8?d=identicon&s=25 Jim Morris (Guest)
on 2008-12-03 22:24
(Received via mailing list)
Quite often I find this is caused by a bad memory SIMM, try running
memtst86 or equivalent to
eliminate a H/W problem, then you can focus on potential S/W problems.
86a01abd9d77ebfc577b2890623c6170?d=identicon&s=25 Izit Izit (izit)
on 2008-12-03 22:31
I am running on a VPS, so cannot check H/W. I am quite sure this is ok.

Jim Morris wrote:
> Quite often I find this is caused by a bad memory SIMM, try running
> memtst86 or equivalent to
> eliminate a H/W problem, then you can focus on potential S/W problems.
B33ea5c12d767bfd1253940a960274f5?d=identicon&s=25 Tim Hunter (timhunter)
on 2008-12-03 22:35
Izit Izit wrote:
> Hi,
>
> I have a Rails app that keeps on segfaulting if I request a very
> intensive task. The task involves reading a lot of DB records and
> parsing each record in hashes and arrays.
>
> If I limit the DB record scope the segfault does not happen but with a
> larger set it happens every time. Strange thing is it only happens on my
> linux system not on my OS X dev system. Both run ruby 1.8.7 latest
> version compiled from source. The process eats a lot of memory, keeps
> growing and then the fault occurs.
>
> I ran gdb on the faulty process, here is some output:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 48005413886848 (LWP 29060)]
> ruby_re_compile_pattern (pattern=0x10f3070 ":", size=<value optimized
> out>,
>     bufp=0x96f51f0) at regex.c:2730
> 2730      skip[c] = m;


Have you tried recompiling with less optimization?
86a01abd9d77ebfc577b2890623c6170?d=identicon&s=25 Izit Izit (izit)
on 2008-12-03 23:02
Tim Hunter wrote:
> Izit Izit wrote:
>> Hi,
>>

>> I ran gdb on the faulty process, here is some output:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 48005413886848 (LWP 29060)]
>> ruby_re_compile_pattern (pattern=0x10f3070 ":", size=<value optimized
>> out>,
>>     bufp=0x96f51f0) at regex.c:2730
>> 2730      skip[c] = m;
>
>
> Have you tried recompiling with less optimization?

I have compiled with only --enable-pthreads, the rest was all default.
86a01abd9d77ebfc577b2890623c6170?d=identicon&s=25 Izit Izit (izit)
on 2008-12-05 16:20
Izit Izit wrote:
> Tim Hunter wrote:
>> Izit Izit wrote:
>>> Hi,
>>>
>
>>> I ran gdb on the faulty process, here is some output:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 48005413886848 (LWP 29060)]
>>> ruby_re_compile_pattern (pattern=0x10f3070 ":", size=<value optimized
>>> out>,
>>>     bufp=0x96f51f0) at regex.c:2730
>>> 2730      skip[c] = m;
>>
>>
>> Have you tried recompiling with less optimization?
>
> I have compiled with only --enable-pthreads, the rest was all default.

I have moved to ruby enterprise edition (latest version) and the problem
is gone.
0ec4920185b657a03edf01fff96b4e9b?d=identicon&s=25 Yukihiro Matsumoto (Guest)
on 2008-12-05 18:12
(Received via mailing list)
Hi,

In message "Re: 1.8.7 segfault"
    on Sat, 6 Dec 2008 00:14:46 +0900, Izit Izit <portie@bitterbal.org>
writes:

|I have moved to ruby enterprise edition (latest version) and the problem
|is gone.

What?!  I didn't know REE is a panacea.  Hmmm.

              matz.
This topic is locked and can not be replied to.