Project

General

Profile

Actions

Bug #8483

closed

SEGV under high concurrency

Bug #8483: SEGV under high concurrency

Added by diego.plentz (Diego Plentz) over 12 years ago. Updated over 6 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 2.0.0p195 (2013-05-14 revision 40734) [x86_64-linux]
Backport:
[ruby-core:55282]

Description

Follow a few segfaults from /var/log/messages https://gist.github.com/plentz/5701752

I'm using sidekiq at my production servers and the ruby process dies with a segfault constantly(it's dying constantly since the last 2 weeks). I'm using concurrency of 50 with sidekiq, which causes a lot of threads to run.

I'm using ruby-2.0.0p195, but the problem happens with ruby-1.9.3-p392, ruby-1.9.3-p429 and ruby-2.0.0p0 as well. I already rollbacked all our gems, which probably means that the problem is really something with our ruby code causing the problem and not some gem that we use.

Here's what I managed to get using gdb

https://gist.github.com/plentz/5630854
https://gist.github.com/plentz/5632256

I can't find which line of the code is triggering the problem, since right after the segfault, I can't call (gdb) call rb_backtrace() to find the ruby stacktrace(or just don't know how).

If someone give me some directions, I can get more info, since the problem happens very often in our environment.

Updated by nagachika (Tomoyuki Chikanaga) over 12 years ago Actions #1 [ruby-core:55767]

Do you use any gem packages contains extension libraries?
Can you run a process in terminal and get backtrace etc..

Updated by naruse (Yui NARUSE) over 12 years ago Actions #2 [ruby-core:56429]

  • Status changed from Open to Feedback
  • Priority changed from 5 to Normal

Could you provide a reproducible code?

Updated by diego.plentz (Diego Plentz) over 12 years ago Actions #4 [ruby-core:56598]

We found the problem, was a recursive call that was generating the problem. I think it's really a bug that it segfaults in a recursive call when we had less memory, but I really can't reproduce the error in a more restrict test case, so I think we can close this. Thanks anyway

Updated by jeremyevans0 (Jeremy Evans) over 6 years ago Actions #5

  • Status changed from Feedback to Closed
  • Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN)
Actions

Also available in: PDF Atom