Re: Ideas for easier debugging of backend problems

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ideas for easier debugging of backend problems
Date: 2005-10-27 15:11:41
Message-ID: 20051027151141.GK4259@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 27, 2005 at 10:41:08AM -0400, Tom Lane wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)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(at)svana(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-10-27 15:57:58 Re: ERROR: invalid memory alloc request size <a_big_number_here>
Previous Message Tom Lane 2005-10-27 14:41:08 Re: Ideas for easier debugging of backend problems