Re: Problems with recent CVS versions and Solaris.

From: Keith Parks <emkxp01(at)mtcc(dot)demon(dot)co(dot)uk>
To: hackers(at)postgresql(dot)org
Subject: Re: Problems with recent CVS versions and Solaris.
Date: 2000-06-01 22:32:13
Message-ID: 200006012232.XAA29590@mtcc.demon.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)mtcc(dot)demon(dot)co(dot)uk>
Subject: Re: [HACKERS] Problems with recent CVS versions and Solaris.
To: emkxp01(at)mtcc(dot)demon(dot)co(dot)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(at)mtcc(dot)demon(dot)co(dot)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 -------------

Attachment Content-Type Size
initdb_debug.txt.Z application/x-sun-compress 2.5 KB
initdb_debug_session.txt.Z application/x-sun-compress 12.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-01 22:42:28 Re: [HACKERS] Re: INET operators and NOT
Previous Message Jacques Huard 2000-06-01 22:29:16 OID question