Thread: RE: [HACKERS] How do I get the backend server into gdb?

And the answer is an undocumented parameter to the postmaster.  The
parameter "-W 30" (must be inside the "-o " because must it be sent to
postgres not to the postmaster) will cause new processes to wait 30 seconds.
This gave me enough time to find the pid for the new process and execute
"gdb postgres pid" or "xxgdb postgres pid".  This pushed the new postgres
process into the debugger where I could set my break points and debug.  I
discovered this by stumbling around in the code a little.  I suppose if I
had looked at the code first, I would not have had to pose my question.  The
responses to my question surprise me a little.  On one hand, jumping in and
searching the code for my answer was much, much easier than I expected.  On
the other hand, I expected others to suggest the techniques they use for
debugging issues. It makes me wonder how much real debugging is taking
place?  After all, this list is for hackers right?  Sorry for the
negativity.  This last issue has me stumped and I am stuck until I can get
it resolved.  I really don't like being stuck very much.

Thanks, Michael
-----Original Message-----From:    Bruce Momjian [SMTP:maillist@candle.pha.pa.us]Sent:    Wednesday, April 28, 1999
1:54PMTo:    Michael J DavisCc:    scrappy@hub.org; pgsql-hackers@postgreSQL.orgSubject:    Re: [HACKERS]  How do I get
thebackend server into
 
gdb?
There is some option that starts backends, and then sleeps waiting
for agdb connection, or something like that.

Or you can add the sleep yourself.
[Charset iso-8859-1 unsupported, filtering to ASCII...]> The problem I need to debug won't allow me to do this.  A
Postgres>connection starts and then dies very quickly with a user
 
authentication> error or database non existence error before I have a chance to
attach to> the process via gdb.  I need to find out why postgres will not
allow my> Access97 connection to succeed.  Pg_hba.conf appears to be
configured> correctly (it was working and has not changed in past two months).
I need> to have the new postgres session start up in debug.> >     -----Original Message----->     From:    The Hermit
Hacker[SMTP:scrappy@hub.org]>     Sent:    Wednesday, April 28, 1999 10:19 AM>     To:    Michael J Davis>     Cc:
pgsql-hackers@postgreSQL.org>    Subject:    RE: [HACKERS]  How do I get the backend
 
server into> gdb?> > >     You can attach to a running process using gdb... 'gdb -t
<pid>' or>     something like that...its been awhile since I've used it,
sorry...> >     On Wed, 28 Apr 1999, Michael J Davis wrote:> >     > I need to debug this connection problem I am
havingwith
 
Access97.> My>     > question is how can I get the new Postgres backend that
starts up> for Access>     > into debug (gdb)?  I can get the PostMaster open in gdb.>     > >     > Thanks, Michael>
 > > >     Marc G. Fournier                   ICQ#7615664
 
IRC> Nick: Scrappy>     Systems Administrator @ hub.org >     primary: scrappy@hub.org           secondary:>
scrappy@{freebsd|postgresql}.org>     > > 
 

--   Bruce Momjian                        |  http://www.op.net/~candle  maillist@candle.pha.pa.us            |  (610)
853-3000 +  If your life is a hard drive,     |  830 Blythe Avenue  +  Christ can be your backup.        |  Drexel
Hill,Pennsylvania
 
19026

Michael J Davis <michael.j.davis@tvguide.com> writes:
> On the other hand, I expected others to suggest the techniques they use for
> debugging issues.

Well, the attach-to-a-running-backend procedure has always sufficed for
my purposes in backend debugging.  (Some other people like to just start
a backend directly from gdb, but of course that's not going to shed much
light on connection failures.)

If you are having an authorization problem, it's not likely the backend
per se that's at fault --- connection authorization is done in the
postmaster before forking a subprocess, so you should be able to step
through the postmaster's checks just with gdb on the postmaster.

Actually, it'd be best to start with a debugger attached to the frontend
and see exactly what series of messages go back and forth.  That would
at least give you an idea of what phase is failing.  I have no idea how
to do that in a Windows/Access97 environment, but it's easy enough if
you are using psql or some other Unix frontend.  (Read the "protocol"
chapter in the developer's guide to know what's supposed to happen,
then set breakpoints in connectDB() in fe-connect.c.)

It might be that just seeing what error message comes back from the
server will tell you what you need to know --- it looked to me like
Access was unhelpfully providing its own generic message instead of
quoting what the backend or postmaster had to say.  (Note: I installed
more verbose connection-rejection messages just last week, so make sure
you have up to date sources.)

BTW, on at least some platforms, the most recent versions of gdb are
capable of dealing with forked subprocesses intelligently, so that's
also a possible answer if you are chasing a problem that occurs
immediately after the fork.
        regards, tom lane