The assembly looks like junk and considering the adresses, you have tried to disassemble some memory on the stack. Is this a 64-bit wfica binary?
Either way, this seems to be a completely different case. How does the backtrace look like? 2016-02-26 13:01 GMT+01:00 Patrick Welche <pr...@cam.ac.uk>: > On Fri, Feb 26, 2016 at 09:22:38AM +0100, Stephan wrote: >> I still recommend Receiver for HTML5 in this case. >> >> The dump looks like a mess and eventually gdb is unable to process >> this dump of a Linux binary on NetBSD correctly. It would be >> interesting to know what is mapped at 0xba90004d. You could break at >> that adress (b *0xba90004d) and check with pmap. Also, what´s the >> corresponding instruction (x/i 0xba90004d)? > > Getting to stop while running for the pmap is proving interesting (need > authentication via pnbrowse before dump in wfica). > > The instruction seems to always be the same though: > > Core was generated by `wfica'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x00007f7fee73a9f4 in ?? () > [Current thread is 1 (process 27767)] > (gdb) x/20i 0x00007f7fee73a9e8 > 0x7f7fee73a9e8: add %al,(%rax) > 0x7f7fee73a9ea: add %al,(%rax) > 0x7f7fee73a9ec: add %al,(%rax) > 0x7f7fee73a9ee: add %al,(%rax) > 0x7f7fee73a9f0: push %rsi > 0x7f7fee73a9f1: rex.R > 0x7f7fee73a9f2: rex.RB push %r13 > => 0x7f7fee73a9f4: rex.RB > 0x7f7fee73a9f5: rex.WRB > 0x7f7fee73a9f6: cs rex.R > 0x7f7fee73a9f8: rex.WR > 0x7f7fee73a9f9: rex.WR add %r8b,(%rax) > 0x7f7fee73a9fc: add %dl,0x75(%rcx) > 0x7f7fee73a9ff: gs jne 0x7f7fee73aa67 > 0x7f7fee73aa02: add %al,(%rax) > 0x7f7fee73aa04: add %al,(%rax) > 0x7f7fee73aa06: add %al,(%rax) > 0x7f7fee73aa08: stc > 0x7f7fee73aa09: mov %al,%al > 0x7f7fee73aa0b: idivl 0x7f(%rdi) > > > Cheers, > > Patrick