From: mame@ruby-lang.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:90086] [Ruby trunk Bug#15346] Core dump during GC if covering a special require
Date: Tue, 27 Nov 2018 07:40:48 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-75211.20181127074046.85b5a5cc21bf6bc2@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15346.20181127054646@ruby-lang.org
Issue #15346 has been updated by 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!
----------------------------------------
Bug #15346: Core dump during GC if covering a special require
https://bugs.ruby-lang.org/issues/15346#change-75211
* Author: MaxLap (Maxime Lapointe)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.6.0dev (2018-11-27 trunk 66002) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
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.
~~~ ruby
# 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)
--
https://bugs.ruby-lang.org/
next prev parent reply other threads:[~2018-11-27 7:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-15346.20181127054646@ruby-lang.org>
2018-11-27 5:46 ` [ruby-core:90085] [Ruby trunk Bug#15346] Core dump during GC if covering a special require hunter_spawn
2018-11-27 7:40 ` mame [this message]
2018-11-27 8:00 ` [ruby-core:90087] " mame
2018-11-27 22:14 ` [ruby-core:90098] " hunter_spawn
2019-01-20 4:34 ` [ruby-core:91185] " nagachika00
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-75211.20181127074046.85b5a5cc21bf6bc2@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).