Re: Ideas for easier debugging of backend problems - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Ideas for easier debugging of backend problems
Date
Msg-id 20051027151141.GK4259@svana.org
Whole thread Raw
In response to Re: Ideas for easier debugging of backend problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Ideas for easier debugging of backend problems
List pgsql-hackers
On Thu, Oct 27, 2005 at 10:41:08AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > 1. Move the test for strange memory alloc sizes to the palloc macros so
> > that on error, it points at the palloc call rather than mcxt.c.
>
> What would that accomplish other than bloating the backend?  We can't do
> it anyway, because of double-evaluation risk.

The double-evaluation is avoidable (on GCC at least). I was thinking
about when you --enable-cassert or something. But you're right, the
test in palloc is always on, so you don't save much.

> > 2. Add either a GUC or a command line switch or PGOPTION switch to call
> > setrlimit to set the core size to something bigger. Most places only
> > soft limit the core size, not hard limit.
>
> > 3. Add either a GUC or a command line switch or PGOPTION switch  to
> > automatically invoke and attach gdb on certain types of error.
> > Obviously you can only do this where stdin, stdout and stderr have not
> > been redirected.
>
> Both of these presume you have a programmer running the database, or at
> least someone who's not scared of gdb.

I've been thinking more along the lines that gdb is scriptable. We
could invoke gdb in a way that immediatly dumps a backtrace, the local
variables and some of the globals to a file and display a message to
the user: please attach this to your bug report...

Like today, having all this info upfront would save some time, because
then we wouldn't have to teach people how to use gdb or what variables
are important. Ofcourse, we'd really need to distinguish between
run-of-the-mill errors and actual serious problems.

The second option would help us where users are stymied by the system
trying to change the core size ulimit, why not make it easier?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ideas for easier debugging of backend problems
Next
From: Alvaro Herrera
Date:
Subject: Re: ERROR: invalid memory alloc request size