On Tue, 6 Jul 2004 22:20:51 +0200 Tilman Sauerbeck <[EMAIL PROTECTED]>
babbled:
> Hi,
> as some of you might know, I'm currently working on Ruby bindings for
> EFL (ecore, evas, edje atm).
>
> One problem I found is that Ruby's garbage collector doesn't work too
> well with our $lib_shutdown() functions, which makes ecore/evas spank me
> badly :)
aah - you will HAVE to solve this. those messages are ecore/evas/etc. AVOIDING
what would normally be a segv. you have a pointer STILL to memory - it may be
NULL which makes it easy to detect and avoid - it will always be safe, but often
its NOT NULL. it is a valid pointer - it may still point WITHIN your memory
space (so the memory it points to is readable) BUt the object it points to was
deleted. ecore/evas MARK deleted objects with magic values and it knows it was
deleted if it finds this magic value there - BUT the object COULd have been
overwritten with new data in memory so this magic value sint there - but the
"i'm alive and well" value most likely wont be (though it IS possible that
co-incidence might make a magic number be put there and then it gets through the
checks even though its all freed). there is ALSO the case where the pointer
points into memory that is no longer accessible (pages outside your memory
range). currently there are no tests for this - the magic checks would SEGV then
(as would any code afterwards too).
so when you get these outputs, it is the sign of a BUG - a REAL and EXISTING
BUG. you NEED to fix it - you are just lucky it hasn't segv'd for NOW. the EFL
code has saved you from a segv as best it can - but thats not guaranteed - its a
sign for developers to FIX their bugs - not "safely ignore them". it's NOT safe.
it's playing with fire and sooner or later you will get burnt. EFL just adds
some fire-retardent gloves on your hands :)
> In my case, these warning messages can be safely ignored, Ruby users
> shouldn't see them.
>
> I guess the most simple way to do this is with the attached patch.
>
> Comments? If nobody objects, I'll put this in CVS in a few days (and
> I'll do the same to evas, too).
noooo - fix the bugs - the problem is how to interact with ruby's GC safely - ie
defer a shutdown until the GC has finished up. maybe you should add a resource
counter per system and whenever ruby's gc frees something decrement and only
shutdown THEN (also respecting init order - you should shut down in the revers
order you initted) :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 (数田) [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
