Re: Trouble with plpgsql on 7.4.6 - Mailing list pgsql-hackers

From Patrick Welche
Subject Re: Trouble with plpgsql on 7.4.6
Date
Msg-id 20041123155918.GR24971@quartz.newn.cam.ac.uk
Whole thread Raw
In response to Re: Trouble with plpgsql on 7.4.6  ("D'Arcy J.M. Cain" <darcy@druid.net>)
List pgsql-hackers
On Tue, Nov 23, 2004 at 07:25:17AM -0500, D'Arcy J.M. Cain wrote:
> The stderr was in the previous message.  No gripes there either other
> than in the startup after the failure.
> 
> > Also see about getting a stack trace from one of the core dumps.
> 
> I did look at the core file and here is what I saw:
> 
> #0  0x483cafeb in kill () from /usr/lib/libc.so.12
> #1  0x483cd0af in __libc_mutex_catchall_stub (m=1212478892)
>     at /usr/src/lib/libc/thread-stub/thread-stub.c:112
> #2  0x4843f0f7 in free (ptr=<incomplete type>)
>     at /usr/src/lib/libc/stdlib/malloc.c:1149
> #3  0x081b3efc in AllocSetDelete (context=<error type>) at aset.c:464
> #4  0x081b468a in MemoryContextDelete (context=<error type>) at
> #mcxt.c:192

Would setting the following environment variable get you an earlier
abort / more logging? (pthread(3))
    PTHREAD_DIAGASSERT       Possible values are any combinations of:                                   A
Ignoreerrors.                                   a         Abort on errors, creating a core
              dump for further debugging.                                   E         Do not log errors to stdout.
                            e         Log errors to stdout.                                   L         Do not log
errorsvia                                             syslogd(8).                                   l         Log
errorsvia syslogd(8).
 

Cheers,

Patrick


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: patch: plpgsql - access records with rec.(expr)
Next
From: Peter Eisentraut
Date:
Subject: Re: Beta5 now Available