Project

General

Profile

Bug #11662

Hash#delete causes segmentation fault at 0x00000000001ec8

Added by mstate (Mike State) almost 4 years ago. Updated 25 days ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.3.0dev (2015-11-02 trunk 52423) [x86_64-linux]
[ruby-core:71355]

Description

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)

Files

bug-11662.log (256 KB) bug-11662.log nobu (Nobuyoshi Nakada), 11/08/2015 07:24 AM

History

Updated by nobu (Nobuyoshi Nakada) almost 4 years ago

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

Updated by mstate (Mike State) almost 4 years ago

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.

#3

Updated by jeremyevans0 (Jeremy Evans) 25 days ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF