Re: Debugging postgresql source on gdb

Hi,

I am trying to debug postgres source code using gdb. I set a breakpoint on a function, but it never stops when it reaches that function. Here are the steps:

1. gdb postgres
2. set args -D test (test is my dbcluster)
3. b hashbuild(this is the function i want to break on)
4. run
5. start a client using ./psql test
6. command to create hash index, which calls the above function.

at this point, i see that the function is being executed because i see my printf statements, but breakpoint never gets triggered.

please advice.

regards,
Shreya

---------------------------------
Get the free Yahoo! toolbar and rest assured with the added security of spyware protection.

Shreya Bhargava <shreya_bhargav(at)yahoo(dot)com> writes:
> 1. gdb postgres
> 2. set args -D test (test is my dbcluster)
> 3. b hashbuild(this is the function i want to break on)
> 4. run

You've set the breakpoint in the postmaster process. It won't propagate
to child backends, at least not without special gdb pushups.

The way that I usually debug things is to start the client psql job,
then determine the PID of the backend serving it, and "attach" to
that process in gdb.

In a development environment where you're likely to have only one or
a few backends running, this shell script might help:

#!/bin/sh

# tee /dev/tty is for user to see the set of procs considered
PROCS=`ps auxww | \
grep postgres: | \
grep -v -e 'grep postgres:' -e 'postgres: stats' -e 'postgres: writer' -e 'postgres: archiver' -e 'postgres: logger' -e 'postgres: autovacuum' | \
tee /dev/tty | \
awk '{print $2}'`

if [ `echo "$PROCS" | wc -w` -eq 1 ]
then
exec gdb $PGINSTROOT/bin/postgres -silent "$PROCS"
else
exec gdb $PGINSTROOT/bin/postgres -silent
fi

This will attach directly to the target backend if there's only one,
else you can examine the ps output to determine which PID to attach to.

regards, tom lane

On 7/22/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Shreya Bhargava <shreya_bhargav(at)yahoo(dot)com> writes:
> > 1. gdb postgres
> > 2. set args -D test (test is my dbcluster)
> > 3. b hashbuild(this is the function i want to break on)
> > 4. run
>
> You've set the breakpoint in the postmaster process. It won't propagate
> to child backends, at least not without special gdb pushups.
>
> The way that I usually debug things is to start the client psql job,
> then determine the PID of the backend serving it, and "attach" to
> that process in gdb.
>
> In a development environment where you're likely to have only one or
> a few backends running, this shell script might help:
>
> #!/bin/sh
>
> # tee /dev/tty is for user to see the set of procs considered
> PROCS=`ps auxww | \
> grep postgres: | \
> grep -v -e 'grep postgres:' -e 'postgres: stats' -e 'postgres: writer' -e 'postgres: archiver' -e 'postgres: logger' -e 'postgres: autovacuum' | \
> tee /dev/tty | \
> awk '{print $2}'`
>
> if [ `echo "$PROCS" | wc -w` -eq 1 ]
> then
> exec gdb $PGINSTROOT/bin/postgres -silent "$PROCS"
> else
> exec gdb $PGINSTROOT/bin/postgres -silent
> fi
>
> This will attach directly to the target backend if there's only one,
> else you can examine the ps output to determine which PID to attach to.
>
> regards, tom lane
>

Also, for gdb to function properly, you should compile the source with
--enable-debug and no compiler optimization i.e:

./configure --enable-debug && CFLAGS=-O0

regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com

On 7/22/07, Sibte Abbas <sibtay(at)gmail(dot)com> wrote:
> On 7/22/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Shreya Bhargava <shreya_bhargav(at)yahoo(dot)com> writes:
> > > 1. gdb postgres
> > > 2. set args -D test (test is my dbcluster)
> > > 3. b hashbuild(this is the function i want to break on)
> > > 4. run
> >
> > You've set the breakpoint in the postmaster process. It won't propagate
> > to child backends, at least not without special gdb pushups.
> >
> > The way that I usually debug things is to start the client psql job,
> > then determine the PID of the backend serving it, and "attach" to
> > that process in gdb.
> >
> > In a development environment where you're likely to have only one or
> > a few backends running, this shell script might help:
> >
> > #!/bin/sh
> >
> > # tee /dev/tty is for user to see the set of procs considered
> > PROCS=`ps auxww | \
> > grep postgres: | \
> > grep -v -e 'grep postgres:' -e 'postgres: stats' -e 'postgres: writer' -e 'postgres: archiver' -e 'postgres: logger' -e 'postgres: autovacuum' | \
> > tee /dev/tty | \
> > awk '{print $2}'`
> >
> > if [ `echo "$PROCS" | wc -w` -eq 1 ]
> > then
> > exec gdb $PGINSTROOT/bin/postgres -silent "$PROCS"
> > else
> > exec gdb $PGINSTROOT/bin/postgres -silent
> > fi
> >
> > This will attach directly to the target backend if there's only one,
> > else you can examine the ps output to determine which PID to attach to.
> >
> > regards, tom lane
> >
>
> Also, for gdb to function properly, you should compile the source with
> --enable-debug and no compiler optimization i.e:
>
> ./configure --enable-debug && CFLAGS=-O0
>

"&&" was a typo, sorry for that. The actual command is:

./configure --enable-debug CFLAGS=-O0

regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com

Thanks very much for the suggestions! will try them out ....

regards,
Shreya

Sibte Abbas <sibtay(at)gmail(dot)com> wrote:
On 7/22/07, Sibte Abbas wrote:
> On 7/22/07, Tom Lane wrote:
> > Shreya Bhargava writes:
> > > 1. gdb postgres
> > > 2. set args -D test (test is my dbcluster)
> > > 3. b hashbuild(this is the function i want to break on)
> > > 4. run
> >
> > You've set the breakpoint in the postmaster process. It won't propagate
> > to child backends, at least not without special gdb pushups.
> >
> > The way that I usually debug things is to start the client psql job,
> > then determine the PID of the backend serving it, and "attach" to
> > that process in gdb.
> >
> > In a development environment where you're likely to have only one or
> > a few backends running, this shell script might help:
> >
> > #!/bin/sh
> >
> > # tee /dev/tty is for user to see the set of procs considered
> > PROCS=`ps auxww | \
> > grep postgres: | \
> > grep -v -e 'grep postgres:' -e 'postgres: stats' -e 'postgres: writer' -e 'postgres: archiver' -e 'postgres: logger' -e 'postgres: autovacuum' | \
> > tee /dev/tty | \
> > awk '{print $2}'`
> >
> > if [ `echo "$PROCS" | wc -w` -eq 1 ]
> > then
> > exec gdb $PGINSTROOT/bin/postgres -silent "$PROCS"
> > else
> > exec gdb $PGINSTROOT/bin/postgres -silent
> > fi
> >
> > This will attach directly to the target backend if there's only one,
> > else you can examine the ps output to determine which PID to attach to.
> >
> > regards, tom lane
> >
>
> Also, for gdb to function properly, you should compile the source with
> --enable-debug and no compiler optimization i.e:
>
> ./configure --enable-debug && CFLAGS=-O0
>

"&&" was a typo, sorry for that. The actual command is:

./configure --enable-debug CFLAGS=-O0

regards,
--
Sibte Abbas
EnterpriseDB http://www.enterprisedb.com

---------------------------------
Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.