SIGBUS si_code 12

[Paul Floyd]

> On 21 May 2020, at 17:46, Mark Johnston <markj at freebsd.org> wrote:
>> 
> 
> Assuming that the context is valgrind, the issue is probably that the
> client program is being run with without a NT_FREEBSD_ABI_TAG note, so
> the kernel does not have p_osrel defined for the client process and thus
> reverts to the legacy behaviour of delivering SIGBUS with UCODE_PAGEFLT.
> This behaviour is not documented since it is only present for
> compatibility with old binaries.
> 
> valgrind should probably embed the NT_FREEBSD_ABI_TAG note from the
> target executable into the client process somehow.

Hi Mark

You assume correctly, this is in the context of running under Valgrind. It’s one of the regression test suite applications, memcheck/tests/addressable

I hadn’t noticed that the executable was generating SIGSEGV when running standalone. The test runs a loop 5 fimes, each time round the loop it forks and the child calls a function that will generate one kind of SIGBUS or SIGSEGV. The parent just checks that the child died with one of these signals. I just ran the executable under gdb and I do see that the error that was posing a problem does generate a SIGSEGV with si_cde 2.

Back in Valgrind, nothing is currently being done with NT_FREEBSD_ABI_TAG, The only thing that I can see that is of this nature is the read elf code that is looking for the buildid. I’ll have a go at seeing if I can read the value of NT_FREEBSD_ABI_TAG, but I’m not sure what to do with it at the moment.

A+
Paul