On Wed, May 10, 2006 at 04:52:38PM -0500, Jim C. Nasby wrote:
> On Wed, May 10, 2006 at 04:24:45PM -0400, Alvaro Herrera wrote:
> > Jim C. Nasby wrote:
> > > We tried reproducing this on a backup server. We haven't been able to
> > > wedge the system into a state where there's tons of sblock processes
> > > and nothing's getting done, but we were able to get some processes into
> > > sblock and get stack traces:
> > >
> > > #0 0x000000080135bd2c in recvfrom () from /lib/libc.so.6
> > > #1 0x00000000004f9898 in secure_read ()
> > > #2 0x00000000004fed7b in TouchSocketFile ()
> > > #3 0x00000000004fee27 in pq_getbyte ()
> > > #4 0x000000000055febf in PostgresMain ()
> > > #5 0x000000000053a487 in ClosePostmasterPorts ()
> > > #6 0x000000000053bab7 in PostmasterMain ()
> > > #7 0x0000000000500436 in main ()
> >
> > This stack trace doesn't make any sense. ClosePostmasterPorts is not
> > calling PostgresMain. And pq_getbyte is not calling TouchSocketFile,
> > which in turn isn't calling secure_read.
>
> So I see... that's rather disturbing... any idea why gdb would end up
> that confused?
Given you don't have debug enabled, it's likely all static symbols have
been dropped from the symbol table and gdb is guessing by listing the
function with the highest address before the actual function.
You could try to find a consistant call tree where the functions call
eachother in the right order. Or just compile with debug symbols
enabled. It doesn't make a difference in performance or memory usage,
only diskspace (about 16MB on my machine, probably more on yours).
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.