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 _______________________________________________ elfutils-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/elfutils-devel
