Bug #6292: Incorrect GC cleanup order with C extension classes

• Status: Rejected
• Assignee: -
• Target version: 1.9.3
• ruby -v: ruby 1.9.3p179 (2012-04-11 revision 35295) [x86_64-linux]

[owensmk (Mike Owens)]

I have two classes as C extensions. One (the child) holds a reference to the other (parent). The child references parent via rb_ivar_set(). Further, child also registers mark function to mark parent. Despite this, parent is still GC'd before child on process exit. Thus, when dhild's destructor is called (next), its parent ref points to invalid memory, causing potential segfault.

Working example code is here:

https://github.com/linterra/ruby-c-ext-gc

This also occurs if I set child to nil and then call GC.start().

Behavior is same on 1.9.1 through ruby_1_9_3@35295.

My understanding of proper behavior is that child's reference to parent (and/or it's mark function) should keep parent destructor from being called first. Neither of these seem to work.

[matz (Yukihiro Matsumoto)]

• Status changed from Open to Rejected

The GC sweeper does not keep the reference dependency. If it does, the GC will be far slower, or will consume too much memory.
I am sorry but I have to reject this bug report. It's spec.

Every deallocator should not reference other objects.

Matz.

[owensmk (Mike Owens)]

I understand the concern. At least I'm clear on the behavior.

matz (Yukihiro Matsumoto) wrote:

The GC sweeper does not keep the reference dependency. If it does, the GC will be far slower, or will consume too much memory.
I am sorry but I have to reject this bug report. It's spec.

Every deallocator should not reference other objects.

Matz.