Re: [PATCH][GOLD] Fix dangling pointer bug due to premature unlock.

[Doug Kwan (éæå) <dougkwan at google dot com>]

In the name of simplicity, I will change it to always lock then.

Thanks

-Doug

On Tue, Jan 25, 2011 at 7:26 AM, Ian Lance Taylor <iant@google.com> wrote:
> "Doug Kwan (éæå)" <dougkwan@google.com> writes:
>
>> Â ÂThis fixes a bug in which an object is released too early, causing
>> a pointer to point to unmapped memory. ÂMy fix is to move the locking
>> code to the caller of get_section_contents() and replace the original
>> locking code with a check. ÂThis has been tested on x86_64.
>>
>> -Doug
>>
>>
>> 2011-01-25 ÂDoug Kwan Â<dougkwan@google.com>
>>
>> Â Â Â Â * gold/icf.cc (get_section_contents): Instead of locking object in
>> Â Â Â Â two places, ask caller to lock it before calling. Add an assert
>> Â Â Â Â to check that object is locked in the first iteration.
>> Â Â Â Â (match_sections): Lock object before calling get_section_contents()
>> Â Â Â Â in the first iteration.
>
> This patch is fine. ÂHowever, it would be slightly simpler to just
> always lock the object in get_section_contents, regardless of whether
> first_iteration is true or not. ÂTask locks in gold are not mutexes or
> anything, they are basically free. ÂThere is no reason to be careful to
> only do the lock on the first iteration.
>
> The patch is OK either way.
>
> Thanks.
>
> Ian
>