Bug in reference counting or garbage collection

[prpr19xx]

Bug in reference counting or garbage collection

[prpr19xx]

This is even simpler:

package require oo

class t { val 0 }
t method setval {v} { set val $v }

proc final {ref value} { puts "Destroy $ref" }

set l1 [list 99 96 98]
set entries [lmap i $l1 {
        set tt [t new]
        finalize $tt final
        puts "Create $tt"
        $tt setval $i
        list $tt
    }]
puts "Collect A"
collect
puts "Display"
set e [lindex $entries 1]
puts $e
puts [$e classname]
puts "Collect B"
collect

and generates this (with a slight mod. to the GC debugging to show refCount):

Create ::<reference.<t______>.00000000000000000000>
Create ::<reference.<t______>.00000000000000000002>
Create ::<reference.<t______>.00000000000000000004>
Collect A
MARK: 4 (type=command) refCount=3
MARK: 2 (type=command) refCount=2
MARK: 0 (type=command) refCount=2
Display
::<reference.<t______>.00000000000000000002>
t
Collect B
MARK: 4 (type=command) refCount=3
No MARK: 2 objPtr->refCount=2 - command with refcount=1
No MARK: 2 objPtr->refCount=1 - command with refcount=1
MARK: 0 (type=command) refCount=2
COLLECTING 2
Destroy <reference.<t______>.00000000000000000002>

It seems that reading any property of $e causes the problem, as it goes away if commented out.
Changing the value of the lindex index to 2 doesn't break it, but 0 and 1 do.
Not sure why object "4" has different refCount to the other two either, but probably explains the preceding sentence.

All this seems to have started on 5 Jun 2020 with 5d44077.

[msteveb]

It does look like there is something not quite right there. I pushed a tentative fix to the branch garbage-collection-fix. Would you mind trying it out and let me know what you think?

[prpr19xx]

The output is now not showing any destruction, which is good:

Create ::<reference.<t______>.00000000000000000000>
Create ::<reference.<t______>.00000000000000000002>
Create ::<reference.<t______>.00000000000000000004>
Collect A
MARK: 4 (type=command) refCount=3
MARK: 2 (type=command) refCount=2
MARK: 0 (type=command) refCount=2
Display
::<reference.<t______>.00000000000000000002>
t
Collect B
MARK: 4 (type=command) refCount=3
MARK: 2 (type=command) refCount=2
No MARK: 2 - command with refcount=1
MARK: 0 (type=command) refCount=2

Still not sure if the refCount stuff is correct as I don't understand it (I tried selected old versions, back to about 2011 until they wouldn't compile, and it's always done that), but certainly the big problem is apparently fixed.

[msteveb]

Thanks. I'll try to come up with some unit tests that show both original problems before I merge it

[prpr19xx]

Not sure why me merging this fix into my personal fork should have closed the issue in the upstream repository when it hasn't been committed to upstream master.

[msteveb]

Sure. I don't know why either. I still want to create some unit tests to confirm that the fix is correct before I merge.

[Mar181-arc]

[msteveb]

I believe I now have a better fix for this problem (garbage-collection-fix-take2) taking into account that there can be multiple objects that refer to the same reference. I think it will end up the same, but this approach makes more sense to me.