|
From: Jeremy F. <je...@go...> - 2002-10-20 20:54:06
|
On Sun, 2002-10-20 at 13:15, Julian Seward wrote:
Hi. Thx for the helgrind fixes. I merged the following patches into
the head this afternoon:
03-poll-select (is also in 1.0.4)
04-lax-ioctls (is also in 1.0.4)
07-seginfo
13-data-syms
14-hg-tid
06-memops
15-hg-datasym
16-ld-nodelete
I think Nick has already merged 08-skin-clientreq.
Excellent. I'll merge and regenerate my patchset.
I just tried a run of mozilla-1.0.1 on the fully patched helgrind.
There are bazillions of errors reported for the _dl_num_relocations
problem which we already know about (even with LD_BIND_NOW=y). If
those were to be got rid of somehow, the remaining ones are sufficiently
few that they might actually tell us something useful.
Yes, LD_BIND_NOW will only work for simple dynamically linked programs
which do all their linking at startup (ie, while single threaded).
Presumably Mozilla is still dynamically linking things well into its
life, with multiple threads.
Which is a step in the right direction.
Any ideas how to get rid of this blasted _dl_num_relocations thing?
Perhaps helgrind can check to see if the variable in question is
indeed _dl_num_relocations, and suppress the error if so?
Well, obviously Helgrind needs to be taught how to understand
suppressions, and we need to start building a standard suppression
file. I also think the handling of duplicate errors needs to be a bit
different from Memcheck and so on. Memcheck considers the error context
to be the same if there's matching portions of the stack backtrace. I
think for helgrind, the memory location itself is all that's
interesting: it doesn't matter what the call frames are (for the
purposes of suppression; obviously you need them for reporting).
Also, the increment of _dl_num_locations is probably an atomic inc
anyway (probably a simple addl $1, _dl_num_locations), so it doesn't
really count as an error at all. I'm not planning on teaching helgrind
about atomic operations just yet, but it is an obvious path for future
work.
Another interesting test is tests/unused/pth_threadpool; this gives
a large number of errors, many of which pertain to _IO_2_1_stdout_.
Yes, I noticed there were a number of reports coming out of stdio, but I
haven't looked into it yet. Quite possibly they're atomic ops as well.
Or just bugs.
J
|