Re: [7.0.2] problems with spinlock under FreeBSD?

On Thu, 24 Aug 2000, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> >> What do you get from gdb backtraces on the corefiles?
> 
> > #2  0x80ee847 in s_lock_stuck (lock=0x20048065 "\001", file=0x816723c "spin.c", line=127) at s_lock.c:51
> > #3  0x80ee8c3 in s_lock (lock=0x20048065 "\001", file=0x816723c "spin.c", line=127) at s_lock.c:80
> > #4  0x80f1580 in SpinAcquire (lockid=7) at spin.c:127
> > #5  0x80f3903 in LockRelease (lockmethod=1, locktag=0xbfbfe674, lockmode=1) at lock.c:1044
> > #6  0x80f2af9 in UnlockRelation (relation=0x82063f0, lockmode=1) at lmgr.c:178
> > #7  0x806f25e in index_endscan (scan=0x8208780) at indexam.c:284
> 
> That's interesting ... someone failing to release lock.c's master
> spinlock, it looks like.  Do you have anything in the postmaster log
> from just before the crashes?

okay, nothing that I can see that is 'unusual' in the log files, but as
shown below, at ~10:30am today, the same thing appears to have happened
...

%ls -lt */*.core
-rw-------  1 pgsql  pgsql  22589440 Aug 23 10:39 udmsearch/postgres.core
-rw-------  1 pgsql  pgsql   5505024 Aug 23 10:34 rockwell/postgres.core
-rw-------  1 pgsql  pgsql   5099520 Aug 23 10:33 pg_banners/postgres.core
-rw-------  1 pgsql  pgsql   5009408 Aug 23 10:32 hub_traf_stats/postgres.core
-rw-------  1 pgsql  pgsql   5099520 Aug 23 10:32 trends_acctng/postgres.core
-rw-------  1 pgsql  pgsql   5124096 Aug 23 10:32 area902/postgres.core
-rw-------  1 pgsql  pgsql   5074944 Aug 23 10:32 petpostings/postgres.core
-rw-------  1 pgsql  pgsql   5074944 Aug 23 10:32 counter/postgres.core
-rw-------  1 pgsql  pgsql  10567680 Aug 23 09:56 horde/postgres.core

Check the gdb on a couple of them:

(gdb) where
#0  0x18271d90 in kill () from /usr/lib/libc.so.4
#1  0x182b2e09 in abort () from /usr/lib/libc.so.4
#2  0x80ee847 in s_lock_stuck (lock=0x20048065 "\001", file=0x816723c "spin.c", line=127) at s_lock.c:51
#3  0x80ee8c3 in s_lock (lock=0x20048065 "\001", file=0x816723c "spin.c", line=127) at s_lock.c:80
#4  0x80f1580 in SpinAcquire (lockid=7) at spin.c:127

(gdb) where
#0  0x18271d90 in kill () from /usr/lib/libc.so.4
#1  0x182b2e09 in abort () from /usr/lib/libc.so.4
#2  0x80ee847 in s_lock_stuck (lock=0x20048065 "\001", file=0x816723c "spin.c", line=127) at s_lock.c:51
#3  0x80ee8c3 in s_lock (lock=0x20048065 "\001", file=0x816723c "spin.c", line=127) at s_lock.c:80
#4  0x80f1580 in SpinAcquire (lockid=7) at spin.c:127

they all appear to be in the same place ...

now, I'm running 4 seperate postmaster daemons, with seperate data
directories, as:

ps ux | grep postmaster | grep 543
pgsql 50554  0.0  0.1  6904  556  p0- I     1:12PM   0:04.88 /pgsql/bin/postmaster -D/pgsql/special/sales.org -i -p
5434(postgres)
 
pgsql 61821  0.0  0.1  7080  636  p6- S     4:38PM   3:03.86 /pgsql/bin/postmaster -B 256 -N 128 -o -F -o
/pgsql/logs/5432.61820-S 32768 -i -p 5432 -D/pgsql/data (postgres)
 
pgsql 62268  0.0  0.0  5488    0  p4- IW   -         0:00.00 /pgsql/bin/postmaster -d 1 -N 16 -o -F -o
/pgsql/logs/5433.62267-S 32768 -i -p 5433 -D/pgsql/special/lee (postgres)
 
pgsql 27084  0.0  0.1  5496  596  p4- S     8:25AM   0:54.11 /pgsql/bin/postmaster -d 1 -N 16 -o -F -o
/pgsql/logs/5437.27083-S 32768 -i -p 5437 -D/pgsql/special/mukesh (postgres)
 

and the above core files are from the one running on 5432 ...

you still have your account on that machine if you want to take a quick
look around ... else, anything else I should be looking at?