|
From: <js...@ac...> - 2007-11-04 01:19:00
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-11-04 02:00:01 CET Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 255 tests, 11 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/deep-C (stderr) massif/tests/peak2 (stderr) massif/tests/realloc (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Nicholas N. <nj...@cs...> - 2007-11-04 05:23:18
|
On Sun, 4 Nov 2007 js...@ac... wrote: > Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-11-04 02:00:01 CET > Results unchanged from 24 hours ago > > Checking out valgrind source tree ... done > Configuring valgrind ... done > Building valgrind ... done > Running regression tests ... failed > > Regression test results follow > > == 255 tests, 11 stderr failures, 2 stdout failures, 0 post failures == > memcheck/tests/deep_templates (stdout) > memcheck/tests/leak-cycle (stderr) > memcheck/tests/leak-tree (stderr) > memcheck/tests/pointer-trace (stderr) > massif/tests/culling1 (stderr) > massif/tests/culling2 (stderr) > massif/tests/deep-C (stderr) > massif/tests/peak2 (stderr) > massif/tests/realloc (stderr) > none/tests/faultstatus (stderr) > none/tests/fdleak_cmsg (stderr) > none/tests/mremap (stderr) > none/tests/mremap2 (stdout) Julian, can you send me diffs for one or all of the Massif ones? Nick |
|
From: Nicholas N. <nj...@cs...> - 2007-11-04 21:42:33
|
On Sun, 4 Nov 2007, Julian Seward wrote: >>> massif/tests/culling1 (stderr) >>> massif/tests/culling2 (stderr) >>> massif/tests/deep-C (stderr) >>> massif/tests/peak2 (stderr) >>> massif/tests/realloc (stderr) > > Hi. I don't have reliable access to the 970, but in fact I get these > + 1 more failing when run on our 32-bit ppc box. So I attach those > instead. Thanks. These differences mostly don't look too bad. I think that the parts of the stack trace below "main" go a little deeper than on my machine, so when I print detailed stats about how many XPts are created, there are differences. I guess I'll have to filter those out. But the result for deep-D looks strange. Can you send me the massif.out file for it? Thanks. N |
|
From: Nicholas N. <nj...@cs...> - 2007-11-10 04:20:03
|
On Mon, 5 Nov 2007, Nicholas Nethercote wrote: > On Sun, 4 Nov 2007, Julian Seward wrote: > >>>> massif/tests/culling1 (stderr) >>>> massif/tests/culling2 (stderr) >>>> massif/tests/deep-C (stderr) >>>> massif/tests/peak2 (stderr) >>>> massif/tests/realloc (stderr) >> >> Hi. I don't have reliable access to the 970, but in fact I get these >> + 1 more failing when run on our 32-bit ppc box. So I attach those >> instead. > > Thanks. These differences mostly don't look too bad. I think that the > parts of the stack trace below "main" go a little deeper than on my machine, > so when I print detailed stats about how many XPts are created, there are > differences. I guess I'll have to filter those out. I've done this now. Nick |
|
From: Julian S. <js...@ac...> - 2007-11-04 22:24:24
Attachments:
massif.out-deep-D-r7087-glibc261-ppc32
|
> But the result for deep-D looks strange. Can you send me the massif.out > file for it? Thanks. Attached. J |
|
From: Nicholas N. <nj...@cs...> - 2007-11-05 02:15:34
|
On Sun, 4 Nov 2007, Julian Seward wrote:
>> But the result for deep-D looks strange. Can you send me the massif.out
>> file for it? Thanks.
>
> Attached.
This snapshot is strange:
#-----------
snapshot=9
#-----------
time=972
mem_heap_B=900
mem_heap_admin_B=72
mem_stacks_B=0
heap_tree=detailed
n1: 900 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
n1: 900 0xFE6737B: (within /lib/libc-2.6.1.so)
n1: 900 0xFE6759F: (below main) (in /lib/libc-2.6.1.so)
n0: 900 (heap allocation functions) malloc/new/new[], --alloc-fns, etc.
The last line is the problem, it shouldn't look like that. I'm using the
address 0 specially to refer to all the allocation functions. Could
VG_(get_StackTrace)() be returning 0 as an address at the bottom of the
stack trace? If so, I'll have to find a different way to encode the
allocation functions... maybe "(Addr)(-1L)".
Nick
|
|
From: Julian S. <js...@ac...> - 2007-11-05 02:24:05
|
> The last line is the problem, it shouldn't look like that. I'm using the > address 0 specially to refer to all the allocation functions. Could > VG_(get_StackTrace)() be returning 0 as an address at the bottom of the > stack trace? Well, it's plausible. The PowerPC ELF ABI specification says that "The back chain word of the first stack frame contains a null pointer (0)." So whether a zero back chain word can somehow give rise to a zero return address, I dunno. Maybe. (abi_elf_ppc64_1.7.pdf page 29). Presumably the ppc32 ELF ABI is similar, at least in this aspect. > If so, I'll have to find a different way to encode the > allocation functions... maybe "(Addr)(-1L)". Is it possible/easy to encode them some way that doesn't involve any magic Addr values? J |
|
From: Nicholas N. <nj...@cs...> - 2007-11-10 04:24:09
|
On Mon, 5 Nov 2007, Nicholas Nethercote wrote: > This snapshot is strange: > > #----------- > snapshot=9 > #----------- > time=972 > mem_heap_B=900 > mem_heap_admin_B=72 > mem_stacks_B=0 > heap_tree=detailed > n1: 900 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. > n1: 900 0xFE6737B: (within /lib/libc-2.6.1.so) > n1: 900 0xFE6759F: (below main) (in /lib/libc-2.6.1.so) > n0: 900 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. > > > The last line is the problem, it shouldn't look like that. I'm using the > address 0 specially to refer to all the allocation functions. Could > VG_(get_StackTrace)() be returning 0 as an address at the bottom of the > stack trace? If so, I'll have to find a different way to encode the > allocation functions... maybe "(Addr)(-1L)". Actually, that line shouldn't even be there, since Massif is supposed to ignore all stack frames below "main" or "(below main)". Hmm. Nick |