Bug #11662: Hash#delete causes segmentation fault at 0x00000000001ec8

• Status: Closed
• Assignee: matz (Yukihiro Matsumoto)
• Target version: -
• ruby -v: ruby 2.3.0dev (2015-11-02 trunk 52423) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[mstate (Mike State)]

I have seen this bug happen several times, but only when the system is under heavy load. I have to apologize that don't have any means of easily reproducing it. I saw the same bug appear (segmentation fault at same line 296) on ruby 2.1.7p400 (2015-08-18 revision 51632) [x86_64-linux]. However on 2.1.7, the Segmentation fault was 0x00000000000000. I have the full core dump for 2.1.7 which I would be happy to provide if it's useful.

Line 296 of client.rb contains:

if handler = @tmp_handlers.delete(stanza.id)

/home/modus/apps/modus_surveyor/bundle/ruby/2.3.0/gems/blather-1.1.4/lib/blather/client/client.rb:296: [BUG] Segmentation fault at 0x00000000001ec8
ruby 2.3.0dev (2015-11-02 trunk 52423) [x86_64-linux]

(snip)

[nobu (Nobuyoshi Nakada)]

• File bug-11662.log bug-11662.log added
• Description updated (diff)
• Status changed from Open to Feedback

Could you inspect the broken object with gdb?
And you seem using threads, where is @tmp_handlers hash modified other than the crashed line?

[mstate (Mike State)]

Yes, we are using threads. @tmp_handlers is only called from one other location in line #129.

@tmp_handlers[id.to_s] = handler

Should it be safe to add a key to a hash while another thread is deleting a key from the same hash?

Unfortunately, I'm not sure if I can inspect with GDB. Let me know if it's required and I'll try and figure out how to do it.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Feedback to Closed