On Wed, 7 Jul 2004 17:32:30 +0200 Tilman Sauerbeck <[EMAIL PROTECTED]>
babbled:
> Carsten Haitzler <[EMAIL PROTECTED]> [2004-07-07 07:14]:
> > > 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[snip]
>
> Yeah, I'm aware of that. I'd only want to suppress the "handle already
> freed" messages, since they can only occur on ONE occasion with the Ruby
> bindings and I know it's safe to ignore these. I think :))
not really - it knows its already freed because the first 4 bytes (int) contain
a magic sequence. it's highly unlikely to find this sequence (it's not a common
number) and so your chances of a mis-detection are like 1 in 4 billion.
the PROBLEM is that it needs to read these 4 bytes - what if the object is freed
and libc has sbrk()'d the process size back down (not common - but possible and
it does happen when enough of the heap frees up at the top). now those 4 bytes
of magic check are not even within your processes memory space - so the CHECK
will cause a segv (as would any other attempt to access the object). so in this
case the app has not been saved. as i said - i didnt check pointer values to see
if they are within memory space of the process. i actually dont know of a
portable way of finding out what the memory space is (easily) and tracking it
(easily). so in this case you'd segv, and the warnings are a sign that there is
a possible segv there... :)
> > > 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) :)
>
> Yeah, I know it's somewhat evil to suppress ecore's warnings, but
> calling $lib_init and $lib_shutdown in every (de)constructor doesn't
> sound appealing either. I'll think about it again, though ;)
>
> --
> Regards,
> Tilman
>
>
> -------------------------------------------------------
> 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
>
--
------------- 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
