On Sat, Jan 28, 2012 at 8:45 PM, Michael Brauwerman <michael.brauwer...@redfin.com> wrote: > We did try that with a postgres 9.1.2, compiled from source with debug > flags, but we got 0x10 bad address in gdb. (Obviously we did it wrong > somehow) > > We will keep trying to get a good set of symbols set up.
Hmm. Your backtrace is, on the one hand, unsurprising - because I don't have complete confidence that nocachegetattr won't index off into oblivion given corrupt data on disk - and on the other hand, unconvincing, mostly because of this: warning: core file may not match specified executable file. If you're doing a custom build, it should be enough to use --enable-debug and then gdb the core file with the path to the executable you built. If you're using Red Hat, you can just do debuginfo-install package-name, where package-name is probably something like "postgresql-server". But either way, it's critical that the executable you use to pull the backtrace be exactly the same one that was running when the system went belly-up, and it's hard to be confident that's the case here. All that having been said, it *is* possible, even if you do everything right, to run across a situation where gdb can't extract a backtrace. This mostly commonly happens at higher optimization levels. You might want to try building -fno-omit-frame-pointer or even -O0 to minimize the chances of the compiler doing something that's too clever for gdb. If you do manage to get it working correctly, the backtrace should show not only ALL (rather than only some) functions in the call stack but also the values of the arguments passed to each of those functions, which, probably needless to say, would be awfully helpful in figuring this one out. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs