This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH][GOLD] Fix dangling pointer bug due to premature unlock.
- From: Ian Lance Taylor <iant at google dot com>
- To: Doug Kwan (éæå) <dougkwan at google dot com>
- Cc: binutils <binutils at sourceware dot org>, Cary Coutant <ccoutant at google dot com>, Sriraman Tallam <tmsriram at google dot com>
- Date: Tue, 25 Jan 2011 07:26:16 -0800
- Subject: Re: [PATCH][GOLD] Fix dangling pointer bug due to premature unlock.
- References: <AANLkTinD+w8rchkJWm+68X7yehCCgpE81wn2rXYfpQgH@mail.gmail.com>
"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