Re: Core dump on PG 7.1.3

Ok, I'll be the first to admit that my GDB debugging skills are not all that
strong ... ;)

Here's what I did to compile postgres 7.1.3

./configure --enable-debug
gmake CPPFLAGS=-DALLOW_ABSOLUTE_DBPATHS all
gmake install

(i could see that it was compiling debug info into the executables since the
"-g" flag was being used with the gcc commands)

So then I fired up postgres and managed to get it to crash again ...

I changed to the directory containing the core dump and ran gdb

gdb -c core

once GDB started, i typed "bt" and, again, i just got the hex addresses and
no pretty function names or line numbers ...

am I doing something wrong?

Core was generated by `postgres: postgres bnmail [local] UPDATE          '.
Program terminated with signal 11, Segmentation fault.
#0  0x080b992b in ?? ()
(gdb) bt
#0  0x080b992b in ?? ()
#1  0x080ba4b1 in ?? ()
#2  0x080b9f03 in ?? ()
#3  0x080b9f7c in ?? ()
#4  0x080ba16d in ?? ()
#5  0x080ba52d in ?? ()
#6  0x080b9f03 in ?? ()
#7  0x080b9f7c in ?? ()
#8  0x080ba119 in ?? ()
#9  0x080ba521 in ?? ()
#10 0x080ba632 in ?? ()
#11 0x080bdf89 in ?? ()
#12 0x080baadf in ?? ()
#13 0x080be160 in ?? ()
#14 0x080b9259 in ?? ()
#15 0x080bf9d4 in ?? ()
#16 0x080b9295 in ?? ()
#17 0x080b8ee2 in ?? ()
#18 0x080b8eba in ?? ()
#19 0x080b8813 in ?? ()
#20 0x080b84ad in ?? ()
#21 0x080b7974 in ?? ()
#22 0x080fc8b7 in ?? ()
#23 0x080fb3c6 in ?? ()
#24 0x080fc3ae in ?? ()
#25 0x080e7408 in ?? ()
#26 0x080e6ffb in ?? ()
#27 0x080e6265 in ?? ()
#28 0x080e5cb0 in ?? ()
#29 0x080c7417 in ?? ()
#30 0x400ed306 in ?? ()

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Monday, April 01, 2002 4:17 PM
> To: David Esposito
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Core dump on PG 7.1.3
>
>
> "David Esposito" <dvesposito@newnetco.com> writes:
> > However, since this problem needs to be fixed, I see myself being
> > able to do one of two things ...
> > - Recompiling PG 7.1.3 using the debug symbols ..
> > - Upgrading to PG 7.2
> > Is there anything I'm missing here that I could try that is
> non-invasive?
>
> Recompiling with debug symbols should be reasonably non-invasive,
> assuming that you can otherwise duplicate the configuration options.
> (If you're using locally built executables this shouldn't be hard;
> not sure what's involved if you are using RPMs that came from somewhere
> else.)
>
> Updating to 7.2 would imply a dump and restore, which'd very likely make
> the problem go away --- but then we'd not learn anything about what
> caused the crash.  If the underlying bug still exists in 7.2 then it
> might someday bite you again.  Are you more interested in getting up and
> running ASAP, or in helping to debug the problem?
>
>             regards, tom lane