1.8.7 segfault

Discussion in 'Ruby' started by Izit Izit, Dec 3, 2008.

  1. Izit Izit

    Izit Izit Guest

    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
    --
    Posted via http://www.ruby-forum.com/.
     
    Izit Izit, Dec 3, 2008
    #1
    1. Advertising

  2. Izit Izit

    Jim Morris Guest

    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.

    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;
    > (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



    --
    Jim Morris, http://blog.wolfman.com
     
    Jim Morris, Dec 3, 2008
    #2
    1. Advertising

  3. Izit Izit

    Izit Izit Guest

    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.


    --
    Posted via http://www.ruby-forum.com/.
     
    Izit Izit, Dec 3, 2008
    #3
  4. Izit Izit

    Tim Hunter Guest

    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?
    --
    Posted via http://www.ruby-forum.com/.
     
    Tim Hunter, Dec 3, 2008
    #4
  5. Izit Izit

    Izit Izit Guest

    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.
    --
    Posted via http://www.ruby-forum.com/.
     
    Izit Izit, Dec 3, 2008
    #5
  6. Izit Izit

    Izit Izit Guest

    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.
    --
    Posted via http://www.ruby-forum.com/.
     
    Izit Izit, Dec 5, 2008
    #6
  7. Izit Izit

    Bouquet Guest

    Izit Izit wrote:

    > 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;


    I just got the same crash in a very simple 1.8.7 program that
    limits its memory using Process.setrlimit(Process::RLIMIT_AS, 10**6).

    It looks the crash is due to a failure to check the success of
    the the must_skip buffer allocation on line 2471 of regex.c
     
    Bouquet, Jan 29, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vedran Vyroubal

    STL string segfault

    Vedran Vyroubal, Mar 3, 2004, in forum: C++
    Replies:
    5
    Views:
    1,369
    Vedran Vyroubal
    Mar 4, 2004
  2. Arthur J. O'Dwyer

    multiset segfault

    Arthur J. O'Dwyer, Jun 17, 2004, in forum: C++
    Replies:
    10
    Views:
    745
    Dave Townsend
    Jun 18, 2004
  3. Jim Strathmeyer

    istream segfault

    Jim Strathmeyer, Jul 22, 2004, in forum: C++
    Replies:
    4
    Views:
    448
    Mike Wahler
    Jul 23, 2004
  4. William Payne
    Replies:
    4
    Views:
    511
    Karthiik Kumar
    Aug 28, 2004
  5. Andrey Vul
    Replies:
    8
    Views:
    698
    Richard Bos
    Jul 30, 2010
Loading...

Share This Page