Re: Problems with recent CVS versions and Solaris. - Mailing list pgsql-hackers

From Keith Parks
Subject Re: Problems with recent CVS versions and Solaris.
Date
Msg-id 200006012232.XAA29590@mtcc.demon.co.uk
Whole thread Raw
In response to Problems with recent CVS versions and Solaris.  (Keith Parks <emkxp01@mtcc.demon.co.uk>)
Responses Re: Problems with recent CVS versions and Solaris.
List pgsql-hackers
Oops, mailed it to myself instead of the list!

It's been a long day...


------------- Begin Forwarded Message -------------

Date: Thu, 1 Jun 2000 23:31:01 +0100 (BST)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] Problems with recent CVS versions and Solaris.
To: emkxp01@mtcc.demon.co.uk
MIME-Version: 1.0

I've managed to get a backtrace, attached, thanks to Ross J. Reedstrom's
excellent example from the archives, also attached.

I'm not sure whether the stack frame shown is corrupt, it seems to just
loop over and over again. (I got fed up after 400+ frames)

The final few frames show us asking for more memory, the point at
which things seem to go out of control.

#0  0xef5d33b8 in _brk_unlocked ()
#1  0xef5ce2f8 in _sbrk_unlocked ()
#2  0xef5ce26c in sbrk ()
#3  0xef585bb0 in _morecore ()
#4  0xef58549c in _malloc_unlocked ()
#5  0xef5852b4 in malloc ()
#6  0x139198 in AllocSetAlloc (set=0x1bea10, size=4032) at aset.c:285
#7  0x139ea8 in GlobalMemoryAlloc (this=0x1bea08, size=4008) at mcxt.c:419
#8  0x1399ec in MemoryContextAlloc (context=0x1bea08, size=4008) at mcxt.c:224
#9  0x12c700 in InitSysCache (relname=0x180f40 "pg_proc",    iname=0x180f08 "pg_proc_oid_index", id=18, nkeys=1,
key=0x19a2f0,   iScanfuncP=0x6e1c8 <ProcedureOidIndexScan>) at catcache.c:705
 
#10 0x1312d8 in SearchSysCacheTuple (cacheId=18, key1=184, key2=0, key3=0,    key4=0) at syscache.c:509

Is this any help?

I'm no expert in gdb, but I can follow instructions. ;-)

Thanks,
Keith.


Keith Parks <emkxp01@mtcc.demon.co.uk>
> 
> Hi all,
> 
> I regularly do a "cvs update" and compile and test PostgreSQL.
> 
> Recently, since about 1 week, I've had a nasty problem.
> 
> Doing an "initdb" seems to suck up all available memory and almost
> kills the system, before dying itself with a SEGV.
> 
> The problem postgress process is:-
> 
>   /usr/local/pgsql/bin/postgres -boot -x -C -F -D/usr/local/pgsql/data -d 
> template1
>   
> The system becomes VERY unresponsive when this postgres process
> starts running, so difficult to attach to with gdb. 
> 
> I'm stuck for a clue as to how to debug this.
> 
> Is anyone else seeing this problem recently?
> 
> Is it just a Solaris problem?
> (Solaris 2.6 on SPARCstation 5)
> 
> Is it just me? :-(
> 
> Help,
> 
> Keith.
> 

------------- End Forwarded Message -------------


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: [BUGS] INET operators and NOT
Next
From: Tom Lane
Date:
Subject: Re: Re: [BUGS] INET operators and NOT