On 28 December 2015 at 22:22, Josh Grosse <[email protected]> wrote: > I'm trying to assist Casey Hancock with illegal instruction exceptions, > reported earlier: > > http://marc.info/?t=145103079400015&r=1&w=2 > http://marc.info/?t=145111278100001&r=1&w=2 > > But I'm very weak on tracking syscalls through the userland .core files > Casey has provided. I'm not sure if ktrace(1) will add any value to > finding the root cause, which I assume is a branch into data, but I have > no clear understanding of how to discern where it's happening, and I > I could use some guidance, as otherwise it's just the blind leading > the blind. > > At this time, I've provided Casey with a -current release(8) so I have > a source tree I can ensure is in sync with executed binaries. Each > failure of a userland program is an illegal instruction, and each time, > there's a syscall being executed in frame 0. I've seen poll(2), kevent(2), > waitpid(2), and others, and I am unsure how to -- or if I can -- get any > value from the .core files produced. These appear to be valid stack traces, > from the calling frame, as shown below. > > A cluestick would be very helpful. I'm sure there's something obvious > I'm overlooking. Thanks in advance! >
forgive me if i've overlooked something, but when faced with a SIGILL, you might want to investigate which instruction is executed that causes this. to do this you need to look at program counter in the relevant frame so dumping registers and figuring out where does %rip point to in the .text segment. please note that %rip value in the frame might point to the next instruction.
