Re: Making sense of ktrace
On 11/23/16 8:25 PM, Jeremie Courreges-Anglas wrote: "Andy Bradford" writes: Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: The stack may indeed be too damaged--I get the following but it doesn't look very helpful: More likely the symbols were stripped. Assuming this was installed from sources, edit conf-cc and add -g, then edit conf-ld and remove the -s: $ head -1 conf-cc cc -O2 -g $ head -1 conf-ld cc Better add -g here too. $ Then recompile and try again (e.g. get a new core file and run gdb again). Andy I made the change to conf-cc and conf-ld and indeed, I got a core file that showed the source and the point of failure. Thanks Andy and Jeremie! Jeff
Re: Making sense of ktrace
"Andy Bradford" writes: > Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: > >> The stack may indeed be too damaged--I get the following but it >> doesn't look very helpful: > > More likely the symbols were stripped. > > Assuming this was installed from sources, edit conf-cc and add -g, then > edit conf-ld and remove the -s: > > $ head -1 conf-cc > cc -O2 -g > $ head -1 conf-ld > cc Better add -g here too. > $ > > Then recompile and try again (e.g. get a new core file and run gdb > again). > > Andy -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Making sense of ktrace
Thus said Jeff Ross on Wed, 23 Nov 2016 15:42:08 -0700: > The stack may indeed be too damaged--I get the following but it > doesn't look very helpful: More likely the symbols were stripped. Assuming this was installed from sources, edit conf-cc and add -g, then edit conf-ld and remove the -s: $ head -1 conf-cc cc -O2 -g $ head -1 conf-ld cc $ Then recompile and try again (e.g. get a new core file and run gdb again). Andy -- TAI64 timestamp: 4000583654c6
Re: Making sense of ktrace
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,0x1002,-1,0)
47868 fastforward RET mmap 9049032314880/0x83ae45b5000
47868 fastforward CALL
mmap(0,0x1000,0x3,0x1002,-1,0)
47868 fastforward RET mmap 9049215606784/0x83aef482000
47868 fastforward CALL
mmap(0,0xa000,0x3,0x1002,-1,0)
47868 fastforward RET mmap 9047796883456/0x83a9ab82000
47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1)
47868 fastforward RET mprotect 0
47868 fastforward CALL munmap(0x83a9ab82000,0xa000)
47868 fastforward RET munmap 0
47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1)
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,0x1002,-1,0)
47868 fastforward RET mmap 9049102131200/0x83ae884a000
47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1)
47868 fastforward RET mprotect 0
47868 fastforward CALL
mprotect(0x83ae884a000,0x1000,0x3)
47868 fastforward RET mprotect 0
47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1)
47868 fastforward RET mprotect 0
47868 fastforward CALL sigaction(SIGPIPE,0x7f7cdec0,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 0x0115d4803035 in ?? () from /var/qmail/bin/fastforward
(gdb) bt
#0 0x0115d4803035 in ?? () from /var/qmail/bin/fastforward
#1 0x0115d4802545 in ?? () from /var/qmail/bin/fastforward
#2 0x0115d48015f2 in ?? () from /var/qmail/bin/fastforward
#3 0x in ?? ()
(gdb)
I built fastforward with
cc -g -O0 -include /usr/include/errno.h -pipe
is there a better incantation?
Thanks again!
Jeff
Re: Making sense of ktrace
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,0x1002,-1,0)
> 47868 fastforward RET mmap 9049032314880/0x83ae45b5000
> 47868 fastforward CALL
> mmap(0,0x1000,0x3,0x1002,-1,0)
> 47868 fastforward RET mmap 9049215606784/0x83aef482000
> 47868 fastforward CALL
> mmap(0,0xa000,0x3,0x1002,-1,0)
> 47868 fastforward RET mmap 9047796883456/0x83a9ab82000
> 47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1)
> 47868 fastforward RET mprotect 0
> 47868 fastforward CALL munmap(0x83a9ab82000,0xa000)
> 47868 fastforward RET munmap 0
> 47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1)
> 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,0x1002,-1,0)
> 47868 fastforward RET mmap 9049102131200/0x83ae884a000
> 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1)
> 47868 fastforward RET mprotect 0
> 47868 fastforward CALL
> mprotect(0x83ae884a000,0x1000,0x3)
> 47868 fastforward RET mprotect 0
> 47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1)
> 47868 fastforward RET mprotect 0
> 47868 fastforward CALL sigaction(SIGPIPE,0x7f7cdec0,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
Making sense of ktrace
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,0x1002,-1,0)
47868 fastforward RET mmap 9049032314880/0x83ae45b5000
47868 fastforward CALL
mmap(0,0x1000,0x3,0x1002,-1,0)
47868 fastforward RET mmap 9049215606784/0x83aef482000
47868 fastforward CALL
mmap(0,0xa000,0x3,0x1002,-1,0)
47868 fastforward RET mmap 9047796883456/0x83a9ab82000
47868 fastforward CALL mprotect(0x83b09fd2000,0x1000,0x1)
47868 fastforward RET mprotect 0
47868 fastforward CALL munmap(0x83a9ab82000,0xa000)
47868 fastforward RET munmap 0
47868 fastforward CALL mprotect(0x83870f07000,0x1000,0x1)
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,0x1002,-1,0)
47868 fastforward RET mmap 9049102131200/0x83ae884a000
47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1)
47868 fastforward RET mprotect 0
47868 fastforward CALL
mprotect(0x83ae884a000,0x1000,0x3)
47868 fastforward RET mprotect 0
47868 fastforward CALL mprotect(0x83ae884a000,0x1000,0x1)
47868 fastforward RET mprotect 0
47868 fastforward CALL sigaction(SIGPIPE,0x7f7cdec0,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"
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
