Bug #15346
closedCore dump during GC if covering a special require
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
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!
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
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.