On 11/23/16 1:16 PM, Otto Moerbeek wrote:
On Wed, Nov 23, 2016 at 12:37:12PM -0700, Jeff Ross wrote:
Hi all,
I've got a program that seg faults on OpenBSD 6.0 AMD64 release that runs
fine on 5.9 i386.
I'm checking to see if will also run on 5.9 AMD64 right now but it doesn't
appear to be w^x related. To be sure I've mounted that partition with
wxallowed.
Here are the last few lines from kdump--would sure appreciate it if someone
could shed some light on what's happening.
47868 fastforward CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
47868 fastforward RET mmap 9049032314880/0x83ae45b5000
47868 fastforward CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
47868 fastforward RET mmap 9049215606784/0x83aef482000
47868 fastforward CALL
mmap(0,0xa000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
47868 fastforward RET mmap 9047796883456/0x83a9ab82000
47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1<PROT_READ>)
47868 fastforward RET mprotect 0
47868 fastforward CALL munmap(0x83a9ab82000,0xa000)
47868 fastforward RET munmap 0
47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1<PROT_READ>)
47868 fastforward RET mprotect 0
47868 fastforward CALL getthrid()
47868 fastforward RET getthrid 1047868/0xffd3c
47868 fastforward CALL __set_tcb(0x83b14ce3600)
47868 fastforward RET __set_tcb 0
47868 fastforward CALL
mmap(0,0x1000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,-1,0)
47868 fastforward RET mmap 9049102131200/0x83ae884a000
47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1<PROT_READ>)
47868 fastforward RET mprotect 0
47868 fastforward CALL
mprotect(0x83ae884a000,0x1000,0x3<PROT_READ|PROT_WRITE>)
47868 fastforward RET mprotect 0
47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1<PROT_READ>)
47868 fastforward RET mprotect 0
47868 fastforward CALL sigaction(SIGPIPE,0x7f7ffffcdec0,0)
47868 fastforward STRU struct sigaction { handler=SIG_IGN, mask=0<>,
flags=0<> }
47868 fastforward RET sigaction 0
47868 fastforward PSIG SIGSEGV SIG_DFL code SEGV_MAPERR<1> addr=0x71008620
trapno=6
47868 fastforward NAMI "fastforward.core"
The program is aborted by a SIGSEGV. Thta means it is accessing a
memory location that is not allocated by the program.
I've re-compiled this also with what I found on the internet to make a core
file that gdb can use but that's even more of a mystery to me than ktrace.
Is there a better debugger that I can use?
Thanks,
Jeff Ross
$ gdb fastforward fastforward.core
then type the command bt, should give you some clue, if the stack isn't
damaged too much.
-Otto
Thank you, Otto!
The stack may indeed be too damaged--I get the following but it doesn't
look very helpful:
jross@luna:/package/mail/sqmail/sqmail-3.2.13 $ sudo gdb
/var/qmail/bin/fastforward fastforward.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.0"...(no debugging
symbols found)
Core was generated by `fastforward'.
Program terminated with signal 11, Segmentation fault.
(no debugging symbols found)
Loaded symbols for /var/qmail/bin/fastforward
Reading symbols from /usr/lib/libc.so.88.0...done.
Loaded symbols for /usr/lib/libc.so.88.0
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 0x00000115d4803035 in ?? () from /var/qmail/bin/fastforward
(gdb) bt
#0 0x00000115d4803035 in ?? () from /var/qmail/bin/fastforward
#1 0x00000115d4802545 in ?? () from /var/qmail/bin/fastforward
#2 0x00000115d48015f2 in ?? () from /var/qmail/bin/fastforward
#3 0x0000000000000000 in ?? ()
(gdb)
I built fastforward with
cc -g -O0 -include /usr/include/errno.h -pipe
is there a better incantation?
Thanks again!
Jeff
