Summary: | Helgrind: program has too many thread sets or lock sets to track | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Chris Moore <dooglus> |
Component: | helgrind | Assignee: | Julian Seward <jseward> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | njn |
Priority: | NOR | ||
Version: | 3.4 SVN | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Chris Moore
2008-02-28 23:16:51 UTC
> Helgrind: Fatal internal error -- cannot continue.
> Helgrind: mk_SHVAL_ShR(tset=19,lset=356247): FAILED
Urr, that's something we will have to fix properly for the 3.4
series. Unfortunately fixing it properly soaks up even more
memory and CPU resources.
In the meantime try the following kludge. Find
#define N_LSID_BITS 17
at hg_main.c:899 or thereabouts. Change it to 18, rebuild,
try again. It may still die; try 18, 19, 20, etc. Let me know
if it works/does not work.
Looks like you application allocated and deallocates a very
large number of locks. Yes? If so you might be able to
avoid the problem by reusing locks rather than deallocating
the memory they occupy, and then reallocate them.
It does allocate a large number of locks, but doesn't use most of them I think. It took 3 or 4 hours to get to the point of crashing, so it's going to take a while to find the optimum number of bits. The problem I'm trying to debug doesn't show up on Linux at all - only on Windows, but I've been unable to find any memory debugging tool like valgrind that will work with gcc-linked applications on Windows. Even the commercial 'purify' app doesn't support gcc (mingw) so I'm hoping I can find the problem using valgrind/helgrind on Linux. Julian, what's the status of this one? The FAQ.txt message has been fixed, so I'm renaming this bug to reflect the crash. |