[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: smob mark functions in 2.0
From: |
Mark H Weaver |
Subject: |
Re: smob mark functions in 2.0 |
Date: |
Fri, 26 Sep 2014 00:50:58 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Hi Andy,
Reviving a 3-year-old thread...
Andy Wingo <address@hidden> wrote in November 2011:
> If you do implement a SMOB marking function, and you touch Scheme
> objects in that marking function, you need to be very careful.
>
> Specifically, there is a warning in gc/gc_mark.h:
>
> /* WARNING: Such a mark procedure may be invoked on an unused object */
> /* residing on a free list. Such objects are cleared, except for a */
> /* free list link field in the first word. Thus mark procedures may */
> /* not count on the presence of a type descriptor, and must handle this */
> /* case correctly somehow. */
>
> So, your mark function might see freed objects. This is terrible, but
> it is the way that it is. The key is that, if you touch a Scheme object
> in your mark function, to first do a check on that object, to see that
> it is valid. You can check the TC bits of the first word, or otherwise
> check that other words are non-NULL.
Andy Wingo <address@hidden> later replied to Ludovic:
> On Thu 24 Nov 2011 00:12, address@hidden (Ludovic Courtès) writes:
>
>>> So, your mark function might see freed objects. This is terrible, but
>>> it is the way that it is. The key is that, if you touch a Scheme object
>>> in your mark function, to first do a check on that object, to see that
>>> it is valid. You can check the TC bits of the first word, or otherwise
>>> check that other words are non-NULL.
>>
>> What about making that check in libguile before invoking the user’s mark
>> function?
>
> Yes, we do that. I think you wrote that code! The problem was in a
> mark function, accessing *other* Scheme objects.
Mark H Weaver <address@hidden> writes:
> Andy Wingo <address@hidden> writes:
>> Specifically, there is a warning in gc/gc_mark.h:
>>
>> /* WARNING: Such a mark procedure may be invoked on an unused object
>> */
>> /* residing on a free list. Such objects are cleared, except for a
>> */
>> /* free list link field in the first word. Thus mark procedures may
>> */
>> /* not count on the presence of a type descriptor, and must handle this
>> */
>> /* case correctly somehow.
>> */
>>
>> So, your mark function might see freed objects.
>
> How can this happen? If you are marking an object, then presumably it
> is still reachable, and therefore the objects it references are also
> still reachable. If any of those reachable objects has been freed,
> isn't that already a bug of a different kind? What am I missing?
I never received an answer to this question. At the time it was merely
a curiosity, but now I have a more pressing need to understand what's
going on here.
Regards,
Mark
- Re: smob mark functions in 2.0,
Mark H Weaver <=