Re: BUG #2033: Assertion Failure: File: "procarray.c", Line: 492
От | Tom Lane |
---|---|
Тема | Re: BUG #2033: Assertion Failure: File: "procarray.c", Line: 492 |
Дата | |
Msg-id | 18441.1131564576@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #2033: Assertion Failure: File: "procarray.c", (Joel Stevenson <joelstevenson@mac.com>) |
Ответы |
Re: BUG #2033: Assertion Failure: File: "procarray.c",
|
Список | 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 по дате отправления: