|
From: Christian B. <bor...@de...> - 2017-05-04 21:24:10
|
On 05/04/2017 10:40 PM, Ivo Raisr wrote: > 2017-05-04 22:14 GMT+02:00 Christian Borntraeger <bor...@de...>: >> On 05/04/2017 04:26 PM, Ivo Raisr wrote: >>> https://bugs.kde.org/show_bug.cgi?id=379504 says it all. >>> For more details, go for http://valgrind.10908.n7.nabble.com/tilegx-td57235.html >>> >>> I'd be grateful if you can peek at the patches attached to the bug, >>> try them with your platform, or both. >> >> >> I wanted to apply them for s390 testing but I get errors: >> >> $ patch -p0 < ~/code//tilegx-valgrind.patch >> patching file Makefile.all.am >> patching file Makefile.tool.am >> patching file Makefile.vex.am >> patching file NEWS >> patching file cachegrind/cg_arch.c >> patching file cachegrind/cg_branchpred.c >> patching file configure.ac >> patching file coregrind/Makefile.am >> patching file coregrind/launcher-linux.c >> patching file coregrind/m_aspacemgr/aspacemgr-common.c >> patching file coregrind/m_cache.c >> patching file coregrind/m_coredump/coredump-elf.c >> patching file coregrind/m_debuginfo/d3basics.c >> patching file coregrind/m_debuginfo/debuginfo.c >> patching file coregrind/m_debuginfo/priv_storage.h >> patching file coregrind/m_debuginfo/readdwarf.c >> patching file coregrind/m_debuginfo/readelf.c >> patching file coregrind/m_debuginfo/storage.c >> patching file coregrind/m_debuglog.c >> patching file coregrind/m_dispatch/dispatch-tilegx-linux.S >> Reversed (or previously applied) patch detected! Assume -R? > > That's because this file was updated in the meantime with a copyright change. > I've rebased the patches attached to the bug - please try the new version (II.). > Thank you for testing this! regression run on s390 is mostly fine, but one testcase regresses due to changed line numbers (this should regress on all platforms) --- leak-segv-jmp.stderr.exp 2017-05-04 22:45:11.591453179 +0200 +++ leak-segv-jmp.stderr.out 2017-05-04 23:18:25.511493110 +0200 @@ -14,8 +14,8 @@ expecting a leak 1,000 bytes in 1 blocks are definitely lost in loss record ... of ... at 0x........: malloc (vg_replace_malloc.c:...) - by 0x........: f (leak-segv-jmp.c:295) - by 0x........: main (leak-segv-jmp.c:370) + by 0x........: f (leak-segv-jmp.c:271) + by 0x........: main (leak-segv-jmp.c:346) LEAK SUMMARY: definitely lost: 1,000 bytes in 1 blocks @@ -30,8 +30,8 @@ expecting a leak again 1,000 bytes in 1 blocks are definitely lost in loss record ... of ... at 0x........: malloc (vg_replace_malloc.c:...) - by 0x........: f (leak-segv-jmp.c:295) - by 0x........: main (leak-segv-jmp.c:370) + by 0x........: f (leak-segv-jmp.c:271) + by 0x........: main (leak-segv-jmp.c:346) LEAK SUMMARY: definitely lost: 1,000 bytes in 1 blocks @@ -46,8 +46,8 @@ expecting a leak again after full mprotect 1,000 bytes in 1 blocks are definitely lost in loss record ... of ... at 0x........: malloc (vg_replace_malloc.c:...) - by 0x........: f (leak-segv-jmp.c:295) - by 0x........: main (leak-segv-jmp.c:370) + by 0x........: f (leak-segv-jmp.c:271) + by 0x........: main (leak-segv-jmp.c:346) LEAK SUMMARY: definitely lost: 1,000 bytes in 1 blocks @@ -62,13 +62,13 @@ expecting heuristic not to crash after full mprotect 1,000 bytes in 1 blocks are definitely lost in loss record ... of ... at 0x........: malloc (vg_replace_malloc.c:...) - by 0x........: f (leak-segv-jmp.c:295) - by 0x........: main (leak-segv-jmp.c:370) + by 0x........: f (leak-segv-jmp.c:271) + by 0x........: main (leak-segv-jmp.c:346) 200,000 bytes in 1 blocks are possibly lost in loss record ... of ... at 0x........: calloc (vg_replace_malloc.c:...) - by 0x........: f (leak-segv-jmp.c:342) - by 0x........: main (leak-segv-jmp.c:370) + by 0x........: f (leak-segv-jmp.c:318) + by 0x........: main (leak-segv-jmp.c:346) LEAK SUMMARY: definitely lost: 1,000 bytes in 1 blocks |