Ability to tell the difference between normal and syscall traps
Does FreeBSD's ptrace have a way to tell the difference between normal traps and those caused by a system call? On Linux¹ this is possible by passing PTRACE_O_TRACESYSGOOD option to the ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the syscall number when delivering system call traps, (i.e., deliver (SIGTRAP | 0x80)). I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks related but can't be sure. ¹: http://linux.die.net/man/2/ptrace -- Regards, Ali Polatel pgpxRuRnR7qZP.pgp Description: PGP signature
Re: Ability to tell the difference between normal and syscall traps
On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: Does FreeBSD's ptrace have a way to tell the difference between normal traps and those caused by a system call? On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to the ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the syscall number when delivering system call traps, (i.e., deliver (SIGTRAP | 0x80)). I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks related but can't be sure. ?: http://linux.die.net/man/2/ptrace There is already procfs(5)-based interface to get a reason for stop. Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. The interface can be lifted to ptrace(2), but I think using the capacity of procfs is not wrong there. pgpAppWkN7781.pgp Description: PGP signature
Re: Ability to tell the difference between normal and syscall traps
Kostik Belousov yazmış: On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: Does FreeBSD's ptrace have a way to tell the difference between normal traps and those caused by a system call? On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to the ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the syscall number when delivering system call traps, (i.e., deliver (SIGTRAP | 0x80)). I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks related but can't be sure. ?: http://linux.die.net/man/2/ptrace There is already procfs(5)-based interface to get a reason for stop. Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. The interface can be lifted to ptrace(2), but I think using the capacity of procfs is not wrong there. Thanks, although not optimal, this solution works for me :-) -- Regards, Ali Polatel pgpBbbTrPPIN3.pgp Description: PGP signature
Re: nginx + passenger = segv in _rtld_error on restart on FreeBSD 8.0?
As you may have guessed by my last reply no we didn't we had to revert to apache + passenger, but seems you've found a fix anyway. Out of interest what lead you to the close race condition PR as a potential fix? - Original Message - From: Matt Reimer mattjrei...@gmail.com Steve, Did you figure this out? We're seeing something very similar with nginx + passenger + FreeBSD 8.0. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nginx + passenger = segv in _rtld_error on restart onFreeBSD8.0?
Thanks Matt most appreciated! - Original Message - From: Matt Reimer mattjrei...@gmail.com Steve, The patch for PR 144061 works for us. http://lists.freebsd.org/pipermail/freebsd-hackers/2010-February/030741.html http://www.freebsd.org/cgi/query-pr.cgi?pr=144061 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to get data from kernel module ?
Lukáš Czerner wrote: Hi, I am creating a kernel module and I need to get some information from that module. I can do this with ioctl and pass the data to the user space but it seems a bit unpractical to me, because I do not know the amount of the data - it can differ. I do not know of any way to pass a list of structures to the userspace through ioctl - is there any? So my question is, is there any standard way in FreeBSD to do this ? In linux I would probably use the sysfs, but in FreeBSD I can not find anything similar, except just creating some virtual filesystem on my own and obviously this is not what I want to do. You could use ioctl(). You will need to make two calls. Once without the data pointer and once with. Take a look at src/sbin/ifconfig/ifmedia.c Take a look at sysctl(3) in particular, if you have the sources online look at src/usr.bin/netstat/inet.c or src/usr.bin/netstat/route.c. You will need to also look at their corresponding kernel code. Or finally, you could use kvm(3). Good luck, Patrick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Ability to tell the difference between normal and syscall traps
Kostik Belousov yazmış: On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote: Does FreeBSD's ptrace have a way to tell the difference between normal traps and those caused by a system call? On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to the ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the syscall number when delivering system call traps, (i.e., deliver (SIGTRAP | 0x80)). I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks related but can't be sure. ?: http://linux.die.net/man/2/ptrace There is already procfs(5)-based interface to get a reason for stop. Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. The interface can be lifted to ptrace(2), but I think using the capacity of procfs is not wrong there. Hmm ok, I've been playing around with PIOCSTATUS but it doesn't seem to work, there's not much documentation about it either so I figured I'll just ask. The code is here: http://alip.github.com/code/piocstatus.c The traced child is stopped at the beginning of a system call. I await that the PIOCSTATUS request sets ps.why to S_SCE but it's always zero. Can you help me figure out what I'm doing wrong? :) -- Regards, Ali Polatel pgpgvTyW2eW6u.pgp Description: PGP signature
