Summary: | callgrind crash on amd64 | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Harri Pasanen <bugsbyhp> |
Component: | callgrind | Assignee: | Josef Weidendorfer <josef.weidendorfer> |
Status: | RESOLVED DUPLICATE | ||
Severity: | crash | CC: | bugsbyhp, jseward |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Harri Pasanen
2009-12-08 14:31:43 UTC
> Looking at the trace, the symbols are long, so it might be running out of > stack? But it does not look like demangle bug. It still looks suspiciously similar to bug 197988. Can you check if increasing VG_STACK_ACTIVE_SZB to 2 Mb fixes your problem? It does not build with VG_STACK_ACTIVE_SZB set to 2Mb (2147483648), 3.5.0 compilation fails with make[3]: Entering directory `/home/harri/src/valgrind-3.5.0/coregrind' if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"amd64-linux\"" -m64 -fomit-frame-pointer -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -MT libcoregrind_amd64_linux_a-m_main.o -MD -MP -MF ".deps/libcoregrind_amd64_linux_a-m_main.Tpo" -c -o libcoregrind_amd64_linux_a-m_main.o `test -f 'm_main.c' || echo './'`m_main.c; \ then mv -f ".deps/libcoregrind_amd64_linux_a-m_main.Tpo" ".deps/libcoregrind_amd64_linux_a-m_main.Po"; else rm -f ".deps/libcoregrind_amd64_linux_a-m_main.Tpo"; exit 1; fi /tmp/ccKVPsyr.s: Assembler messages: /tmp/ccKVPsyr.s:18: Error: suffix or operands invalid for `add' make[3]: *** [libcoregrind_amd64_linux_a-m_main.o] Error 1 However, with 1 Mb stack (0x40000000) it compiles, but when using that my process promptly runs out of memory. 0x10000000, or 256Kb worked for me, so it does seem it is a stack size issue. But I guess memory usage can still be an issue when lots of threads are running. > VG_STACK_ACTIVE_SZB set to 2Mb (2147483648) Oh, you set it to 2Gb. I wouldn't expect this to work ;-) 2Mb are 2097152. > 0x10000000, or 256Kb worked for me That is 256MB not 256Kb. Nice to hear that Valgrind works with such a huge tool stack. So it really seems to be a duplicate of bug 197988. > But I guess memory usage can still be an issue when lots of threads are > running. This is about the tool's stack. Hmm. I do not think that there will be multiple VG tool stacks allocated if the client code has multiple threads (valgrind serializes execution of threads). So this should not be an issue. Oops, I was thinking big there... (or rather not really thinking at all). I'll run a few tests to see what still works. The 64Kb is probably too small default for heavily templated C++ code and my app might be a good guinea pig to provide a real world 'worst case' behaviour. My app seems to work fine with 256 Kb stack as well. But running with the accidentally put 256 Mb stack the my process eats up ~3Gb of virtual memory. With 256 Kb stack it is only ~1.2Gb. So the additional memory consumption seems to be a multiple of VG_STACK_ACTIVE_SZB, even if not in relation to number of client threads... *** This bug has been marked as a duplicate of bug 197988 *** |