|
From: Matthias S. <zz...@ge...> - 2015-04-12 19:01:15
|
On 10.04.2015 20:56, Philippe Waroquiers wrote: > On Fri, 2015-04-10 at 06:47 +0200, Matthias Schwarzott wrote: > >> The check "if (fp_min + 256 >= fp_max)" in coregrind/m_stacktrace.c:501 >> is triggered here. >> >> By changing it to "if (fp_min + 128 >= fp_max)" it can be fixed. >> >> I think amd64 is having problems here because some functions do not need >> additional local variables but can use the redzone, so the stackframes >> are small. > Thanks for this analysis. > Some days ago, I looked at the history of this check. > I saw that the value was already decreased in the past for amd64. > This check is also disabled for Darwin. > > For x86/ppc32/ppc64/arm/arm64, the value is still 512. > > s390x/mips32/mips64/tilegx have no such condition. > > > It is not clear to me what is the purpose of this check. > I did not find an explanation in the svn history. > > I am wondering if that had not as objective to avoid SEGV for bogus > stack pointers. > There was some recent work done to avoid SEGV (e.g. by obtaining > better stack limits for unwinding). > > So, I am not sure that these checks are still useful. > Rather, they might only harm in case we have small but valid > stack frames. > Maybe the number should be dropped in total. Then only the check "fp_min >= fp_max" would remain. Even if I tried, I did not get the whole idea of how stack registering and (main) thread extension works. Regards Matthias |