From: Julian Seward Date: Tue, 2 Aug 2005 13:35:21 +0000 (+0000) Subject: "Fix" (kludge) highly obscure bug in flag settings for growdown stacks X-Git-Tag: svn/VALGRIND_3_0_0~13 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d71b68c6a35b3eb435ecd19d2f0c5a0c0925d138;p=thirdparty%2Fvalgrind.git "Fix" (kludge) highly obscure bug in flag settings for growdown stacks which manifested itself as unreliable behaviour with --smc-check=stack. The accompanying comment explains. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4305 --- diff --git a/coregrind/m_signals.c b/coregrind/m_signals.c index 51b191574b..cc43ff28b3 100644 --- a/coregrind/m_signals.c +++ b/coregrind/m_signals.c @@ -1728,6 +1728,24 @@ Bool VG_(extend_stack)(Addr addr, UInt maxsize) if (seg->len + newsize >= maxsize) return False; + /* Nasty Hack. The new segment will have SF_MMAP set because + that's what VG_(mmap) does. But the existing stack segment + won't necessarily have it set, because the initial segment list + entry for the main thread's stack doesn't have it set. That + means that the segment list preener won't merge the segments + together (because they have different flags). That means the + segment list will in fact list two adjacent segments for the + main stack, which is wrong. This means that the tests which + check if a translation is from a stack-like area and therefore + in need of a self-check will not work right. Sigh. + + So .. in lieu of fixing this properly (viz, rationalising all + the SF_ flags), just mark the original stack segment as having + SF_MMAP. Then the preener will merge it into the new area. + This is a hack. */ + seg->flags |= SF_MMAP; + /* end of Nasty Hack */ + if (VG_(mmap)((Char *)base, newsize, seg->prot, VKI_MAP_PRIVATE | VKI_MAP_FIXED | VKI_MAP_ANONYMOUS | VKI_MAP_CLIENT,