Project

General

Profile

Actions

Bug #12237

closed

Coverage keeps tracking counts even after Coverage.result

Added by Eregon (Benoit Daloze) about 8 years ago. Updated about 8 years ago.

Status:
Closed
Target version:
-
ruby -v:
ruby 2.4.0dev (2016-03-31 trunk 54454) [x86_64-linux]
[ruby-core:74741]

Description

While looking at #12220, I found a bug.
Attached is a patch that reveals it.

Running
$ make test-all TESTS="test/coverage -n /test_restarting_coverage/"
gives
[1/1] TestCoverage#test_restarting_coverage
Updating cov for /tmp/d20160331-27149-q8o6co/test.rb:1 : 1 size=3 # OK
Updating cov for /tmp/d20160331-27149-q8o6co/test.rb:2 : 1 size=0 # This did RARAAY_AREF(,2) on an array of size 0!
{"/tmp/d20160331-27149-q8o6co/test.rb"=>[]}
Updating cov for /tmp/d20160331-27149-q8o6co/test.rb:2 : 2 size=0 # This did RARAAY_AREF(,4) on an array of size 0!
Updating cov for /tmp/d20160331-27149-q8o6co/test2.rb:1 : 1 size=4 # OK
{"/tmp/d20160331-27149-q8o6co/test.rb"=>[], "/tmp/d20160331-27149-q8o6co/test2.rb"=>[1, nil, 0, nil]}

Coverage tracking of files after Coverage.result (= reset) should just disable itself.
Since the current strategy is to rb_ary_clear() these arrays referenced by the iseq, one should check for bounds instead, as in the commented code.

Ideally, it could even rewrite the trace coverage instruction to a no-op, but that's more involved and might have few real use-cases.
Note that these arrays also forever leak and it would seem rb_ary_clear() does not always free the storage but just set the size to 0.

Can I commit the fix in thread.c?
I think it should be back-ported as well as it could be accessing arrays out-of-bounds.


Files

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0