Test failures on PPC (Fedora 11, Rawhide)

[Google Code Exporter]

From the ppc failure log:
Fedora 11:
http://koji.fedoraproject.org/koji/getfile?taskID=1449784&name=build.log
Fedora 12 (Rawhide):
http://koji.fedoraproject.org/koji/getfile?taskID=1450299&name=build.log

While running:
LD_LIBRARY_PATH=./.libs make check

On ppc, it fails on this test:

...

Obtained 10 stack frames.
Obtained 10 stack frames.
./stacktrace_unittest [0x10000754] 0x10000754
./stacktrace_unittest [0x10000954] 0x10000954
./stacktrace_unittest [0x10000998] 0x10000998
./stacktrace_unittest [0x100009e8] 0x100009e8
./stacktrace_unittest [0x10000a38] 0x10000a38
./stacktrace_unittest [0x10000a88] 0x10000a88
./stacktrace_unittest [0x10000ac4] 0x10000ac4
/lib/libc.so.6 [0xfbbf51c] 0xfbbf51c
/lib/libc.so.6 [0xfbbf6c0] 0xfbbf6c0
[(nil)] (nil)
CheckStackTrace() addr: 0x10000a60
Backtrace 0: expected: 0x10000710..0x10000750  actual: 0x10000754 ... Check
failed: ret_addr <= (void *) ((char *) function_start_addr + kMaxFnLen)
FAIL: stacktrace_unittest

...

Original issue reported on code.google.com by [e-mail] on 2 Jul 2009 at 5:37

[Google Code Exporter]

Interesting.  Are the other tests passing?  This test has to make a guess how 
big
each function will be, and may get it wrong on some architectures.

Can you run the test in gdb:
   LD_LIBRARY_PATH=.libs gdb .libs/lt-stacktrace_unittest
or something similar.

You can just put a breakpoint in main, and do something like
   x 0x10000754
what function is it in?  Is it the same function as
  x 0x10000710
?

Likewise for some of the other addresses it prints out (10000954, etc).

Original comment by [e-mail] on 2 Jul 2009 at 6:34

• Added labels: Priority-Medium, Type-Defect

[Google Code Exporter]

(gdb) x 0x10000754
0x10000754 <printf>:    0x7fe4fb78
(gdb) x 0x10000710
0x10000710 <_Z19CheckStackTraceLeafv>:  0x9421ffa0
(gdb) x 0x10000954
0x10000954 <_Z16CheckStackTrace4i+36>:  0x37ffffff
(gdb) x 0x10000998
0x10000998 <_Z16CheckStackTrace3i+40>:  0x37ffffff
(gdb) x 0x100009e8
0x100009e8 <_Z16CheckStackTrace2i+40>:  0x37ffffff
(gdb) x 0x10000a38
0x10000a38 <_Z16CheckStackTrace1i+40>:  0x37ffffff
(gdb) x 0x10000a88
0x10000a88 <_Z15CheckStackTracei+40>:   0x37ffffff
(gdb) x 0x10000ac4
0x10000ac4 <printf>:    0x3c801000

And yes, all the other tests pass.

Original comment by [e-mail] on 2 Jul 2009 at 8:20

[Google Code Exporter]

Weird.  That doesn't seem quite plausible to me that printf is at 0x10000754.  I
wonder what's going on here.

One more debugging question: can you do
   (gdb) disassemble 0x10000710
and also
   (gdb) disassemble 0x10000754
?

That will tell us how long these functions are, so we can see what's going on 
better.

Original comment by [e-mail] on 2 Jul 2009 at 8:26

[Google Code Exporter]

Any more news on this?  We changed this test a bit in perftools 1.4; if the bug
report was on an earlier version, I wonder if you could try the latest and see 
if you
still get a failure.

Original comment by [e-mail] on 14 Oct 2009 at 11:23

[Google Code Exporter]

Any more news on this?  If not, I'll have to close it CannotReproduce (I don't 
have a 
ppc machine for testing on, unfortunately).

Original comment by [e-mail] on 10 Mar 2010 at 6:14

[Google Code Exporter]

Go ahead and close it. The PPC folks can re-open if they're interested.

Original comment by [e-mail] on 10 Mar 2010 at 6:23

[Google Code Exporter]

OK, done.

Original comment by [e-mail] on 10 Mar 2010 at 6:51

• Changed state: CannotReproduce