|
From: Matthias S. <zz...@ge...> - 2015-04-10 04:47:59
Attachments:
0001-fix-short-callstack-on-amd64.patch
|
Hi! I analysed why the test memcheck/tests/threadname fails on amd64. See also https://bugs.kde.org/show_bug.cgi?id=345928 On amd64 it has this on stderr: ==32123== Thread 2: ==32123== Invalid write of size 1 ==32123== at 0x40083F: bad_things (threadname.c:16) ==32123== Address 0x53e71e2 is 0 bytes after a block of size 2 alloc'd ==32123== at 0x4C28BEF: malloc (vg_replace_malloc.c:299) ==32123== by 0x40082D: bad_things (threadname.c:15) ==32123== by 0x40094E: child_fn_0 (threadname.c:61) ==32123== by 0x4E3C203: start_thread (pthread_create.c:310) ==32123== I then enabled debug and added more printf-statements: 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. Regards Matthias |
|
From: Philippe W. <phi...@sk...> - 2015-04-10 18:55:52
|
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. Philippe |
|
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 |