Very Computer

by **Francisco Rey** » Sun, 21 Apr 2002 00:50:27

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)

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

by **Joe Conw** » Sun, 21 Apr 2002 00:58:47

> 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

---------------------------(end of broadcast)---------------------------

by **Vince Vielhab** » Sun, 21 Apr 2002 01:01:03

> 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.
--
==========================================================================

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
==========================================================================

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

by **Francisco Rey** » Sun, 21 Apr 2002 01:36:54

> > 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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

by **Vince Vielhab** » Sun, 21 Apr 2002 01:41:58

> > > 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.

Vince.
--
==========================================================================

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
==========================================================================

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

by **Doug McNaug** » Sun, 21 Apr 2002 01:44:27

> 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...

---------------------------(end of broadcast)---------------------------

by **Francisco Rey** » Sun, 21 Apr 2002 01:50:06

> > 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 ()

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

by **Vince Vielhab** » Sun, 21 Apr 2002 01:53:14

> 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?

Vince.
--
==========================================================================

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
==========================================================================

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

by **Tom La** » Sun, 21 Apr 2002 02:46:06

> 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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

by **Francisco Rey** » Sun, 21 Apr 2002 04:17:54

> 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)

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Very Computer

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps

Troubleshooting cored dumps