On Fri, Nov 18, 2011 at 12:00:57AM -0800, Doug Barton wrote: > On 11/17/2011 02:57, Kostik Belousov wrote: > >> > It's not catching there though: > >> > > >> > Reading symbols from /libexec/ld-elf.so.1...done. > >> > Loaded symbols for /libexec/ld-elf.so.1 > >> > 0x28183b2d in accept () at accept.S:3 > >> > 3 RSYSCALL(accept) > >> > (gdb) c > >> > Continuing. > >> > no thread to satisfy query > >> > 0x28183b2d in accept () at accept.S:3 > >> > 3 RSYSCALL(accept) > >> > (gdb) info threads > >> > Cannot get thread info: invalid key > >> > (gdb) > > Err, the other part of my message was that you shall set the breakpoint > > on sigprocmask. > > I'm sorry I'm not making myself clear. We are setting the breakpoint on > sigprocmask. But, maybe I'm doing it wrong. Can you give precise > instructions as to what you want me to do, from the beginning? Sorry to > be so dense. Find the pid of the process issuing excessive number of sigprocmask calls. Do $ gdb /usr/local/bin/httpd (gdb) attach <pid> (gdb) b _sigprocmask (gdb) c Bah ! Breakpoint fired. (gdb) bt (gdb) c <... Repeat ... >
> > > I want to see a backtrace from the breakpoint hit. > > Several times. > > Me too. :) > > Meanwhile, in response to one of the other questions, we are using > mpm_prefork. Also, the particular problem we're seeing does not appear > related to fork(). The pattern of sigprocmask() calls is different from > the pattern you see with fork(). I am sure that your sigprocmask calls do not come from rtld, it is some use of setjmp or sigsetjmp(1), most likely. I am not aware of any significant users of setjmp or sigprocmask in our system libraries. > > > Doug > > -- > > "We could put the whole Internet into a book." > "Too practical." > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/
pgpLtgYwMDdmp.pgp
Description: PGP signature
