[DTrace-devel] [PATCH 03/20] libproc: dynamically search for elements of the rtld_global structure

[Nick Alcock]

On 20 May 2022, Kris Van Hees told this:

> On Fri, May 20, 2022 at 03:31:37PM -0400, Kris Van Hees wrote:
>> On Fri, May 20, 2022 at 03:29:21PM -0400, Kris Van Hees via DTrace-devel wrote:
>> > On Wed, May 11, 2022 at 10:12:45PM +0100, Nick Alcock via DTrace-devel wrote:
>> > > Unfortunately because most of these fields (other than dl_nns == 1) only
>> > > go nonzero when multiple lmids are in use (which is rare) or when
>> > > dlopen() is being called in the child (also rare), we can't really
>> > > verify our guesses the way we could for l_searchlist.  The existing
>> > > verification that when we look up a symbol in a nonzero lmid it actually
>> > > comes from a nonzero lmid will have to do.  This will almost certainly
>> > > be good enough, particularly given that all this machinery will be
>> > > disabled in favour of documented facilities when the victim is a binary
>> > > running against glibc 2.35+.
>> > > 
>> > > Orabug: 32856318
>> > > Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
>> > 
>> > Reviewed-by: Kris Van Hees <kris.van.hees at oracle.com>
>> > 
>> > ... modulo fixinng several cases where you have 8 leading spaces in case of a
>> >     tab.  I fixed those, and will put this on dev.

I really should find and fix the Emacs configuration bug that's causing
this. It's only been giving me grief for, oh, 25 years now.

>> Oh, and you also did not flip the test that is fixed by this to no longer be
>> XFAIL.  That is important to do - if a patch fixes a test (which will clearly
>> be shown when you test the patch) the test should be updated to reflect that
>> it now should pass.

... I didn't?! Whoops!

> Hm, I was a bit too hasty...
>
> Trying ttest/internals/libproc/tst.lmid-consistency.sh results in a PASS on OL8
> but a core dump on OL7.

OK, this is a long-known bug, but one I couldn't reproduce consistently
before. Now it's happening consistently:

libproc DEBUG 1653340982: Pwait: 7366: process status change at address 7ffff7de11f9: signal 127/5 does not correspond to a known breakpoint.

(and we never dropped a breakpoint there, so we pass the SIGTRAP on and
now we are doomed, the process will die and the test will fail).

This has prodded me into actually looking at it: will track it down
tomorrow.

Definitely not related to this change, the code I added isn't even
kicking in (and though the find_l_searchlist code does kick in, it
visibly works: we print the searchlist in the DTRACE_DEBUG output and it
looks fine, at least in my tests).