Re: Where is that trap coming from?

[Emmanuel Dreyfus <manu%netbsd.org@localhost>]

On Fri, Feb 08, 2019 at 04:34:55PM +0100, Martin Husemann wrote:
> You need to check the details of the system call, 

I checked the read calls, arguments are sane: all buffer memory is mapped.

Let us go back in crash:

crash> bt/a cc1d2aa0
trace: pid 5109 lid 3 at 0xdd696e9c
sigswitch(0,b,1,c112be2c,ffffffff,c7c59dd0,c7c59f08,0,cc1d2c58,cc1d2c58) at sigs
witch+0xa5
issignal(cc1d2aa0,0,400,0,caa745c8,dd696f54,c7c59df4,cc1d2aa0,dd696fa8,104) at i
ssignal+0x1fc
lwp_userret(cc1d2aa0,dd696f54,dd694000,b52220e0,c,91093,c6027b2c,0,c131ec40,dd69
6f60) at lwp_userret+0x1c3
trap() at trap+0x96e
--- trap (number 4) ---
b7c21459:

lwp 3 would be the culprit? Back in gdb:
(gdb) thread 4
[Switching to thread 4 (LWP 3)]
#0  0xb7c21459 in ___lwp_park60 () from /lib/libc.so.12
(gdb) bt
#0  0xb7c21459 in ___lwp_park60 () from /lib/libc.so.12
#1  0xff0077d3 in ?? ()

(gdb) x/5i ___lwp_park60
   0xb7c21450 <___lwp_park60>:  mov    $0x1de,%eax
   0xb7c21455 <___lwp_park60+5>:        int    $0x80
   0xb7c21457 <___lwp_park60+7>:        jb     0xb7c2145a <___lwp_park60+10>
=> 0xb7c21459 <___lwp_park60+9>:        ret  

I was wrong, it was not inside a system call: it crashes when 
leaving the system call stub, because return address is invalid.

Now I have to figure how it can happen;

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost