Troubleshooting cored dumps

Started by Francisco Reyesalmost 24 years ago10 messagesgeneral

lists@natserv.com

almost 24 years ago

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

Joe Conway

mail@joeconway.com

almost 24 years ago

In reply to: Francisco Reyes (#1)

Re: Troubleshooting cored dumps

Francisco Reyes wrote:

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

run:
gdb [options] [executable-file [core-file or process-id]]

Assuming you're in the directory with the core, it would look something
like:

gdb /usr/local/pgsql/bin/postgres ./core

Once in gdb, run the command "bt" to see a backtrace.

However if you haven't compiled PostgrSQL with --enable-debug, it will
be difficult to tell what was going on.

HTH,

Joe

Vince Vielhaber

vev@michvhf.com

almost 24 years ago

In reply to: Francisco Reyes (#1)

Re: Troubleshooting cored dumps

On Fri, 19 Apr 2002, Francisco Reyes wrote:

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

gdb /full/path/to/postmaster /full/path/to/corefile

You can change either full paths to relative if you want.

Then at the prompt:

gdb> where

And you'll get the necessary info - provided debugging symbols were
compiled in, but even if not you may get an idea of what's wrong.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

Francisco Reyes

lists@natserv.com

almost 24 years ago

In reply to: Vince Vielhaber (#3)

Re: Troubleshooting cored dumps

On Fri, 19 Apr 2002, Vince Vielhaber wrote:

On Fri, 19 Apr 2002, Francisco Reyes wrote:

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

gdb /full/path/to/postmaster /full/path/to/corefile

You can change either full paths to relative if you want.

Then at the prompt:

gdb> where

And you'll get the necessary info - provided debugging symbols were
compiled in, but even if not you may get an idea of what's wrong.

I got
psql.core: not in executable format:
File format not recognized

Doug McNaught

doug@wireboard.com

almost 24 years ago

In reply to: Francisco Reyes (#4)

Re: Troubleshooting cored dumps

Francisco Reyes <lists@natserv.com> writes:

I got
psql.core: not in executable format:
File format not recognized

The first argument to gdb needs to be the postmaster binary; the core
file is the second argument.

-Doug
--
Doug McNaught Wireboard Industries http://www.wireboard.com/

Custom software development, systems and network consulting.
Java PostgreSQL Enhydra Python Zope Perl Apache Linux BSD...

Import Notes

Reply to msg id not found: FranciscoReyes'smessageofFri19Apr2002123625-0400EDT

Vince Vielhaber

vev@michvhf.com

almost 24 years ago

In reply to: Francisco Reyes (#4)

Re: Troubleshooting cored dumps

On Fri, 19 Apr 2002, Francisco Reyes wrote:

On Fri, 19 Apr 2002, Vince Vielhaber wrote:

On Fri, 19 Apr 2002, Francisco Reyes wrote:

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

gdb /full/path/to/postmaster /full/path/to/corefile

You can change either full paths to relative if you want.

Then at the prompt:

gdb> where

And you'll get the necessary info - provided debugging symbols were
compiled in, but even if not you may get an idea of what's wrong.

I got
psql.core: not in executable format:
File format not recognized

psql is the program that blew core? In that case change the above
that reads /full/path/to/postmaster to /full/path/to/psql and try it.

Francisco Reyes

lists@natserv.com

almost 24 years ago

In reply to: Vince Vielhaber (#3)

Re: Troubleshooting cored dumps

On Fri, 19 Apr 2002, Vince Vielhaber wrote:

On Fri, 19 Apr 2002, Francisco Reyes wrote:

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

gdb /full/path/to/postmaster /full/path/to/corefile

Ignore the previous post. :-)
Left out the program.

It turns out that it was psql that crashed.

bestpal:~/sql>gdb /usr/local/bin/psql psql.core
no debugging symbols found)...
Core was generated by `psql'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libpq.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/local/lib/libgnugetopt.so.1...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/libssl.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcrypto.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libz.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libreadline.so.4...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libc.so.4...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libncurses.so.5...(no debugging symbols
found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols
found)...done.
#0 0x28088fec in appendPQExpBufferStr () from /usr/local/lib/libpq.so.2
(gdb) where
#0 0x28088fec in appendPQExpBufferStr () from /usr/local/lib/libpq.so.2
#1 0x28084dfa in PQexec () from /usr/local/lib/libpq.so.2
#2 0x804d6e3 in PQclientEncoding ()
#3 0x804f09e in PQclientEncoding ()
#4 0x80504e8 in PQclientEncoding ()
#5 0x804a125 in PQclientEncoding ()

Vince Vielhaber

vev@michvhf.com

almost 24 years ago

In reply to: Francisco Reyes (#7)

Re: Troubleshooting cored dumps

On Fri, 19 Apr 2002, Francisco Reyes wrote:

It turns out that it was psql that crashed.

bestpal:~/sql>gdb /usr/local/bin/psql psql.core
no debugging symbols found)...
Core was generated by `psql'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libpq.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/local/lib/libgnugetopt.so.1...(no debugging
symbols found)...done.
Reading symbols from /usr/lib/libssl.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcrypto.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libz.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libm.so.2...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libreadline.so.4...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libc.so.4...(no debugging symbols
found)...done.
Reading symbols from /usr/lib/libncurses.so.5...(no debugging symbols
found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols
found)...done.
#0 0x28088fec in appendPQExpBufferStr () from /usr/local/lib/libpq.so.2
(gdb) where
#0 0x28088fec in appendPQExpBufferStr () from /usr/local/lib/libpq.so.2
#1 0x28084dfa in PQexec () from /usr/local/lib/libpq.so.2
#2 0x804d6e3 in PQclientEncoding ()
#3 0x804f09e in PQclientEncoding ()
#4 0x80504e8 in PQclientEncoding ()
#5 0x804a125 in PQclientEncoding ()

I'd look at what you're passing to PQexec. Perhaps a null pointer or
something?

Tom Lane

tgl@sss.pgh.pa.us

almost 24 years ago

In reply to: Francisco Reyes (#1)

Re: Troubleshooting cored dumps

Francisco Reyes <lists@natserv.com> writes:

How does one go about troubleshooting Core Dumps?
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
server sent data ("D" message) without prior row description ("T" message)
DEBUG: pq_flush: send() failed: Broken pipe
Segmentation fault (core dumped)

I'll save you the trouble: I'll bet that psql ran out of memory for a
huge result set. libpq is not real robust about coping with that :-(.

regards, tom lane

#10

Francisco Reyes

lists@natserv.com

almost 24 years ago

In reply to: Tom Lane (#9)

Re: Troubleshooting cored dumps

On Fri, 19 Apr 2002, Tom Lane wrote:

I'll save you the trouble: I'll bet that psql ran out of memory for a
huge result set. libpq is not real robust about coping with that :-(.

Thanks Tom.
That hint was enough. I looked at the query... real hard. :-)
Found that I was missing a join condition so my return set would have been
gigantic (cartisian product of tables with close to 1 Million records)