memcheck/tests/addressable is failing

[paulfloyd]

Unfiltered the output is ==85690== Process terminating with default action of signal 11 (SIGSEGV) ==85690== Access not within mapped region at address 0x5057000 ==85690== at 0x4011FA: test2 (addressable.c:54) ==85690== by 0x401732: main (addressable.c:128) ==85690== If you believe this happened as a result of a stack ==85690== overflow in your program's main thread (unlikely but ==85690== possible), you can try to increase the size of the ==85690== main thread stack using the --main-stacksize= flag. ==85690== The main thread stack size used in this run was 16777216.

The filtered output should be

Process terminating with default action of signal N (SIGSEGV or SIGBUS) Bad memory (SIGSEGV or SIGBUS) at address 0x........ at 0x........: test4 (addressable.c:77) by 0x........: main (addressable.c:128)

but I'm getting Process terminating with default action of signal N (SIGSEGV or SIGBUS) at 0x........: test4 (addressable.c:77) by 0x........: main (addressable.c:128)

(missing the 'Bad memory' line)

Looks like just a filtering issue

[nbriggs]

The unfiltered output included there is for the prior test (addressable.c:54), not the one that's reporting unexpected output (addressable.c:77). The unfiltered output I see is:

==21069== 
==21069== Process terminating with default action of signal 10 (SIGBUS)
==21069==    at 0x401973: test4 (addressable.c:77)
==21069==    by 0x40136A: main (addressable.c:128)

So it's missing the line that the filter would have replaced by the 'Bad memory' line, i.e. (Bad permissions for mapped region|Access not within mapped region|Non-existent physical address) at address 0x

[nbriggs]

--22270-- sync signal handler: signal=10, si_code=12, EIP=0x401973, eip=0x53aa1b5, from kernel
--22270-- delivering signal 10 (SIGBUS):12 to thread 1
--22270-- delivering 10 (code 12) to default handler; action: terminate+core
==22270== 
==22270== Process terminating with default action of signal 10 (SIGBUS)

vki-freebsd.h only defines codes of 1, 2, and 3 but at m_signals.c:1902 we see the 12 (above). I haven't traced back what that's supposed to mean compared to the ones that have definitions.

[nbriggs]

The kernel source doesn't admit to there being an si_code of 12 for SIGBUS, at least not at /usr/src/sys/sys/signal.h:314 or, as far as I can see, in the source where it handles machine traps.

[paulfloyd]

The only thing I can think of off the top of my head is maybe there is some SIGBUS/SIGSEVG confusion and

define VKI_SEGV_PAGE_FAULT 12

is being used.

[paulfloyd]

I haven't debugged this category of issue yet, other than a bit of running with "--trace-signals=yes". We're not handling signals correctly. See this Valgrind issue. I did just push a change that affects a couple of issues, but not this one.

[nbriggs]

In /usr/src/sys/i386/i386/trap.c lines 430-440 in the 12.1 release sources it can deliver a SIGBUS with a T_PAGEFLT (=12) as the si_code. The same thing happens in the amd64/amd64/trap.c

It had to have taken a page fault trap and in my case machdep.prot_fault_translation=0, which means that !(SV_CURPROC_ABI() == SV_ABI_FREEBSD && p->p_osrel >= P_OSREL_SIGSEGV)

Personally, I think that's buggy behavior, since it's documented that on a SIGBUS the si_trapno is set, and that's where the T_PAGEFLT should have gone, n'est-ce pas?

[nbriggs]

Looks as though the signal generating code has all been rewritten -- https://svnweb.freebsd.org/base?view=revision&revision=352807 -- so this may all be moot.

[paulfloyd]

That matches what I've seen. none/tests/faultstatus is similar, the testcase expects a SIGBUS from an access to a page that is after a mapped file, but a SIGSEGV is generated.

[paulfloyd]

I added the same message as SIGSEGV/VKI_SEGV_PAGE_FAULT and also VKI_BUS_OOMERR.