07.12.2010 00:57, Roland McGrath wrote:
If you think your sharing_stack fix makes it good, then
s/stackish/sharing_stack/ in dwarf and dwarf_tracker. That's the only way
to get the code back in use. Doing so should reduce the memory footprint
of dwarfcmp (and some of dwarf_output stuff) by a lot, and maybe help CPU
use too. If that works without new regressions or strangeness, then it's
all good.
I turned it on. I did a couple tests (dwarfcmp X X for several Xs of
various sizes, but none really huge) and got no leaks or crashes (or
memory warnings in valgrind).
I'm doing make check now, one core is spinning on "dwarf" branch and has
been like that for about four hours now. It's stuck on "dwarfcmp
dwarfcmp dwarfcmp".
The other core checks "roland/dwarf-hacking" with the sharing_stack
fixes applied on top. That one got through all the "dwarfcmp" tests,
then there's a bunch of failures due to "dwarfcmp-test" throwing
std::logic_error (these are not new), and now it's stuck on
"dwarfcmp-test dwarfcmp dwarfcmp". Apparently the DIE graph of dwarfcmp
is a nasty case. I cross-checked on a beefy machine with stackish
instead of sharing_stack, and it gets stuck the same way, so that's not
either.
All in all, I'm inclined to vouch for that fix.
PM