Bug #15346: Core dump during GC if covering a special require

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.6.0dev (2018-11-27 trunk 66002) [x86_64-linux]
• Backport: 2.4: DONTNEED, 2.5: DONTNEED

[MaxLap (Maxime Lapointe)]

On my environment, (ruby-head, updated today) the following script generates a core dump almost all the time. (I join a core dump to this report)

I am running on Ubuntu 16.04, I first saw the problem on Travis-CI and managed to make this much simpler reproduction code.

# Just setting up a file to require, this could be in a regular file and be required.
require 'tempfile'
f = Tempfile.new(['ruby', '.rb'])
f.write(<<-RUBY)
  a = 123
  begin
  ensure
    a
  end
RUBY
f.close

# Now the actual code to trigger the problem
require 'coverage'
Coverage.start
load f.path # require can do the same thing, but less frequently

# The problem is during GC, so we trigger it ourself
puts 'gc time!'
GC.start

# When it doesn't crash the first time, doing the load/require again seems to take care of it
puts '2nd gc'
load f.path
GC.start

puts 'gc done, try again!'

The problem seems related to the content of the ensure, if it's too simple, things break? It's weird.
If the content of the ensure is:
a
puts 'something'
#=> All good

puts 'something'
a
#=> Core dump

puts 'something'; a
#=> All good

a + 1
#=> All good

My personal guess is, if the last line of the ensure is useless, ruby optimizes it away, but that causes a problem with Coverage.

[mame (Yusuke Endoh)]

This report is awesome. Thank you very much!

The coverage counters are initialized with counter[lineno - 1] = 0. However, the lineno of ensure clause is 0 (for unknown reason). So it caused write access for index -1, which broke malloc header.

For now, I did a preventive commit to prevent this behavior (just ignore when lineno == 0). I'll continue to investigate the reason why the lineno is 0.

Again, I really appreciate you!

[mame (Yusuke Endoh)]

• Status changed from Open to Closed

[mame (Yusuke Endoh)]

The commit was r66025. (I have no idea why the commit is not automatically related to this ticket.)

I investigated the reason why lineno is 0. In Ruby bytecode, each instruction has lineno information. However, the ensure clause has no significant code (because the return value of ensure is just discarded), so the compiler does emit no instruction for the code. So, the lineno of the ensure clause cannot be identified, which led to lineno 0. This behavior looks benign, and coverage initialization can ignore them.

So, I'd like to make r66025 final for this issue. Let me know if you found any weird behavior. Thank you very much.

[MaxLap (Maxime Lapointe)]

Wow, very fast handling, thank you.

I confirm that this seems to have solved things on my end. Travis has not updated their ruby-head yet, but I assume it will be fine there too.

Thanks again

[nagachika (Tomoyuki Chikanaga)]

• Backport changed from 2.4: UNKNOWN, 2.5: UNKNOWN to 2.4: UNKNOWN, 2.5: REQUIRED

[nagachika (Tomoyuki Chikanaga)]

• Backport changed from 2.4: UNKNOWN, 2.5: REQUIRED to 2.4: DONTNEED, 2.5: DONTNEED

I misunderstood this could be reproducible in 2.5 but it isn't.