"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> The software we are running is a build from the beta2 release, with
> no special options specified at ./configure time. Would you expect
> such a build to include the debug info you wanted?
No, you need configure --enable-debug, which is not the default.
For working with a beta release, --enable-cassert isn't a bad idea
either, though it is probably not relevant to your problem.
> (gdb) bt
> #0 0x40197b46 in recv () from /lib/i686/libc.so.6
> #1 0x0813485f in secure_read ()
> #2 0x08138f7b in pq_recvbuf ()
> #3 0x081393a9 in pq_getbyte ()
> #4 0x08195565 in PostgresMain ()
> #5 0x081716c5 in ServerLoop ()
> #6 0x0817232e in PostmasterMain ()
> #7 0x0813aad8 in main ()
> Which seemed to show reasonable information, to my untrained eye.
Yeah, that looks expected for a non-debug build. (Debug build would
show call parameters too, which is why it would be more helpful
even apart from the "(corrupt stack?)" problem.)
> That got me wondering whether the "(corrupt stack?)" note on the
> previous backtrace might be something real.
More likely, it's specific to particular places in the code that got
optimized in a way that gdb couldn't figure out.
regards, tom lane
