Bug #6292

Incorrect GC cleanup order with C extension classes

Added by Mike Owens almost 3 years ago. Updated almost 3 years ago.

[ruby-core:44347]
Status:Rejected
Priority:Normal
Assignee:-
ruby -v:ruby 1.9.3p179 (2012-04-11 revision 35295) [x86_64-linux] Backport:

Description

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.

History

#1 Updated by Yukihiro Matsumoto almost 3 years ago

  • 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.

#2 Updated by Mike Owens almost 3 years ago

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.

Also available in: Atom PDF