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
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
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
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
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
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