Project

General

Profile

Actions

Bug #6292

closed

Incorrect GC cleanup order with C extension classes

Added by owensmk (Mike Owens) over 12 years ago. Updated over 12 years ago.

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

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.

Updated by matz (Yukihiro Matsumoto) over 12 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.

Updated by owensmk (Mike Owens) over 12 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.

Actions

Also available in: Atom PDF

Like0
Like0Like0