Please check again my explanation: rclosure_unref is not called in
step #1 or #2.Both #1 and #2 calls rclosure_invalidate() but don’t call
rclosure_unref(). Is it OK?
That’s right.
when the first rclosure_invalidate() call?
Yes. Remember that in #1, this is the Ruby’s GC who’s firing, hence it
calls your callback gr_closure_holder_free which sets the holder to
Qnil before invoking rclosure_invalidate.
I explained it in the last paragraph of my previous message, but I can
show it as code if you prefer:Thanks. I’m good in programming language rather than
English. X<
That’s maybe the best common language we have, that’s right 
}rcosure isn’t freed but rclosure->rb_holder is freed. Is it
OK? If it’s true, does the following patch solve your
That’s correct.
GRClosureHolder *holder; Data_Get_Struct(rclosure->rb_holder, GRClosureHolder, holder); holder->closure = NULL;
rclosure->rb_holder = Qnil;
No. Remember, rclosure_unref is unfortunately never called in the
described scenario.
Btw, the point of my suggested patch is exactly to be able to call
rclosure_unref (with a count of 1) in case rclosure_invalidate is
triggered. Remember, when GTK calls rclosure_invalidate, it means the
memory for the closure will be freed right after that, so in my
opinion the flaw is in your rclosure_invalidate, which should always
take necessary actions so that no code would lookup again data in the
closure after that, so calling the series of weak_unref is crucial.
That’s the spirit of my patch.
–
Guillaume C. - Guillaume Cottenceau
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net’s Techsay panel and you’ll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV