Re: truss -f timeout 2 sleep 10 causes breakage
On Wed, Mar 27, 2024 at 01:00:07PM +0100, Mateusz Guzik wrote: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. > > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. The issue is because debugger can stop the debuggee, which makes the single threading never succeed. Supposed fix is in https://reviews.freebsd.org/D44523 the cost is that in principle, the debuggee now can try to break out of the reaper kill hammer, with the help of debugger. But this setup is arguably too convoluted: you either control the process with reaper, or with debugger. > > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets > stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig > _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl > amd64_syscall fast_syscall_common This is because the threaded workqueue thread is stuck waiting for single-threading of the victim. > > It does react to -9 though. Not the workqueue, which is the problem.
Re: truss -f timeout 2 sleep 10 causes breakage
Mateusz Guzik writes: > Top of main, but I reproduced it on stable/14-e64d827d3 as well. Confirmed on 14.0-RELEASE-p5. > Mere "timeout 2 sleep 10" correctly times out. > > Running "truss -f timeout 2 sleep 10" prevents timeout from killing > sleep This is sort of expected as truss(1) uses ptrace(2) which breaks the parent-child relationship, so you should never use `truss -f` with a command that expects to control its children. > and the entire thing refuses to exit, truss has to be killed off > with SIGKILL. This, however, is not expected. > Here is the best part: after doing the above, going back to mere > "timeout 2 sleep 10" (without truss!) no longer works Neither is this. DES -- Dag-Erling Smørgrav - d...@freebsd.org
truss -f timeout 2 sleep 10 causes breakage
Top of main, but I reproduced it on stable/14-e64d827d3 as well. Mere "timeout 2 sleep 10" correctly times out. Running "truss -f timeout 2 sleep 10" prevents timeout from killing sleep and the entire thing refuses to exit, truss has to be killed off with SIGKILL. Here is the best part: after doing the above, going back to mere "timeout 2 sleep 10" (without truss!) no longer works -- timeout gets stuck in the kernel: mi_switch sleepq_catch_signals sleepq_wait_sig _sx_xlock_hard stop_all_proc_block kern_procctl sys_procctl amd64_syscall fast_syscall_common It does react to -9 though. -- Mateusz Guzik
Re: Deadlock involving truss -f, pdfork() and wait4()
As Conrad has pointed out, it's an explicit PID. The test completes successfully when not run under truss -f. On Fri, Sep 13, 2019 at 2:37 PM Mark Johnston wrote: > > On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > > This gets me a little further but now the wait4 call by the parent > > never reaps the child and instead blocks forever: > > Does it perform a wildcarded wait(), or does it explicitly specify the > PID of the child? By design, the former will not return children > created by pdfork(). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deadlock involving truss -f, pdfork() and wait4()
On Fri, Sep 13, 2019 at 11:37 AM Mark Johnston wrote: > > On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > > This gets me a little further but now the wait4 call by the parent > > never reaps the child and instead blocks forever: > > Does it perform a wildcarded wait(), or does it explicitly specify the > PID of the child? By design, the former will not return children > created by pdfork(). Explicit PID: https://people.freebsd.org/~rstone/pdfork.c Best, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deadlock involving truss -f, pdfork() and wait4()
On Fri, Sep 13, 2019 at 02:12:56PM -0400, Ryan Stone wrote: > This gets me a little further but now the wait4 call by the parent > never reaps the child and instead blocks forever: Does it perform a wildcarded wait(), or does it explicitly specify the PID of the child? By design, the former will not return children created by pdfork(). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deadlock involving truss -f, pdfork() and wait4()
This gets me a little further but now the wait4 call by the parent
never reaps the child and instead blocks forever:
# truss -f ./pdfork -p
706: mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34361
970688 (0x800221000)
706: issetugid() = 0 (0x0)
706: open("/etc/libmap.conf",O_RDONLY|O_CLOEXEC,010440020) = 3 (0x3)
706: fstat(3,{ mode=-rw-r--r-- ,inode=241058,size=47,blksize=32768 }) = 0 (0x0
)
706: read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
706: close(3) = 0 (0x0)
706: open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,
0165) ERR#2 'No such file or directory'
706: open("/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,010002355) = 3 (0x3)
706: read(3,"Ehnt\^A\0\0\0\M^@\0\0\0A\0\0\0\0"...,128) = 128 (0x80)
706: fstat(3,{ mode=-r--r--r-- ,inode=72,size=193,blksize=4096 }) = 0 (0x0)
706: pread(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,65,0x80) = 65 (0x41)
706: close(3) = 0 (0x0)
706: open("/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,057400) = 3 (0x3)
706: fstat(3,{ mode=-r--r--r-- ,inode=402754,size=1915744,blksize=32768 }) = 0
(0x0)
706: mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 3436210176
0 (0x800241000)
706: mmap(0x0,4169728,PROT_NONE,MAP_GUARD,-1,0x0) = 34362105856 (0x800242000)
706: mmap(0x800242000,524288,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PR
EFAULT_READ,3,0x0) = 34362105856 (0x800242000)
706: mmap(0x8002c2000,1327104,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NO
CORE|MAP_PREFAULT_READ,3,0x8) = 34362630144 (0x8002c2000)
706: mmap(0x800406000,61440,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PRE
FAULT_READ,3,0x1c4000) = 34363957248 (0x800406000)
706: mmap(0x800415000,2256896,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_A
NON,-1,0x0) = 34364018688 (0x800415000)
706: munmap(0x800241000,4096) = 0 (0x0)
706: close(3) = 0 (0x0)
706: mprotect(0x80040c000,36864,PROT_READ) = 0 (0x0)
706: sysarch(AMD64_SET_FSBASE,0x7fffe110) = 0 (0x0)
706: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIG
TERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFS
Z|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
706: mprotect(0x80040c000,36864,PROT_READ|PROT_WRITE) = 0 (0x0)
706: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
706: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIG
TERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFS
Z|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
706: mprotect(0x80040c000,36864,PROT_READ) = 0 (0x0)
706: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
706: readlink("/etc/malloc.conf",0x7fffd830,1024) ERR#2 'No such file or d
irectory'
706: issetugid() = 0 (0x0)
706: __sysctl(0x7fffd7e0,0x2,0x7fffd7dc,0x7fffd7d0,0x0,0x0) = 0 (0
x0)
706: mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(21
),-1,0x0) = 34368126976 (0x80080)
706: cap_getmode({ 0 })= 0 (0x0)
706: open("/dev/hpet0",O_RDONLY,00)= 3 (0x3)
706: mmap(0x0,4096,PROT_READ,MAP_SHARED,3,0x0) = 34362101760 (0x800241000)
706: close(3) = 0 (0x0)
706: mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),
-1,0x0) = 34366275584 (0x80063c000)
706: mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(21
),-1,0x0) = 34370224128 (0x800a0)
706: mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-
1,0x0) = 34366308352 (0x800644000)
706: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIG
TERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFS
Z|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
706: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
706: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIG
TERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFS
Z|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
706: mprotect(0x203000,4096,PROT_READ) = 0 (0x0)
706: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
706: pdfork(0x7fffeba8,0x0)= 708 (0x2c4)
708:
708: nanosleep({ 1.0 })= 0 (0x0)
708: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIG
TERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFS
Z|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
708: sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0)
708: sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIG
Re: Deadlock involving truss -f, pdfork() and wait4()
Hello Ryan, Can you verify is this patch fix your issue: https://reviews.freebsd.org/D20362 Thanks, Mariusz On Thu, 12 Sep 2019 at 21:37, Ryan Stone wrote: > > I've hit an issue with a simple use of pdfork(). I have a process > that calls pdfork() and the parent immediately does a wait4() on the > child pid. This works fine under normal conditions, but if the parent > is run under truss -f, the three processes deadlock. If I switch out > pdfork() for fork(), the deadlock does not occur. > > This C file demonstrates the issue: > > https://people.freebsd.org/~rstone/pdfork.c > > If I run "truss -f ./pdfork", which uses fork(), it completes within a > second. If I run "truss -f ./pdfork -p", which uses pdfork(), the > processes deadlock. If I run "./pdfork -p" without truss, it > completes normally. > > procstat reports the following kernel stacks: > > 27572 102043 truss - mi_switch+0xe2 > sleepq_catch_signals+0x425 sleepq_wait_sig+0xf _sleep+0x1bf > kern_wait6+0x695 sys_wait6+0x9f amd64_syscall+0x36e > fast_syscall_common+0x101 > 27573 102469 pdfork - mi_switch+0xe2 > sleepq_catch_signals+0x425 sleepq_wait_sig+0xf _sleep+0x1bf > kern_wait6+0x695 sys_wait4+0x78 amd64_syscall+0x36e > fast_syscall_common+0x101 > 27574 102053 pdfork - mi_switch+0xe2 > thread_suspend_switch+0xd4 ptracestop+0x13b fork_return+0x14e > fork_exit+0x83 fork_trampoline+0xe > > As near as I can tell, truss is blocked waiting for ptrace events, the > parent process is blocked in wait4, and the child process is perhaps > waiting for its parent to exit the kernel so it can send the ptrace > event? > > I really don't see anything obvious in the pdfork() code path that > would cause this to happen when fork() doesn't have the problem. It > may be that pdfork() just changes the timing enough to expose a latent > bug. > > I'm seeing this on a recentish current (r351363). > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Deadlock involving truss -f, pdfork() and wait4()
I've hit an issue with a simple use of pdfork(). I have a process that calls pdfork() and the parent immediately does a wait4() on the child pid. This works fine under normal conditions, but if the parent is run under truss -f, the three processes deadlock. If I switch out pdfork() for fork(), the deadlock does not occur. This C file demonstrates the issue: https://people.freebsd.org/~rstone/pdfork.c If I run "truss -f ./pdfork", which uses fork(), it completes within a second. If I run "truss -f ./pdfork -p", which uses pdfork(), the processes deadlock. If I run "./pdfork -p" without truss, it completes normally. procstat reports the following kernel stacks: 27572 102043 truss - mi_switch+0xe2 sleepq_catch_signals+0x425 sleepq_wait_sig+0xf _sleep+0x1bf kern_wait6+0x695 sys_wait6+0x9f amd64_syscall+0x36e fast_syscall_common+0x101 27573 102469 pdfork - mi_switch+0xe2 sleepq_catch_signals+0x425 sleepq_wait_sig+0xf _sleep+0x1bf kern_wait6+0x695 sys_wait4+0x78 amd64_syscall+0x36e fast_syscall_common+0x101 27574 102053 pdfork - mi_switch+0xe2 thread_suspend_switch+0xd4 ptracestop+0x13b fork_return+0x14e fork_exit+0x83 fork_trampoline+0xe As near as I can tell, truss is blocked waiting for ptrace events, the parent process is blocked in wait4, and the child process is perhaps waiting for its parent to exit the kernel so it can send the ptrace event? I really don't see anything obvious in the pdfork() code path that would cause this to happen when fork() doesn't have the problem. It may be that pdfork() just changes the timing enough to expose a latent bug. I'm seeing this on a recentish current (r351363). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
[I re-established the crotchet-build based failure context finally.
Unfortunately truss just dies in a new place.]
On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>> [The following has been reported in:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>>
>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
>> to track things down I ran into truss getting a SIGSEGV when it tries to
>> handle the situation. . .
>>
>> In truss's enter_syscall there is (from a live gdb on truss, after the
>> segmentation fault):
>>
>> 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
>> t->cs.number);
>> 381 if (t->cs.name == NULL)
>> (gdb)
>> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
>> 383 t->proc->abi->type, t->cs.number);
>> 384
>> 385 sc = get_syscall(t->cs.name, narg);
>> 386 t->cs.nargs = sc->nargs;
>> 387 assert(sc->nargs <= nitems(t->cs.s_args));
>> 388
>> 389 t->cs.sc = sc;
>>
>> (gdb) print *t
>> $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060,
>> tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number =
>> 580828064, args = 0x2061b0c0, nargs = 0,
>>s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec =
>> 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}}
>>
>> (gdb) print sc
>> $3 = (struct syscall *) 0x0
>>
>> So line 386 listed above gets a segmentation fault for sc->nargs when
>> t->cs.name is a NULL pointer: sc ends up NULL.
>>
>> Looking at the two things that the fprintf on lines 382 and 383 would report:
>>
>> (gdb) print t->proc->abi->type
>> $4 = 0x10166 "FreeBSD ELF32"
>>
>> (gdb) print t->cs.number
>> $5 = 580828064
>>
>> (gdb) print narg
>> $6 = 0
>>
>> (that last is for context for the get_syscall arguments).
>>
>> FYI: 580828064 = 0x229EBBA0
>
> I have a patchset I have tested some in a git branch that I believe fixes
> handling of
> unknown system calls. Please try this:
>
> https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown
>
> (Add .diff to get a diff you can apply with patch)
>
>
> --
> John Baldwin
[Watch out for inlining consequences in how gdb presents things. Also I
extracted from my explorations and changed the presentation order to eliminate
junk.]
Summary: st->syscalls ends up NULL from reallocf refusing a huge allocation
because t->cs.number==580828064, which would make for a huge offset in
st->syscalls[number] . new_count * sizeof(st->syscalls[0]) would be rather
large (new_count == number+1) .
reallocf's result needs to be tested and/or reasonable-value-checks on
t->cs.number (a.k.a. number) need to be made and unreasonable value handled
some other way.
The supporting details:
root@bananapi-m3:/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/armv6-portbld-freebsd11.0/libgcc
# gdb truss
GNU gdb 6.1.1 [FreeBSD]
. . .
(gdb) run -faeH -o truss.log
/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc
-B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/
-B/usr/local/armv6-portbld-freebsd11.0/bin/
-B/usr/local/armv6-portbld-freebsd11.0/lib/ -isystem
/usr/local/armv6-portbld-freebsd11.0/include -isystem
/usr/local/armv6-portbld-freebsd11.0/sys-include -O2 -pipe -mcpu=cortex-a7
-DLIBICONV_PLUG -g -fno-strict-aliasing -O2 -O2 -pipe -mcpu=cortex-a7
-DLIBICONV_PLUG -g -fno-strict-aliasing -DIN_GCC -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread
-fno-inline -fomit-frame-pointer -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -fPIC -pthread -fno-inline -fomit-frame-pointer -I. -I.
-I../.././gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc
-I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/.
-I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.
0/libgcc/../gcc
-I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/../include
-DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libgcc/libgcc2.c
-fvisibility=hidden -DHIDE_EXPORTS
Starting program: /usr/bin/truss -faeH -o truss.log .
. . .
Program received signal SIGSEGV, Segmentation fault.
0x20241ebc in memset () from /lib/libc.so.7
Current language: auto; currently minimal
(gdb) bt
#0 0x202
Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
On 2016-Oct-28, at 4:02 PM, Mark Millard wrote:
> On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
>
>> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>>> [The following has been reported in:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>>>
>>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
>>> to track things down I ran into truss getting a SIGSEGV when it tries to
>>> handle the situation. . .
>>>
>>> In truss's enter_syscall there is (from a live gdb on truss, after the
>>> segmentation fault):
>>>
>>> 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
>>> t->cs.number);
>>> 381 if (t->cs.name == NULL)
>>> (gdb)
>>> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
>>> 383 t->proc->abi->type, t->cs.number);
>>> 384
>>> 385 sc = get_syscall(t->cs.name, narg);
>>> 386 t->cs.nargs = sc->nargs;
>>> 387 assert(sc->nargs <= nitems(t->cs.s_args));
>>> 388
>>> 389 t->cs.sc = sc;
>>>
>>> (gdb) print *t
>>> $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060,
>>> tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number =
>>> 580828064, args = 0x2061b0c0, nargs = 0,
>>> s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec =
>>> 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}}
>>>
>>> (gdb) print sc
>>> $3 = (struct syscall *) 0x0
>>>
>>> So line 386 listed above gets a segmentation fault for sc->nargs when
>>> t->cs.name is a NULL pointer: sc ends up NULL.
>>>
>>> Looking at the two things that the fprintf on lines 382 and 383 would
>>> report:
>>>
>>> (gdb) print t->proc->abi->type
>>> $4 = 0x10166 "FreeBSD ELF32"
>>>
>>> (gdb) print t->cs.number
>>> $5 = 580828064
>>>
>>> (gdb) print narg
>>> $6 = 0
>>>
>>> (that last is for context for the get_syscall arguments).
>>>
>>> FYI: 580828064 = 0x229EBBA0
>>
>> I have a patchset I have tested some in a git branch that I believe fixes
>> handling of
>> unknown system calls. Please try this:
>>
>> https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown
>>
>> (Add .diff to get a diff you can apply with patch)
>>
>> --
>> John Baldwin
>
> Sorry it took so long to try the build. . .
>
> I got a compile failure for use of bool in my stable/11 context for the
> BPI-M3 build that the truss problem was discovered with (quoting the build
> log below):
>
>> --- main.o ---
>> cc -target armv6-gnueabihf-freebsd11.0
>> --sysroot=/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp
>> -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe
>> -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD
>> -MF.depend.main.o -MTma
>> in.o -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W
>> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
>> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
>> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
>> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
>> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
>> -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
>> /usr/src/usr.bin/truss/main.c -o main.o
>> In file included from /usr/src/usr.bin/truss/main.c:53:
>> /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name 'bool'
>>bool unknown; /* Uknown system call */
>>^
>> 1 error generated.
>> *** [main.o] Error code 1
>>
>> make[4]: stopped in /usr/src/usr.bin/truss
>> 1 error
>
>
> In C99 bool is a macro from and _Bool is the C99 type itself. So
> apparently (or an equivalent) was not directly or indirectly
> included. (The macros true and false and __bool_true_false_are_defined are
> also from .)
>
> Which way do you want the C99 typing to be handled for this: native C99 with
> no required? Use ?
>
>
> Side note:
>
> I'll see about getting my normal stable/11 build environment going for the
> BPI-M3 instead of using the crochet from my first-time build f
Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
On 2016-Oct-28, at 7:29 AM, John Baldwin wrote:
> On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
>> [The following has been reported in:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>>
>> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
>> to track things down I ran into truss getting a SIGSEGV when it tries to
>> handle the situation. . .
>>
>> In truss's enter_syscall there is (from a live gdb on truss, after the
>> segmentation fault):
>>
>> 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
>> t->cs.number);
>> 381 if (t->cs.name == NULL)
>> (gdb)
>> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
>> 383 t->proc->abi->type, t->cs.number);
>> 384
>> 385 sc = get_syscall(t->cs.name, narg);
>> 386 t->cs.nargs = sc->nargs;
>> 387 assert(sc->nargs <= nitems(t->cs.s_args));
>> 388
>> 389 t->cs.sc = sc;
>>
>> (gdb) print *t
>> $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060,
>> tid = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number =
>> 580828064, args = 0x2061b0c0, nargs = 0,
>>s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec =
>> 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}}
>>
>> (gdb) print sc
>> $3 = (struct syscall *) 0x0
>>
>> So line 386 listed above gets a segmentation fault for sc->nargs when
>> t->cs.name is a NULL pointer: sc ends up NULL.
>>
>> Looking at the two things that the fprintf on lines 382 and 383 would report:
>>
>> (gdb) print t->proc->abi->type
>> $4 = 0x10166 "FreeBSD ELF32"
>>
>> (gdb) print t->cs.number
>> $5 = 580828064
>>
>> (gdb) print narg
>> $6 = 0
>>
>> (that last is for context for the get_syscall arguments).
>>
>> FYI: 580828064 = 0x229EBBA0
>
> I have a patchset I have tested some in a git branch that I believe fixes
> handling of
> unknown system calls. Please try this:
>
> https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown
>
> (Add .diff to get a diff you can apply with patch)
>
> --
> John Baldwin
Sorry it took so long to try the build. . .
I got a compile failure for use of bool in my stable/11 context for the BPI-M3
build that the truss problem was discovered with (quoting the build log below):
> --- main.o ---
> cc -target armv6-gnueabihf-freebsd11.0
> --sysroot=/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp
> -B/usr/local/src/crochet/work/obj/arm.armv6/usr/src/tmp/usr/bin -O -pipe
> -I/usr/src/usr.bin/truss -I. -I/usr/src/usr.bin/truss/../../sys -g -MD
> -MF.depend.main.o -MTma
> in.o -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W
> -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
> -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs
> -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
> -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c
> /usr/src/usr.bin/truss/main.c -o main.o
> In file included from /usr/src/usr.bin/truss/main.c:53:
> /usr/src/usr.bin/truss/syscall.h:75:2: error: unknown type name 'bool'
> bool unknown; /* Uknown system call */
> ^
> 1 error generated.
> *** [main.o] Error code 1
>
> make[4]: stopped in /usr/src/usr.bin/truss
> 1 error
In C99 bool is a macro from and _Bool is the C99 type itself. So
apparently (or an equivalent) was not directly or indirectly
included. (The macros true and false and __bool_true_false_are_defined are also
from .)
Which way do you want the C99 typing to be handled for this: native C99 with no
required? Use ?
Side note:
I'll see about getting my normal stable/11 build environment going for the
BPI-M3 instead of using the crochet from my first-time build for the target.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
On Tuesday, October 25, 2016 11:40:38 AM Mark Millard wrote:
> [The following has been reported in:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
>
> In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying
> to track things down I ran into truss getting a SIGSEGV when it tries to
> handle the situation. . .
>
> In truss's enter_syscall there is (from a live gdb on truss, after the
> segmentation fault):
>
> 380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
> t->cs.number);
> 381 if (t->cs.name == NULL)
> (gdb)
> 382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
> 383 t->proc->abi->type, t->cs.number);
> 384
> 385 sc = get_syscall(t->cs.name, narg);
> 386 t->cs.nargs = sc->nargs;
> 387 assert(sc->nargs <= nitems(t->cs.s_args));
> 388
> 389 t->cs.sc = sc;
>
> (gdb) print *t
> $2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid
> = 100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064,
> args = 0x2061b0c0, nargs = 0,
> s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec =
> 492342263}, after = {tv_sec = 1477418265, tv_nsec = 492496630}}
>
> (gdb) print sc
> $3 = (struct syscall *) 0x0
>
> So line 386 listed above gets a segmentation fault for sc->nargs when
> t->cs.name is a NULL pointer: sc ends up NULL.
>
> Looking at the two things that the fprintf on lines 382 and 383 would report:
>
> (gdb) print t->proc->abi->type
> $4 = 0x10166 "FreeBSD ELF32"
>
> (gdb) print t->cs.number
> $5 = 580828064
>
> (gdb) print narg
> $6 = 0
>
> (that last is for context for the get_syscall arguments).
>
> FYI: 580828064 = 0x229EBBA0
I have a patchset I have tested some in a git branch that I believe fixes
handling of
unknown system calls. Please try this:
https://github.com/freebsd/freebsd/compare/master...bsdjhb:truss_unknown
(Add .diff to get a diff you can apply with patch)
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
[The following has been reported in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying to
track things down I ran into truss getting a SIGSEGV when it tries to handle
the situation. . .
In truss's enter_syscall there is (from a live gdb on truss, after the
segmentation fault):
380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
t->cs.number);
381 if (t->cs.name == NULL)
(gdb)
382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
383 t->proc->abi->type, t->cs.number);
384
385 sc = get_syscall(t->cs.name, narg);
386 t->cs.nargs = sc->nargs;
387 assert(sc->nargs <= nitems(t->cs.s_args));
388
389 t->cs.sc = sc;
(gdb) print *t
$2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid =
100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064, args =
0x2061b0c0, nargs = 0,
s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec = 492342263},
after = {tv_sec = 1477418265, tv_nsec = 492496630}}
(gdb) print sc
$3 = (struct syscall *) 0x0
So line 386 listed above gets a segmentation fault for sc->nargs when
t->cs.name is a NULL pointer: sc ends up NULL.
Looking at the two things that the fprintf on lines 382 and 383 would report:
(gdb) print t->proc->abi->type
$4 = 0x10166 "FreeBSD ELF32"
(gdb) print t->cs.number
$5 = 580828064
(gdb) print narg
$6 = 0
(that last is for context for the get_syscall arguments).
FYI: 580828064 = 0x229EBBA0
Context:
root@bananapi-m3:/usr/ports # uname -apKU
FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24
00:41:16 PDT 2016
markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
arm armv6 1100505 1100505
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
stable/11 -r307797 on BPi-M3 (cortex-a7): truss gets segmentation fault for handling unknown system call
[The following has been reported in:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213778 .]
In trying to build lang/gcc6 xgcc's cc1 got some SIGSYS examples. In trying to
track things down I ran into truss getting a SIGSEGV when it tries to handle
the situation. . .
In truss's enter_syscall there is (from a live gdb on truss, after the
segmentation fault):
380 t->cs.name = sysdecode_syscallname(t->proc->abi->abi,
t->cs.number);
381 if (t->cs.name == NULL)
(gdb)
382 fprintf(info->outfile, "-- UNKNOWN %s SYSCALL %d --\n",
383 t->proc->abi->type, t->cs.number);
384
385 sc = get_syscall(t->cs.name, narg);
386 t->cs.nargs = sc->nargs;
387 assert(sc->nargs <= nitems(t->cs.s_args));
388
389 t->cs.sc = sc;
(gdb) print *t
$2 = {entries = {le_next = 0x0, le_prev = 0x20617070}, proc = 0x20617060, tid =
100150, in_syscall = 1, cs = {sc = 0x0, name = 0x0, number = 580828064, args =
0x2061b0c0, nargs = 0,
s_args = 0x2061b0ec}, before = {tv_sec = 1477418265, tv_nsec = 492342263},
after = {tv_sec = 1477418265, tv_nsec = 492496630}}
(gdb) print sc
$3 = (struct syscall *) 0x0
So line 386 listed above gets a segmentation fault for sc->nargs when
t->cs.name is a NULL pointer: sc ends up NULL.
Looking at the two things that the fprintf on lines 382 and 383 would report:
(gdb) print t->proc->abi->type
$4 = 0x10166 "FreeBSD ELF32"
(gdb) print t->cs.number
$5 = 580828064
(gdb) print narg
$6 = 0
(that last is for context for the get_syscall arguments).
FYI: 580828064 = 0x229EBBA0
Context:
root@bananapi-m3:/usr/ports # uname -apKU
FreeBSD bananapi-m3 11.0-STABLE FreeBSD 11.0-STABLE #0 r307797M: Mon Oct 24
00:41:16 PDT 2016
markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm.armv6/usr/src/sys/ALLWINNER
arm armv6 1100505 1100505
===
Mark Millard
markmi at dsl-only.net
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Please check in this simple patch: misc/180976 Fixed vfork/rfork arguments in truss(1)
http://www.freebsd.org/cgi/query-pr.cgi?pr=180976 Thank you, Yuri ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Please check in this simple patch: misc/180976 Fixed vfork/rfork arguments in truss(1)
On Wed, Jul 31, 2013 at 11:24:31AM -0700, Yuri wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=180976 I've committed a modified version of the patch as r253850. Thanks! -Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote: KB Could you, please, test the change below ? For me, I still can truss(1) KB or debug with gdb after the change applied. Does truss work for you KB with only this change, without resetting SIGTRAP handler in truss process ? KB KB commit 2ae586c039a55399edc3b34cd40410e0d690a16c KB Author: Konstantin Belousov kos...@pooma.home KB Date: Tue Sep 20 00:25:07 2011 +0300 KB KB Do not deliver SIGTRAP on exec as the normal signal, use ptracestop() KB on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal() KB do not want to deliver, and debugger never get a notification of exec. I can confirm - with this patch unmodified truss works when SIGTRAP is ignored. -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Tue, 20 Sep 2011 00:27:22 +0300, Kostik Belousov wrote:
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
KB This is quite a hack. The proper fix should go in kernel, otherwise
KB we cannot debug programs that decided to ignore SIGTRAP. The reason
It seems to be, that in gdb used similar hack:
citrin:~ procstat -i 2433 | fgrep TRAP
2433 dd TRAP -I-
:~ gdb /bin/dd 2433
...
(gdb) next
Single stepping until exit from function write,
which has no line number information.
dd_out (force=1) at dd.c:458
458 if (nw = 0) {
(gdb)
...
:~ procstat -i 2433 | fgrep TRAP
2433 dd TRAP ---
KB Could you, please, test the change below ? For me, I still can truss(1)
KB or debug with gdb after the change applied. Does truss work for you
KB with only this change, without resetting SIGTRAP handler in truss process ?
I'll test this patch.
--
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG Could you please run ktrace with -i option? The behavior is like if MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG does not check this. ktrace -i for truss sleep 5 http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Mon, 19 Sep 2011 12:13:56 + (UTC) Anton Yuzhaninov wrote to Mikolaj Golub: AY On Sun, 18 Sep 2011 16:46:01 +0300, Mikolaj Golub wrote: MG Could you please run ktrace with -i option? The behavior is like if MG ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss MG does not check this. AY ktrace -i for truss sleep 5 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after execve() and wait4() in parent (which was actually waiting for this stop) returned only after the child exit. No I idea why so far :-). -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote: AY ktrace -i for truss sleep 5 AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt MG MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop after MG execve() and wait4() in parent (which was actually waiting for this stop) MG returned only after the child exit. No I idea why so far :-). MG As I understand SIGTRAP used to stop child process after execve(), but this signal ignored: citrin:~ sleep 300 citrin:~ procstat -i 1991 | fgrep TRAP 1991 sleepTRAP -I- Under FreeBSD 8, where ptrace works for me, this signal is not ignored: x:~ sleep 300 x:~ procstat -i 78716 | fgrep TRAP 78716 sleepTRAP --- -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop
after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG
AY
AY As I understand SIGTRAP used to stop child process after execve(), but
AY this signal ignored:
AY
AY citrin:~ sleep 300
AY citrin:~ procstat -i 1991 | fgrep TRAP
AY 1991 sleepTRAP -I-
AY
AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
AY x:~ sleep 300
AY x:~ procstat -i 78716 | fgrep TRAP
AY 78716 sleepTRAP ---
SIGTRAP is ignored by X window manager used by me, and this is inherited across
forks/execs up to the truss.
IMHO truss should restore default signal handler for SIGTRAP.
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
--
Anton Yuzhaninov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Mon, Sep 19, 2011 at 04:03:42PM +, Anton Yuzhaninov wrote:
On Mon, 19 Sep 2011 15:00:31 + (UTC), Anton Yuzhaninov wrote:
AY On Mon, 19 Sep 2011 15:58:02 +0300, Mikolaj Golub wrote:
AY ktrace -i for truss sleep 5
AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace2.txt
MG
MG Although ptrace(PT_TRACE_ME,0,0,0) returned 0 the process did not stop
after
MG execve() and wait4() in parent (which was actually waiting for this stop)
MG returned only after the child exit. No I idea why so far :-).
MG
AY
AY As I understand SIGTRAP used to stop child process after execve(), but
AY this signal ignored:
AY
AY citrin:~ sleep 300
AY citrin:~ procstat -i 1991 | fgrep TRAP
AY 1991 sleepTRAP -I-
AY
AY Under FreeBSD 8, where ptrace works for me, this signal is not ignored:
AY x:~ sleep 300
AY x:~ procstat -i 78716 | fgrep TRAP
AY 78716 sleepTRAP ---
SIGTRAP is ignored by X window manager used by me, and this is inherited
across
forks/execs up to the truss.
IMHO truss should restore default signal handler for SIGTRAP.
With this patch truss works for me:
--- usr.bin/truss/main.c(revision 225504)
+++ usr.bin/truss/main.c(working copy)
@@ -255,6 +255,11 @@ main(int ac, char **av)
if (trussinfo-pid == 0) { /* Start a command ourselves */
command = av;
+ /*
+* SIGTRUP used to stop traced process after execve
+* un-ignore this signal (it can be ignored by parents)
+*/
+ signal(SIGTRAP, SIG_DFL);
trussinfo-pid = setup_and_wait(command);
signal(SIGINT, SIG_IGN);
signal(SIGTERM, SIG_IGN);
This is quite a hack. The proper fix should go in kernel, otherwise
we cannot debug programs that decided to ignore SIGTRAP. The reason
there is that tdsendsignal() does nothing for attempt to deliver ignored
signal, and kern_execve() simply tries to send a signal to self.
BTW, it seems we might also have similar issues for threads that masks
SIGTRAP, now because issignal() does nothing in that case too. But lets
handle it by small steps.
Could you, please, test the change below ? For me, I still can truss(1)
or debug with gdb after the change applied. Does truss work for you
with only this change, without resetting SIGTRAP handler in truss process ?
commit 2ae586c039a55399edc3b34cd40410e0d690a16c
Author: Konstantin Belousov kos...@pooma.home
Date: Tue Sep 20 00:25:07 2011 +0300
Do not deliver SIGTRAP on exec as the normal signal, use ptracestop()
on syscall exit path. Otherwise, if SIGTRAP is ignored, that tdsendsignal()
do not want to deliver, and debugger never get a notification of exec.
Found by: Anton Yuzhaninov cit...@citrin.ru
diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c
index fe01142..4545848 100644
--- a/sys/kern/kern_exec.c
+++ b/sys/kern/kern_exec.c
@@ -777,16 +777,6 @@ interpret:
KNOTE_LOCKED(p-p_klist, NOTE_EXEC);
p-p_flag = ~P_INEXEC;
- /*
-* If tracing the process, trap to the debugger so that
-* breakpoints can be set before the program executes. We
-* have to use tdsignal() to deliver the signal to the current
-* thread since any other threads in this process will exit if
-* execve() succeeds.
-*/
- if (p-p_flag P_TRACED)
- tdsignal(td, SIGTRAP);
-
/* clear fork but no exec flag, as we _are_ execing */
p-p_acflag = ~AFORK;
diff --git a/sys/kern/subr_syscall.c b/sys/kern/subr_syscall.c
index cb0d929..bba4479 100644
--- a/sys/kern/subr_syscall.c
+++ b/sys/kern/subr_syscall.c
@@ -204,9 +204,17 @@ syscallret(struct thread *td, int error, struct
syscall_args *sa __unused)
* is not the case, this code will need to be revisited.
*/
STOPEVENT(p, S_SCX, sa-code);
- PTRACESTOP_SC(p, td, S_PT_SCX);
if (traced || (td-td_dbgflags (TDB_EXEC | TDB_FORK)) != 0) {
PROC_LOCK(p);
+ /*
+* If tracing the execed process, trap to the debugger
+* so that breakpoints can be set before the program
+* executes. If debugger requested tracing of syscall
+* returns, do it now too.
+*/
+ if (traced ((td-td_dbgflags TDB_EXEC) != 0 ||
+ (p-p_stops S_PT_SCX) != 0))
+ ptracestop(td, SIGTRAP);
td-td_dbgflags = ~(TDB_SCX | TDB_EXEC | TDB_FORK);
PROC_UNLOCK(p);
}
pgpF2yup3qKFJ.pgp
Description: PGP signature
Re: truss
On Wed, 14 Sep 2011 06:17:45 + (UTC) Anton Yuzhaninov wrote to Xin LI: AY On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote: XL -BEGIN PGP SIGNED MESSAGE- XL Hash: SHA256 XL XL On 08/31/11 07:35, Anton Yuzhaninov wrote: It seems to be truss(1) is broken on current :~ truss /bin/echo x x truss: can not get etype: No such process FreeBSD 9.0-BETA1 #0 r224884M i386 from ktrace of turss 3162 trussCALL __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1 errno 3 No such process XL XL Can't seem to be reproducable here, did I missed anything? (note that XL you may need a full world/kernel build). XL AY Problem still here after svn up and rebuild world/kernel AY :~ ktrace -t+ truss /usr/bin/true AY truss: can not get etype: No such process Could you please run ktrace with -i option? The behavior is like if ptrace(PT_TRACE_ME) failed in the child by some reason. Unfortunately, truss does not check this. AY Full ktrace: AY http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt AY FreeBSD 9.0-BETA2 #1 r225504M AY i386 AY Kernel config is not GENERIC - main difference - DTrace added: AY http://dl.dropbox.com/u/8798217/tmp/kernconf.txt AY -- AY Anton Yuzhaninov AY ___ AY freebsd-current@freebsd.org mailing list AY http://lists.freebsd.org/mailman/listinfo/freebsd-current AY To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Fri, 09 Sep 2011 15:56:41 -0700, Xin LI wrote: XL -BEGIN PGP SIGNED MESSAGE- XL Hash: SHA256 XL XL On 08/31/11 07:35, Anton Yuzhaninov wrote: It seems to be truss(1) is broken on current :~ truss /bin/echo x x truss: can not get etype: No such process FreeBSD 9.0-BETA1 #0 r224884M i386 from ktrace of turss 3162 trussCALL __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1 errno 3 No such process XL XL Can't seem to be reproducable here, did I missed anything? (note that XL you may need a full world/kernel build). XL Problem still here after svn up and rebuild world/kernel :~ ktrace -t+ truss /usr/bin/true truss: can not get etype: No such process Full ktrace: http://dl.dropbox.com/u/8798217/tmp/truss_ktrace.txt FreeBSD 9.0-BETA2 #1 r225504M i386 Kernel config is not GENERIC - main difference - DTrace added: http://dl.dropbox.com/u/8798217/tmp/kernconf.txt -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0 r224884M i386
from ktrace of turss
3162 trussCALL
__sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1
errno 3 No such process
Can't seem to be reproducable here, did I missed anything? (note that
you may need a full world/kernel build).
truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cd9e,0x800848810,0x8008487e0,0xb277,0x0)
= 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=1668471,size=712,blksize=4096 }) = 0
(0x0)
read(3,libpthread.so.2\tlibthr.so.2\nli...,4096) = 712 (0x2c8)
read(3,0x80063b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open(/var/run/ld-elf.so.hints,O_RDONLY,0160) = 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0\M-\\^A\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET) = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,476) = 476 (0x1dc)
close(3) = 0 (0x0)
mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366287872 (0x80063f000)
access(/lib/libc.so.7,0) = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040737600)= 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=2664100,size=1310888,blksize=131072
}) = 0 (0x0)
pread(0x3,0x80083af60,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b69000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x12)
= 34371702784 (0x800b69000)
mprotect(0x800b74000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffcfc0,0x80063d6c8,0x0,0xffad0580,0x800865370)
= 0 (0x0)
munmap(0x800642000,24576)= 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366300160 (0x800642000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024) = 2 (0x2)
issetugid(0x800945ba1,0x7fffd220,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371858432 (0x800b8f000)
mmap(0x800f8f000,462848,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376052736 (0x800f8f000)
munmap(0x800b8f000,462848) = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdad0,0x600d10,0x7fffcd60) = 2
(0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0
Cheers,
- --
Xin LI delp...@delphij.nethttps://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (FreeBSD)
iQEcBAEBCAAGBQJOapmpAAoJEATO+BI/yjfBgY8IANXc7pbkZHEa0I6N6eZPM2Mk
IuiK8Ei6p9jGI72DYS9VV+OPGerarkBw0CvYyKr9lNKV5rnB4fg04MiUflNGpSqN
2zQmnGewzr1+a/bC6txaLZr5ittUnpzXp85CB1sEZ5tXn34pMsW9MYmSSmL4SwMG
L8e4+U+QjdOMvH2BHEil3WdkqPDQKnz/mk+2wJX7gw3/ssf7QozyQ4vpE4Ed2jC8
dnpCmE++BtPRK+PzdbhcoT3/KpSCuWIpaAAcxh8RE994K3nwc27crPOKLA/7lQ2x
u4VIIcX27Jb1pKwugmcriTCIhCb0D7ge44fDTHAhY97W7p36JD3DbSUm5zs8I8o=
=v+hw
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Sep 9, 2011, at 3:56 PM, Xin LI delp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/31/11 07:35, Anton Yuzhaninov wrote:
It seems to be truss(1) is broken on current
:~ truss /bin/echo x x truss: can not get etype: No such process
FreeBSD 9.0-BETA1 #0 r224884M i386
from ktrace of turss
3162 trussCALL
__sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 truss
SCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1
errno 3 No such process
Can't seem to be reproducable here, did I missed anything? (note that
you may need a full world/kernel build).
truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cd9e,0x800848810,0x8008487e0,0xb277,0x0)
= 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=1668471,size=712,blksize=4096 }) = 0
(0x0)
read(3,libpthread.so.2\tlibthr.so.2\nli...,4096) = 712 (0x2c8)
read(3,0x80063b000,4096) = 0 (0x0)
close(3) = 0 (0x0)
open(/var/run/ld-elf.so.hints,O_RDONLY,0160) = 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0\M-\\^A\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET) = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,476) = 476 (0x1dc)
close(3) = 0 (0x0)
mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366287872 (0x80063f000)
access(/lib/libc.so.7,0) = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040737600) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=2664100,size=1310888,blksize=131072
}) = 0 (0x0)
pread(0x3,0x80083af60,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3432448,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1179648,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b69000,45056,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x12)
= 34371702784 (0x800b69000)
mprotect(0x800b74000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffcfc0,0x80063d6c8,0x0,0xffad0580,0x800865370)
= 0 (0x0)
munmap(0x800642000,24576) = 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366300160 (0x800642000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024) = 2 (0x2)
issetugid(0x800945ba1,0x7fffd220,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371858432 (0x800b8f000)
mmap(0x800f8f000,462848,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376052736 (0x800f8f000)
munmap(0x800b8f000,462848) = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdad0,0x600d10,0x7fffcd60) = 2
(0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0
Truss isn't broken for me this way either. It just doesn't detach from
processes properly if I do ctrl c, which seems like a ptrace bug to me.
It would help to know how truss was compiled (file would be helpful), and what
environment it's being executed in (32bit on 64bit, a chroot/jail, etc).
Thanks,
-Garrett___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
truss
It seems to be truss(1) is broken on current :~ truss /bin/echo x x truss: can not get etype: No such process FreeBSD 9.0-BETA1 #0 r224884M i386 from ktrace of turss 3162 trussCALL __sysctl(0xbfbfea00,0x4,0xbfbfe9e0,0xbfbfea10,0,0) 3162 trussSCTL kern.proc.sv_name.3163 3162 trussRET __sysctl -1 errno 3 No such process -- Anton Yuzhaninov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss
On Wed, Aug 31, 2011 at 4:35 PM, Anton Yuzhaninov cit...@citrin.ru wrote:
It seems to be truss(1) is broken on current
I just tried with a newly build CURRENT, and no problem here.
[solskogen@friend ~]$ truss /bin/echo x
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366255104 (0x800637000)
issetugid(0x800638015,0x80062cb5e,0x800848250,0x800848220,0xb4b7,0x0) = 0 (0x0)
open(/etc/libmap.conf,O_RDONLY,0666) ERR#2 'No such file or
directory'
open(/var/run/ld-elf.so.hints,O_RDONLY,057)= 3 (0x3)
read(3,Ehnt\^A\0\0\0\M^@\0\0\0-\0\0\0\0...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET) = 128 (0x80)
read(3,/lib:/usr/lib:/usr/lib/compat:/u...,45) = 45 (0x2d)
close(3) = 0 (0x0)
access(/lib/libc.so.7,0) = 0 (0x0)
open(/lib/libc.so.7,O_RDONLY,040734700)= 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=4830,size=1268472,blksize=131072 }) = 0 (0x0)
pread(0x3,0x80083a9a0,0x1000,0x0,0x101010101010101,0x8080808080808080)
= 4096 (0x1000)
mmap(0x0,3387392,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =
34368425984 (0x800849000)
mmap(0x800849000,1138688,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 34368425984 (0x800849000)
mmap(0x800b5f000,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x116000)
= 34371661824 (0x800b5f000)
mprotect(0x800b69000,110592,PROT_READ|PROT_WRITE) = 0 (0x0)
close(3) = 0 (0x0)
sysarch(0x81,0x7fffd2f0,0x80063b0c8,0x0,0xffada580,0x800864b38)
= 0 (0x0)
munmap(0x80063e000,4096) = 0 (0x0)
mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34366283776 (0x80063e000)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
readlink(/etc/malloc.conf,aj,1024) = 2 (0x2)
issetugid(0x80093e153,0x7fffd550,0x6a,0x0,0x2,0x2) = 0 (0x0)
break(0x80) = 0 (0x0)
mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =
34371813376 (0x800b84000)
mmap(0x800f84000,507904,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0)
= 34376007680 (0x800f84000)
munmap(0x800b84000,507904) = 0 (0x0)
x
writev(0x1,0x800c07040,0x2,0x7fffdd40,0x0,0x600d10) = 2 (0x2)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
process exit, rval = 0
--
chs,
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss crashing process
In the last episode (Jul 27), Alexander Best said:
hi there,
i was trying to attach truss to chromium via
'truss -p 18445' and got:
[...]
kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x!
0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,!
0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,!
0x0,0x0,
-- UNKNOWN SYSCALL -14720592 --
write(-14720976,0x8080808080808000,0) = 41 (0x29)
select(94,0x6acd,{0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 70 71 72 73 76 77 78 79 80 81
82 84 87 88 91},0x1,{0.85048848 }) = 73 (0x49)
-- UNKNOWN SYSCALL 303120384 --
#94(0x0,0x0,0x5e,0xb6cd600,0x83ed780,0x3dae410)= 189 (0xbd)
truss: Cannot malloc -14740096 bytes for fd_set array: Cannot allocate memory
Invalid syscalls numbers like that usually mean that truss has attached to a
process in the middle of a syscall. The ptrace API fires the same event for
syscall enter and exit, so if truss is expecting an enter and gets an exit,
you get a mangled syscall number and eventually truss will coredump trying
to decode incorrect data.
Try applying the patch at https://www.evoy.net/FreeBSD/truss.diff , which
amongst other things, fixes this problem. If you just want the syscall fix,
search the diff for 50-50 chance and manually patch that if(){} block in
your source.
--
Dan Nelson
dnel...@allantgroup.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: truss crashing process
On Wed, Jul 27, 2011 at 11:35:49AM -0500, Dan Nelson wrote:
In the last episode (Jul 27), Alexander Best said:
hi there,
i was trying to attach truss to chromium via
'truss -p 18445' and got:
[...]
kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x!
0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,!
0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,!
0x0,0x0,
-- UNKNOWN SYSCALL -14720592 --
write(-14720976,0x8080808080808000,0)= 41 (0x29)
select(94,0x6acd,{0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
22 23 24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 70 71 72 73 76 77 78 79
80 81 82 84 87 88 91},0x1,{0.85048848 }) = 73 (0x49)
-- UNKNOWN SYSCALL 303120384 --
#94(0x0,0x0,0x5e,0xb6cd600,0x83ed780,0x3dae410) = 189 (0xbd)
truss: Cannot malloc -14740096 bytes for fd_set array: Cannot allocate
memory
Invalid syscalls numbers like that usually mean that truss has attached to a
process in the middle of a syscall. The ptrace API fires the same event for
syscall enter and exit, so if truss is expecting an enter and gets an exit,
you get a mangled syscall number and eventually truss will coredump trying
to decode incorrect data.
Try applying the patch at https://www.evoy.net/FreeBSD/truss.diff , which
amongst other things, fixes this problem. If you just want the syscall fix,
search the diff for 50-50 chance and manually patch that if(){} block in
your source.
We have PL_FLAG_SCE/PL_FLAG_SCX for some time. I planned to update truss
to use the flags, as well as to take advantage of PL_FLAG_FORKED to close
the race where truss can miss the forked child.
Unfortunately, the project stalled.
pgpl5z6RehkLM.pgp
Description: PGP signature
truss crashing process
hi there,
i was trying to attach truss to chromium via
'truss -p 18445' and got:
[...]
kevent(26,{},0,{0x1b,EVFILT_READ,0x0,0,0x1,0x44cb600 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0 0x0,0x0,0x0,0,0x0,0x0
0x0,0x0,0x0,0,0x0,0x0},64,{9.469312000 }) = 116 (0x74)
-- UNKNOWN SYSCALL -14720592 --
write(-14720976,0x8080808080808000,0)= 41 (0x29)
select(94,0x6acd,{0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31 40 41 42 43 44 45 46 70 71 72 73 76 77 78 79 80 81 82
84 87 88 91},0x1,{0.85048848 }) = 73 (0x49)
-- UNKNOWN SYSCALL 303120384 --
#94(0x0,0x0,0x5e,0xb6cd600,0x83ed780,0x3dae410) = 189 (0xbd)
truss: Cannot malloc -14740096 bytes for fd_set array: Cannot allocate memory
... this is 100% reproducable, if i wait long enough. this will crash truss
along with chromium.
using '-f' in addition to the flags above gives me:
[...]
truss: Cannot malloc -4220992 bytes for fd_set array: Cannot allocate memory
otaku% truss: can not attach to target process: No such process
strange thing though, when i redirect the first command via ' bla 21', truss
leaves behind a core file, because it segfaults. without redirecting the
output, no core file gets created, because truss doesn't segfault.
cheers.
alex
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
truss calls setpgid()
Hi all,
I've been seeing this bug for a very long time, but I was too lazy to
figure out the root cause earlier. It is TTY related, but in this case
the TTY layer is not to blame. It does things correctly.
When you run a command in truss which calls ioctls on TTYs, it just
locks up. This is because truss runs jobs in a separate process group.
This also means you cannot send signals to it:
truss sleep 1
Pressing ^C here won't work.
I've fixed it locally like this:
Index: usr.bin/truss/setup.c
===
--- usr.bin/truss/setup.c (revision 213113)
+++ usr.bin/truss/setup.c (working copy)
@@ -78,7 +78,6 @@
}
if (pid == 0) { /* Child */
ptrace(PT_TRACE_ME, 0, 0, 0);
- setpgid (0, 0);
execvp(command[0], command);
err(1, execvp %s, command[0]);
Question: was this intentional? I'd rather not break stuff.
Greetings,
--
Ed Schouten e...@80386.nl
WWW: http://80386.nl/
pgpgLNWsANUMZ.pgp
Description: PGP signature
Re: truss calls setpgid()
On Monday, October 11, 2010 9:17:19 am Ed Schouten wrote:
Hi all,
I've been seeing this bug for a very long time, but I was too lazy to
figure out the root cause earlier. It is TTY related, but in this case
the TTY layer is not to blame. It does things correctly.
When you run a command in truss which calls ioctls on TTYs, it just
locks up. This is because truss runs jobs in a separate process group.
This also means you cannot send signals to it:
truss sleep 1
Pressing ^C here won't work.
I've fixed it locally like this:
Index: usr.bin/truss/setup.c
===
--- usr.bin/truss/setup.c (revision 213113)
+++ usr.bin/truss/setup.c (working copy)
@@ -78,7 +78,6 @@
}
if (pid == 0) { /* Child */
ptrace(PT_TRACE_ME, 0, 0, 0);
- setpgid (0, 0);
execvp(command[0], command);
err(1, execvp %s, command[0]);
Question: was this intentional? I'd rather not break stuff.
It was added in the switch from procfs to ptrace(), but it's not clear why the
child has a new process group. It doesn't look like truss ever tries to kill
the entire group for example.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
repeatable panic with truss
Hello, While running the next commands on the attached program I get a panic everytime. gcc rfk-smtpd.c truss ./a.out cat ctrl-c --panic-- Running 5.1-CURRENT from today. I did a 'make world' in a clean /usr/obj dir. System P-II 400Mhz UP, 256 MB, IDE, no acpi enabled. I hope somebody can repeat this and maybe it helps getting FreeBSD more and more stable. (Or maybe it's a known issue.) Ronald. PS: I don't have a debugger enabled kernel, so can't give any more output for now. But I'm willing to make one if it's needed. -- Ronald Klop Amsterdam, The Netherlands rfk-smtpd.c Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
select + signal + truss = LOR
I don't believe I've seen any reports of this particular lock order reversal. I got it by pointing truss at syslogd. My kernel and world were built from a cvsup run slightly before Fri Nov 7 14:50:18 PST 2003. Sleeping on stopevent with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/kern _condvar.c:289 lock order reversal 1st 0xc6bc0aa8 sigacts (sigacts) @ /usr/src/sys/kern/kern_condvar.c:289 2nd 0xc6bbabc4 process lock (process lock) @ /usr/src/sys/kern/kern_synch.c:309 Stack backtrace: backtrace(c08a4327,c6bbabc4,c08a0922,c08a0922,c08a1964) at backtrace+0x17 witness_lock(c6bbabc4,8,c08a1964,135,c08a05a9) at witness_lock+0x672 _mtx_lock_flags(c6bbabc4,0,c08a1964,135,) at _mtx_lock_flags+0xba msleep(c6bbac98,c6bbabc4,5c,c08a4b24,0) at msleep+0x794 stopevent(c6bbab58,2,e,822,c096d440) at stopevent+0x85 issignal(c640,2,c08a1463,bd,c6bbab58) at issignal+0x168 cursig(c640,0,c089e483,121,0) at cursig+0xf0 cv_wait_sig(c0991f34,c0991f00,c08a492e,348,4) at cv_wait_sig+0x448 kern_select(c640,7,8055060,0,0) at kern_select+0x526 select(c640,e5f26d10,c08bea62,3ee,5) at select+0x66 syscall(2f,2f,2f,8,1) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (93), eip = 0x480d03ff, esp = 0xbfbff79c, ebp = 0xbfbffd98 --- Sleeping on stopevent with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/subr _trap.c:260 Sleeping on stopevent with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc6bc0aa8) locked @ /usr/src/sys/kern/subr _trap.c:260 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
truss issue
All,
I found current truss behaviour a bit strange. It coredumps always if
trussed process do without any significant reason for my understanding.
I also confused with comment for commit originally introduced this
functionality
http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/truss/main.c.diff?r1=1.9r2=1.10.
I propose patch attached to make truss always return result of trussed
process and do not kill() itself. What do you think about it?
All the best,
Alexander.
--- usr.bin/truss/main.c.orig Mon Jun 16 23:00:35 2003
+++ usr.bin/truss/main.cMon Jun 16 23:05:03 2003
@@ -144,7 +144,7 @@
struct ex_types *funcs;
int in_exec = 0;
char *fname = NULL;
- int sigexit = 0;
+ int rval = 0;
struct trussinfo *trussinfo;
/* Initialize the trussinfo struct */
@@ -283,10 +283,10 @@
break;
case S_SIG:
fprintf(trussinfo-outfile, SIGNAL %lu\n, pfs.val);
- sigexit = pfs.val;
break;
case S_EXIT:
fprintf (trussinfo-outfile, process exit, rval = %lu\n, pfs.val);
+ rval = pfs.val;
break;
case S_EXEC:
funcs = set_etype(trussinfo);
@@ -305,11 +305,5 @@
}
} while (pfs.why != S_EXIT);
fflush(trussinfo-outfile);
- if (sigexit) {
-if (sigexit == SIGQUIT)
- exit(sigexit);
-(void) signal(sigexit, SIG_DFL);
-(void) kill(getpid(), sigexit);
- }
- return 0;
+ return rval;
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
truss and KSE
While experimenting with the new libpthread, I found that if you run `truss' on a KSE process, both truss and its victim get into a weird state and don't respond to TERM, INT or QUIT signals. The truss proc dies if you send it the KILL signal, but the victim process cannot be killed. Stranger still, it's in the run state but not actually performing any work. I understand that KSE is still an experimental feature but I thought this was worth pointing out because it could be used as a local DoS and we are nearing 5.0-RELEASE. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss and KSE
What is your revision of kern_thread.c? revision 1.58 should fix this problem. - Original Message - From: Tim Robbins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 14, 2002 9:06 PM Subject: truss and KSE While experimenting with the new libpthread, I found that if you run `truss' on a KSE process, both truss and its victim get into a weird state and don't respond to TERM, INT or QUIT signals. The truss proc dies if you send it the KILL signal, but the victim process cannot be killed. Stranger still, it's in the run state but not actually performing any work. I understand that KSE is still an experimental feature but I thought this was worth pointing out because it could be used as a local DoS and we are nearing 5.0-RELEASE. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss and KSE
On Thu, Nov 14, 2002 at 05:39:12AM -0800, David Xu wrote: What is your revision of kern_thread.c? revision 1.58 should fix this problem. I believe it was 1.57. I'll try with 1.58 and let you know if the problem is still there. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Truss segfaults when tracing sshd
Submitter-Id: current-users
Originator:Anders Nordby [EMAIL PROTECTED]
Organization:
Confidential: no
Synopsis: Truss segfaults when tracing sshd
Severity: serious
Priority: medium
Category: bin
Class: sw-bug
Release: FreeBSD 5.0-CURRENT i386
Environment:
FreeBSD current 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Aug 31 09:31:05 GMT 2002
root@current:/usr/obj/usr/src/sys/MYGENERIC i386
Filesystems mounted:
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1f on /tmp (ufs, local, soft-updates)
/dev/ad0s1g on /usr (ufs, local, soft-updates)
/dev/ad0s1e on /var (ufs, local, soft-updates)
eggsilo:/space/distfiles on /usr/ports/distfiles (nfs)
procfs on /proc (procfs, local)
The processor on the system is a 466 MHz Intel Celeron.
Description:
Find your sshd process:
# sockstat -l | grep sshd
root sshd 175 3 tcp6 *:22 *:*
root sshd 175 4 tcp4 *:22 *:*
Truss it through gdb:
# gdb truss
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 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 i386-undermydesk-freebsd...
(no debugging symbols found)...
(gdb) run -p 175
Starting program: /usr/bin/truss -p 175
Now log in to the machine (I'm logging in as root), and return to gdb:
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x08049c77 in free ()
(gdb) bt
#0 0x08049c77 in free ()
#1 0x2806d000 in ?? ()
#2 0x08049e3e in free ()
#3 0x0804eb6d in free ()
#4 0x08049182 in free ()
#5 0x08048d31 in free ()
(gdb)
How-To-Repeat:
On a vanilla -current system from today:
# truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'`
Log into the system with sshd, and truss will segfault:
Segmentation fault (core dumped)
This also seems to happen if you truss sshd while logging out another ssh
session.
Fix:
N/A
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bin/42255: Truss segfaults when tracing sshd
On Sat, Aug 31, 2002 at 05:45:26PM +0200, Anders Nordby wrote:
# truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'`
Log into the system with sshd, and truss will segfault:
There is an even easier way to reproduce this:
gonzo 9% sleep 10
[2] 35245
gonzo 10% truss -p 35245
*segfaults*
It is actually just strcmping a NULL syscall name, which can happen
if you truss a process which is waiting for a syscall to return
when you first attach to the process.
The patch below seems to fix the problem, but I Matthew would like
a more complex fix.
David.
ndex: syscalls.c
===
RCS file: /cvs/FreeBSD-CVS/src/usr.bin/truss/syscalls.c,v
retrieving revision 1.25
diff -u -r1.25 syscalls.c
--- syscalls.c 7 Aug 2002 11:35:18 - 1.25
+++ syscalls.c 31 Aug 2002 21:10:51 -
@@ -411,7 +411,7 @@
if (trussinfo-flags FOLLOWFORKS)
len += fprintf(trussinfo-outfile, %5d: , trussinfo-pid);
- if (!strcmp(name, execve) || !strcmp(name, exit)) {
+ if (name != NULL (!strcmp(name, execve) || !strcmp(name, exit))) {
clock_gettime(CLOCK_REALTIME, trussinfo-after);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Error in truss (Was: Re: error in ncurses in 'make buildworld')
Hi I'ts probably not related, but i have problems :) I have tried a couple of days to compile world, with CFLAGS=-O -pipe, with a system from Jun 16 and it stops at the same place every time. I have tried to clean out /usr/src and obj and resup. Recompiled awk and sh if something happened to them but no change. Any ideas as what happened ? The error is: === usr.bin/truncate rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === usr.bin/truss cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh syscalls.master / usr/src/usr.bin/truss/i386.conf syscalls.master: line 55: syscall number out of sync at 7 line is: struct rusage * rusage ) ; } wait4 wait_args int *** Error code 1 Stop in /usr/src/usr.bin/truss. *** Error code 1 Regards /Johan On Mon, 24 Jun 2002, Claus Guttesen wrote: Hi. What -O level did you compile libc with? Optimisation levels = 2 damage __vfprintf() with the in-tree gcc, causing these same symptoms. The fix is to remove any optimisation options above -O, go into /usr/src/lib/libc, rebuild and install the static libc.a, build and install a static linked awk binary, then rebuild world + kernel as usual. With this advise my 'make world' and 'make kernel' completed without any errors. Thank you. Regards Claus _ Følg VM i fodbold på tæt hold fra Yahoo!s officielle VM-side www.yahoo.dk/vm2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Error in truss (Was: Re: error in ncurses in 'make buildworld')
Compile and install a fresh sed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 24 Jun 2002, Johan Granlund wrote: Hi I'ts probably not related, but i have problems :) I have tried a couple of days to compile world, with CFLAGS=-O -pipe, with a system from Jun 16 and it stops at the same place every time. I have tried to clean out /usr/src and obj and resup. Recompiled awk and sh if something happened to them but no change. Any ideas as what happened ? The error is: === usr.bin/truncate rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === usr.bin/truss cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh syscalls.master / usr/src/usr.bin/truss/i386.conf syscalls.master: line 55: syscall number out of sync at 7 line is: struct rusage * rusage ) ; } wait4 wait_args int *** Error code 1 Stop in /usr/src/usr.bin/truss. *** Error code 1 Regards /Johan On Mon, 24 Jun 2002, Claus Guttesen wrote: Hi. What -O level did you compile libc with? Optimisation levels = 2 damage __vfprintf() with the in-tree gcc, causing these same symptoms. The fix is to remove any optimisation options above -O, go into /usr/src/lib/libc, rebuild and install the static libc.a, build and install a static linked awk binary, then rebuild world + kernel as usual. With this advise my 'make world' and 'make kernel' completed without any errors. Thank you. Regards Claus _ Følg VM i fodbold på tæt hold fra Yahoo!s officielle VM-side www.yahoo.dk/vm2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Error in truss (Was: Re: error in ncurses in 'make buildworld')
On 2002.06.24 21:49:47 +, Johan Granlund wrote: Hi I'ts probably not related, but i have problems :) I have tried a couple of days to compile world, with CFLAGS=-O -pipe, with a system from Jun 16 and it stops at the same place every time. I have tried to clean out /usr/src and obj and resup. Recompiled awk and sh if something happened to them but no change. Any ideas as what happened ? This exact issue has been discussed numerous times on this list before. The fix is to rebuild sed. The error is: === usr.bin/truncate rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === usr.bin/truss cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh syscalls.master / usr/src/usr.bin/truss/i386.conf syscalls.master: line 55: syscall number out of sync at 7 line is: struct rusage * rusage ) ; } wait4 wait_args int *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Error in truss (Was: Re: error in ncurses in 'make buildworld')
Worked. Thanks a million for the _very_ fast answer. /Johan On Mon, 24 Jun 2002, Robert Watson wrote: Compile and install a fresh sed. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Mon, 24 Jun 2002, Johan Granlund wrote: Hi I'ts probably not related, but i have problems :) I have tried a couple of days to compile world, with CFLAGS=-O -pipe, with a system from Jun 16 and it stops at the same place every time. I have tried to clean out /usr/src and obj and resup. Recompiled awk and sh if something happened to them but no change. Any ideas as what happened ? The error is: === usr.bin/truncate rm -f .depend mkdep -f .depend -a /usr/src/usr.bin/truncate/truncate.c echo truncate: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === usr.bin/truss cp /usr/src/usr.bin/truss/../../sys/kern/syscalls.master syscalls.master /bin/sh /usr/src/usr.bin/truss/../../sys/kern/makesyscalls.sh syscalls.master / usr/src/usr.bin/truss/i386.conf syscalls.master: line 55: syscall number out of sync at 7 line is: struct rusage * rusage ) ; } wait4 wait_args int *** Error code 1 Stop in /usr/src/usr.bin/truss. *** Error code 1 Regards /Johan On Mon, 24 Jun 2002, Claus Guttesen wrote: Hi. What -O level did you compile libc with? Optimisation levels = 2 damage __vfprintf() with the in-tree gcc, causing these same symptoms. The fix is to remove any optimisation options above -O, go into /usr/src/lib/libc, rebuild and install the static libc.a, build and install a static linked awk binary, then rebuild world + kernel as usual. With this advise my 'make world' and 'make kernel' completed without any errors. Thank you. Regards Claus _ Følg VM i fodbold på tæt hold fra Yahoo!s officielle VM-side www.yahoo.dk/vm2002 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
truss
Hello, On a fresh current i get this # truss /bin/echo hello truss: cannot open /proc/13245/mem: No such file or directory truss: cannot open /proc/curproc/mem: No such file or directory Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: RAHello, RA RAOn a fresh current i get this RA RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. harti RA RAGreetings, RA RARichard. RA RA RAAn OS is like swiss cheese, the bigger it is, the more holes you get! RA RA RATo Unsubscribe: send mail to [EMAIL PROTECTED] RAwith unsubscribe freebsd-current in the body of the message RA -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote: RAOn a fresh current i get this RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. Mee too message. I tryed same command, 1st time I got same error. I checked with df if /proc was mounted and than trussed again and it show me calls not failing any more. Some timeout of procfs ? # uname -v FreeBSD 5.0-CURRENT #32: Tue Apr 23 08:21:16 CEST 2002 [...] Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Harti Brandt wrote: You need to mount procfs. Oops youre right... Why isn't it listed in /etc/fstab??? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 07:46:27PM +0200, Richard Arends wrote: Hello, On a fresh current i get this # truss /bin/echo hello truss: cannot open /proc/13245/mem: No such file or directory truss: cannot open /proc/curproc/mem: No such file or directory procfs is not mounted by default. Kris msg37816/pgp0.pgp Description: PGP signature
Re: truss
On Sun, Apr 28, 2002 at 08:11:58PM +0200, Riccardo Torrini wrote: On 28-Apr-2002 (17:56:47/GMT) Harti Brandt wrote: RAOn a fresh current i get this RA# truss /bin/echo hello RAtruss: cannot open /proc/13245/mem: No such file or directory RAtruss: cannot open /proc/curproc/mem: No such file or directory You need to mount procfs. Mee too message. I tryed same command, 1st time I got same error. I checked with df if /proc was mounted and than trussed again and it show me calls not failing any more. Some timeout of procfs ? Probably some auto-loading of procfs.ko Kris msg37817/pgp0.pgp Description: PGP signature
Re: truss
On Sun, 28 Apr 2002, Kris Kennaway wrote: procfs is not mounted by default. New to current (one day old baby :-), so didn't know that. sorry() Why isn't it mounted by default?? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: On Sun, 28 Apr 2002, Kris Kennaway wrote: procfs is not mounted by default. New to current (one day old baby :-), so didn't know that. sorry() Why isn't it mounted by default?? I believe DES has a largely rewritten version of truss that doesn't use procfs. When I disabled procfs in sysinstall, I did it thinking that had already been committed, but it turned out not to have been. Hopefully he'll get it finished and committed sometime soon. The rationale for disabling procfs is that its functionality is largely redundant to existing sysctls and debugging mechanisms, and that it has been, and will likely continue to be, an important source of system security holes. The very nature of procfs (mapping one kernel abstraction into another with different security properties) is part of what makes that likely. In fact, if it's not already on the how to harden your system list, unmounting procfs should be at the top of it :-). I think truss is one of the last stragglers that relies on it -- the other is 'ps -e', which gropes through the memory of each process to dig out the environmental variables. This requires that ps both have substantial privilege, and that procfs be present. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 08:49:55PM +0200, Richard Arends wrote: On Sun, 28 Apr 2002, Kris Kennaway wrote: procfs is not mounted by default. New to current (one day old baby :-), so didn't know that. sorry() Why isn't it mounted by default?? Numerous and horrendous security vulnerabilities in the past. Kris msg37821/pgp0.pgp Description: PGP signature
Re: truss
On Sun, 28 Apr 2002, Robert Watson wrote: The rationale for disabling procfs is that its functionality is largely redundant to existing sysctls and debugging mechanisms, and that it has been, and will likely continue to be, an important source of system security holes. Okay disable it :-) I think truss is one of the last stragglers that relies on it -- the other is 'ps -e', which gropes through the memory of each process to dig out the environmental variables. This requires that ps both have substantial privilege, and that procfs be present. Can't we take the privileges away, so that an user only can see his own procs and only root can see all?? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: I think truss is one of the last stragglers that relies on it -- the other is 'ps -e', which gropes through the memory of each process to dig out the environmental variables. This requires that ps both have substantial privilege, and that procfs be present. Can't we take the privileges away, so that an user only can see his own procs and only root can see all?? It's a little more complicated than that. The problem was that procfs provided extremely broad access to the system, but without much granularity. Mostly this meant that if you had root privilege, you could do whatever you wanted, and otherwise, you got a reasonable view of the system (modulo the countless security holes in procfs). So the problem was that ps ran with a lot of privilege -- generally root or 'gid kmem' which amounts to much the same thing. This meant that gating of process information happened in the ps command, or at least, with the help of the ps command deciding not to get around the information gating. In FreeBSD 4.0, this responsibility happens both in userland and the kernel -- the kernel makes some effort to limit access via procfs, but largely allows privileged processes access to most things. So the ps command implemented the limit on what processes you could extract environmental information from. In FreeBSD 5.0, all this information is exported from the kernel using the sysctl() interface, which provides much more information gating, and flexibe policy controls. This exists in part in 4.x, but not completely. In 5.0, ps requires no special privilege, and access control is done entirely in the kernel. However, giving up the ability to grope through the memory of other processes by giving up procfs does limit that one capability -- listing environmental variables. For ps to display this information, either it has to extract it using a kernel facility (such as procfs), or the kernel has to extract it and provide it to ps. So far, we've had to rule out the first due to the security issues, but the second hasn't been implemented. It's not clear there's enough interest in it that someone has felt motivated to do so. Patches would be accepted here, but I think there's some concensus it's not really a necessary feature, and it also raises a lot of security issues of its own (you'd be surprised what ends up in environmental variables, and how hard it is to keep policy in sync between userland and kernel). BTW, 5.0 will also allow (once we commit the MAC framework from the TrustedBSD Project) kernel modules to tweak process visibility protections in the kernel at runtime. For example, you can kldload a mac_seeotheruids.ko policy module, which can limit what processes can view of other processes based on a number of factors, including uids, and information it tags onto the processes. It can also limit access to socket information listed in netstat, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Robert Watson wrote: BTW, 5.0 will also allow (once we commit the MAC framework from the TrustedBSD Project) kernel modules to tweak process visibility protections in the kernel at runtime. For example, you can kldload a mac_seeotheruids.ko policy module, which can limit what processes can view of other processes based on a number of factors, including uids, and information it tags onto the processes. It can also limit access to socket information listed in netstat, etc. When will the TrustedBSD modules commited to current?? Greetings, Richard. An OS is like swiss cheese, the bigger it is, the more holes you get! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Richard Arends wrote: On Sun, 28 Apr 2002, Robert Watson wrote: BTW, 5.0 will also allow (once we commit the MAC framework from the TrustedBSD Project) kernel modules to tweak process visibility protections in the kernel at runtime. For example, you can kldload a mac_seeotheruids.ko policy module, which can limit what processes can view of other processes based on a number of factors, including uids, and information it tags onto the processes. It can also limit access to socket information listed in netstat, etc. When will the TrustedBSD modules commited to current?? The current (vague) plan is to commit them around mid-June, but that may slip a bit depending on development rate. Early access to the feature set is possible via Perforce, or from cvsup10.FreeBSD.org. I'm hoping to have the basic kernel feature set ready for integration by early June, so we might integrate back the changes back into the main tree in phases. I have to warn you that the stuff in the branch is moving pretty quickly, and there are some known poor interactions, especially with non-IP networking types, that we're still tracking down. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Crist J. Clark wrote:
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
probably thinking of top, which still is setgid in -STABLE. You'll find
however, that -e won't work without setgid kmem being turned on. There
are a number of other tools in -CURRENT that aren't setgid kmem where they
are in -STABLE (top, iostat, etc).
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED] NAI Labs, Safeport Network Services
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, Apr 28, 2002 at 05:11:14PM -0400, Robert Watson wrote:
On Sun, 28 Apr 2002, Crist J. Clark wrote:
On Sun, Apr 28, 2002 at 03:59:44PM -0400, Robert Watson wrote:
[snip]
In FreeBSD 5.0, all this information is exported from the kernel using the
sysctl() interface, which provides much more information gating, and
flexibe policy controls. This exists in part in 4.x, but not completely.
In 5.0, ps requires no special privilege, and access control is done
entirely in the kernel.
I think I'm missing something here.
$ uname -r
4.5-RELEASE
$ ls -l /bin/ps
-r-xr-xr-x 1 root wheel 213796 Jan 30 14:30 /bin/ps
ps(1) has no special privileges in 4.x, but I may not understand what
you mean by special privileges? (To me it means s{u,g}id.)
Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was
probably thinking of top, which still is setgid in -STABLE. You'll find
however, that -e won't work without setgid kmem being turned on.
'-e' for ps(1) seems to work fine on processes you own. You cannot see
the environments of other users' processes (of course root can see
everyone's). But you do need /proc for '-e' to work.
There
are a number of other tools in -CURRENT that aren't setgid kmem where they
are in -STABLE (top, iostat, etc).
You know, I'm not sure why top(1) needs it if ps(1) doesn't.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: truss
On Sun, 28 Apr 2002, Crist J. Clark wrote: Hmm. I'd forgotten that the setgid kmem was removed in 4.x; I was probably thinking of top, which still is setgid in -STABLE. You'll find however, that -e won't work without setgid kmem being turned on. '-e' for ps(1) seems to work fine on processes you own. You cannot see the environments of other users' processes (of course root can see everyone's). But you do need /proc for '-e' to work. There might be other criteria where you wish to protect environmental information, such as for setugid processes, in jail, etc. Having the policy in kernel means that you can change it in one place, rather that tracking through various user space programs (which may not even have all the information they need). There are a number of other tools in -CURRENT that aren't setgid kmem where they are in -STABLE (top, iostat, etc). You know, I'm not sure why top(1) needs it if ps(1) doesn't. My recollection is that Thomas Moestl had to add a number of sysctl's to return system information that top previously pulled out of /dev/kmem. There are two related campaigns here: (1) Eliminate the requirements for procfs due to the risks involved There have been a large number of serious vulnerabilities due to the procfs concept a number of operating systems. A high percentage of our local anyone-to-root vulnerabilities have come from procfs. This combined with a largely redundant feature set lead to the conclusion that we should try and phase out the requirement that it be mounted, since a common hardening technique is to unmount it. (2) Eliminate the requirements for kmem due to the risks involved As with procfs, there have been a number of vulnerabilities associated with kmem, and as with procfs, when a vulnerability is present, the level of privilege that can be attained is high -- usually root with a little bit of work. Eiminating the use of kmem and replacing it with better defined sysctl APIs also means that the tight userland/kernel dependencies that used to result in failures during upgrades could be partially eliminated. Likewise, policy implemented in userspace could be further migrated to kernel space (limiting netstat socket display, process listings, etc). In both cases, the actual services themselves are not being eliminated, since they have uses (especially kmem) in some restricted environments (such as development), but the general requirement that they be used for common place activities is being reduced. A number of utilities still use kmem, and if anyone wants to pick up the task of converting them over the sysctl or other mechanisms, they should feel free :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: truss(1) is back in business
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: des 2001/12/08 16:35:30 PST Modified files: sys/fs/procfsprocfs.c procfs_ioctl.c Log: Fix various bugs in the debugging code and reenable it. Revision ChangesPath 1.3 +0 -2 src/sys/fs/procfs/procfs.c 1.2 +9 -7 src/sys/fs/procfs/procfs_ioctl.c Thought you'd like to know. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) is back in business
On Sun, Dec 09, 2001 at 01:38:03AM +0100, Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: des 2001/12/08 16:35:30 PST Modified files: sys/fs/procfsprocfs.c procfs_ioctl.c Log: Fix various bugs in the debugging code and reenable it. Revision ChangesPath 1.3 +0 -2 src/sys/fs/procfs/procfs.c 1.2 +9 -7 src/sys/fs/procfs/procfs_ioctl.c Thought you'd like to know. Thanks! -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) out of commission
On 4 Dec 2001, Dag-Erling Smorgrav wrote: Bruce Evans [EMAIL PROTECTED] writes: Please only commit working code. Tell that to the author of truss(1) (who also wrote procfs(5) in the first place). It used to work. Did it not work when it was first committed? Anyway, there are many more developers now, so breaking the build or a utility wastes more peoples time. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) out of commission
* Bruce Evans [EMAIL PROTECTED] [011204 13:43] wrote: On 4 Dec 2001, Dag-Erling Smorgrav wrote: Bruce Evans [EMAIL PROTECTED] writes: Please only commit working code. Tell that to the author of truss(1) (who also wrote procfs(5) in the first place). It used to work. Did it not work when it was first committed? Anyway, there are many more developers now, so breaking the build or a utility wastes more peoples time. I think what DES is aptly saying is that although it worked, the way in which it worked has caused us a lot problems and it deserves a good replacement. Let me also state in the author's defense (Sean i think) that it's much easier to rewrite something that has already been written than to be the initial implementor and even though it looks like it's in for a rewrite one must congratulate him on a job that has lasted us so long. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) out of commission
Bruce Evans [EMAIL PROTECTED] writes: Please only commit working code. Tell that to the author of truss(1) (who also wrote procfs(5) in the first place). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: truss(1) out of commission
I'm about to commit patches to procfs(5) that will (unfortunately) temporarily disable truss(1), until I finish extending ptrace(2) and rewriting truss(1) to use that instead of procfs(5) (or find a quiet moment to figure out why my legacy support code doesn't work). Until then, use ktrace(1) (or don't upgrade). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: truss(1) out of commission
On 4 Dec 2001, Dag-Erling Smorgrav wrote: I'm about to commit patches to procfs(5) that will (unfortunately) temporarily disable truss(1), until I finish extending ptrace(2) and rewriting truss(1) to use that instead of procfs(5) (or find a quiet moment to figure out why my legacy support code doesn't work). Until then, use ktrace(1) (or don't upgrade). Please only commit working code. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
strange behaviour of mkioctls in kdump/truss
Hi, Since I've moved to -CURRENT a few weeks ago [I'm fairly new to FreeBSD] I had build problems with kdump and truss. The problem I report here are as far as I can judge them, sorry for any errors or inconsistencies. I've tried to find something about an earlier bug report but could not find any. The problem consisted of the definition for TELNO_MAX not defined or included in /usr/include/machine/i4b_rbch_ioctl.h. The definition for this is in /usr/include/machine/i4b_ioctl.h. By coincidence the building of kdump/truss succeeds, due to the fact that mkioctl uses find(1) for the retreiving of the include files. And because i4b_ioctl.h is alphabetical in front of i4b_rbch_ioctl.h it will be included before i4b_rbch_ioctl.h and therefor the value for TELNO_MAX is already defined on the moment i4b_rbch_ioctl.h is included. Due to some reason I don't know yet [please enlighten me on this] i4b_rbch_ioctl.h appeared before i4b_ioctl.h in _my_ ioctl.c! [Although like I told find(1) uses alphabetical order ?!?!] This happened still after various builds and cleans, etc. But after I have touched the files a bit [e.g. editing them for testing] they do also appear in the right order for me now. So in my case make buildworld stopped on this error because it did not know the value of TELNO_MAX, which is correct as far as it goes for the compiler part. Anyway, like I said earlier, due to some luck it went well for a long time. [that is why nobody reported it before probably, otherwise shoot me] The solution to this seems to be simple: #include machine/i4b_ioctl.h in i4b_rbch_ioctl.h Don't hesitate to ask me anything more (that I forgot). Regards, Mark -- Mark Santcroos RIPE Network Coordination Centre PGP KeyID: 1024/0x3DCBEB8D PGP Fingerprint: BB1E D037 F29D 4B40 0B26 F152 795F FCAB 3DCB EB8D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
01/01/2000 buildworld failure in kdump, truss
I did a cvsup on 01/01/2000, and then did a buildworld. It failed in kdump and truss in /usr/src/usr.bin. Thinking the problem was the "make" picking up the wrong include file, I redid the build once I did a make installworld with the latest build (less kdump and truss!). Same problem. Since kdump and truss were last modified on 12/03 (or so), it would seem I am doing something wrong, since the archives don't have any references to this problem. Any pointers? === usr.bin/kdump cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:90: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:80: warning: this is the location of the previous definition In file included from ioctl.c:87: /usr/obj/usr/src/i386/usr/include/sys/joystick.h:36: redefinition of `struct joystick' *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Same thing happens when building "truss" as well. /usr/src/usr.bin/Makefile: # From: @(#)Makefile 8.3 (Berkeley) 1/7/94 # $FreeBSD: src/usr.bin/Makefile,v 1.141 1999/12/23 11:10:23 marcel Exp $ /usr/src/usr.bin/kdump/Makefile: # @(#)Makefile8.1 (Berkeley) 6/6/93 # $FreeBSD: src/usr.bin/kdump/Makefile,v 1.4 1999/12/03 12:50:01 marcel Exp $ /usr/src/usr.bin/truss/Makefile: # $FreeBSD: src/usr.bin/truss/Makefile,v 1.10 1999/12/03 17:35:34 marcel Exp $ Bruce -- --- Bruce Burden[EMAIL PROTECTED] Tandem Computers Inc. 512-432-8944Network Verification 14231 Tandem Blvd. Auto answer(4 rings) Austin, TX 78726 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
