Horton

Thread

  1. Troubleshooting cored dumps

    Francisco Reyes <lists@natserv.com> — 2002-04-19T15:50:01Z

    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)

  2. Re: Troubleshooting cored dumps

    Joe Conway <mail@joeconway.com> — 2002-04-19T15:58:32Z

    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

  3. Re: Troubleshooting cored dumps

    Vince Vielhaber <vev@michvhf.com> — 2002-04-19T16:00:38Z

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

  4. Re: Troubleshooting cored dumps

    Francisco Reyes <lists@natserv.com> — 2002-04-19T16:36:25Z

    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

  5. Re: Troubleshooting cored dumps

    Doug McNaught <doug@wireboard.com> — 2002-04-19T16:40:26Z

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

  6. Re: Troubleshooting cored dumps

    Vince Vielhaber <vev@michvhf.com> — 2002-04-19T16:41:20Z

    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.

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

  7. Re: Troubleshooting cored dumps

    Francisco Reyes <lists@natserv.com> — 2002-04-19T16:41:31Z

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

  8. Re: Troubleshooting cored dumps

    Vince Vielhaber <vev@michvhf.com> — 2002-04-19T16:44:16Z

    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?

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

  9. Re: Troubleshooting cored dumps

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-04-19T17:45:13Z

    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. Re: Troubleshooting cored dumps

    Francisco Reyes <lists@natserv.com> — 2002-04-19T19:17:34Z

    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)