Project

General

Profile

Actions

Bug #15346

closed

Core dump during GC if covering a special require

Added by MaxLap (Maxime Lapointe) over 5 years ago. Updated about 5 years ago.

Status:
Closed
Assignee:
-
Target version:
-
ruby -v:
ruby 2.6.0dev (2018-11-27 trunk 66002) [x86_64-linux]
[ruby-core:90085]

Description

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.


Files

cov-require_core_dump.txt (10.4 KB) cov-require_core_dump.txt MaxLap (Maxime Lapointe), 11/27/2018 05:42 AM

Updated by mame (Yusuke Endoh) over 5 years ago

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!

Actions #2

Updated by mame (Yusuke Endoh) over 5 years ago

  • Status changed from Open to Closed

Updated by mame (Yusuke Endoh) over 5 years ago

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.

Updated by MaxLap (Maxime Lapointe) over 5 years ago

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

Actions #5

Updated by nagachika (Tomoyuki Chikanaga) over 5 years ago

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

Updated by nagachika (Tomoyuki Chikanaga) about 5 years ago

  • 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0