|
From: Christian B. <bor...@de...> - 2014-10-08 15:22:48
|
Am 25.09.2014 09:34, schrieb Christian Borntraeger:
> On 09/25/2014 06:14 AM, Christian Borntraeger wrote:
>> valgrind revision: 14566
>> VEX revision: 2959
>> C compiler: gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
>> GDB: GNU gdb (GDB) SUSE (7.5.1-0.7.29)
>> Assembler: GNU assembler (GNU Binutils; SUSE Linux Enterprise 11) 2.23.1
>> C library: GNU C Library stable release version 2.11.3 (20110527)
>> uname -mrs: Linux 3.0.101-0.35-default s390x
>> Vendor version: Welcome to SUSE Linux Enterprise Server 11 SP3 (s390x) - Kernel %r (%t).
>>
>> Nightly build on sless390 ( SUSE Linux Enterprise Server 11 SP3 gcc 4.3.4 on z196 (s390x) )
>> Started at 2014-09-25 03:45:01 CEST
>> Ended at 2014-09-25 06:14:46 CEST
>> 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
>>
>> == 661 tests, 3 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
>> memcheck/tests/origin5-bz2 (stderr)
>> helgrind/tests/pth_cond_destroy_busy (stderr)
>> helgrind/tests/tc20_verifywrap (stderr)
>>
>> --tools=none,memcheck,callgrind,helgrind,cachegrind,drd,massif --reps=3 --vg=../valgrind-new --vg=../valgrind-old
> [....]
>> many-xpts valgrind-new:0.07s no: 0.6s ( 9.0x, -----) [...] ca:374.8s (5353.6x, -----) [...]
>> many-xpts valgrind-old:0.07s no: 0.6s ( 9.0x, 0.0%) [...] ca:371.9s (5312.4x, 0.8%) [...]
>
> This testcase is really weird. All other tests run fine within seconds, but this takes several minutes. When running the same test in the nightly folder it finishes after 3-4 seconds. No idea what is happening here right now.
>
> Any guesses?
I can now reproduce this manually. The code spends huge amount of times in
void CLG_(setup_bbcc)(BB* bb) (callgrind/bbcc.c)
in this while loop:
while(1) {
if (top_ce->ret_addr == bb_addr(bb)) break;
if (csp_up>0) {
csp_up--;
top_ce = &(CLG_(current_call_stack).entry[csp_up]);
if (top_ce->sp == sp) {
popcount_on_return++;
continue;
}
}
popcount_on_return = 0;
break;
}
The reason is that the value of csp is increasing during that testcase to insanely high values.
I have to admit, that I dont fully understand that code, so any ideas are welcome.
|