Re: BUG #2033: Assertion Failure: File: "procarray.c", Line: 492 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #2033: Assertion Failure: File: "procarray.c", Line: 492
Date
Msg-id 18441.1131564576@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #2033: Assertion Failure: File: "procarray.c",  (Joel Stevenson <joelstevenson@mac.com>)
Responses Re: BUG #2033: Assertion Failure: File: "procarray.c",  (Joel Stevenson <joelstevenson@mac.com>)
List pgsql-bugs
Joel Stevenson <joelstevenson@mac.com> writes:
> This produced a bunch of core files that show the following backtrace:

> #0  0x001ea038 in ?? ()
> #1  0xbfffa4d8 in ?? ()
> #2  0xbfffa5e0 in ?? ()
> #3  0xbfffa560 in ?? ()
> #4  0x08180844 in ?? ()
> #5  0x00000005 in ?? ()
> #6  0xbfffa4e0 in ?? ()
> #7  0x00000000 in ?? ()

> I'm at a loss as to what to do about it, really; is there a hidden
> configure flag or something that could be in my environment that's
> causing the executable to be stripped?

Nondefault LDFLAGS maybe?  Look at the commands that link all the
SUBSYS.o files to produce the postgres executable.

Also, on most Unixen "file /path/to/postgres" will tell the difference
between a stripped and nonstripped executable.

If "file" says that the executable isn't stripped, then the problem is
either with gdb itself or with the way you're invoking it.  Could we see
a cut-and-paste of the whole terminal session with gdb, rather than just
the result of the bt part?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Joel Stevenson
Date:
Subject: Re: BUG #2033: Assertion Failure: File: "procarray.c",
Next
From: Joel Stevenson
Date:
Subject: Re: BUG #2033: Assertion Failure: File: "procarray.c",