Bug #6292

Incorrect GC cleanup order with C extension classes

Added by Mike Owens about 2 years ago. Updated about 2 years ago.

[ruby-core:44347]
Status:Rejected
Priority:Normal
Assignee:-
Category:core
Target version:1.9.3
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 rbivarset(). 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 ruby19_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 about 2 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 about 2 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