Thread
-
Bug report
Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2003-03-21T00:26:49Z
============================================================================ POSTGRESQL BUG REPORT TEMPLATE ============================================================================ Your name : Robert Bruccoleri Your email address : bruc@acm.org System Configuration --------------------- Architecture (example: Intel Pentium) : SGI Origin 3000 Operating System (example: Linux 2.0.26 ELF) : Irix 6.5.18 PostgreSQL version (example: PostgreSQL-7.3.2): PostgreSQL-7.3.2 and possibly 7.2.1 Compiler used (example: gcc 2.95.2) : MIPS Pro 7.4 and MIPS Pro 7.3.1.3, 64 bit compilation model. Please enter a FULL description of your problem: ------------------------------------------------ The PostgreSQL backend core dumps reproducibly with a set of LOCK commands that would normally deadlock. The following debugging session on the core dump shows some details: nunu postgres 101 >>dbx /pg/postgresql-7.3.2/bin/postgres dbx version 7.3.3 (78517_Dec16 MR) Dec 16 2001 07:45:22 Core from signal SIGBUS: Bus error file foo.dbx already exists, appending [3] record input foo.dbx (0 lines) warning: file foo.dbx already exists, appending [4] record output foo.dbx (0 lines) (dbx) where > 0 ExpandConstraints(constraints = 0x1041ad58, nConstraints = 1) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/deadlock.c":586, 0x101df1ec] 1 TestConfiguration(startProc = 0x8006483ebf8) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/deadlock.c":322, 0x101de90c] 2 DeadLockCheckRecurse(proc = 0x8006483ebf8) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/deadlock.c":246, 0x101de698] 3 DeadLockCheckRecurse(proc = 0x8006483ebf8) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/deadlock.c":280, 0x101de828] 4 DeadLockCheck(proc = 0x8006483ebf8) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/deadlock.c":192, 0x101de4a4] 5 CheckDeadLock() ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/proc.c":843, 0x101dd9d0] 6 handle_sig_alarm(postgres_signal_arg = 14) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/proc.c":1145, 0x101de280] 7 _sigtramp(0xc, 0x1, 0xda710a4, 0x7f7f7f7f7f7f7f7f, 0x1034fe50, 0xe, 0x1, 0x9) ["/xlv14/patches/4847/work/irix/lib/libc/libc_64_M4/signal/sigtramp.s":71, 0xda6250c] 8 __syscall(0x41d, 0x2, 0xf1, 0x1, 0x72, 0x75, 0x80044833070, 0x1) ["/xlv14/patches/4847/work/irix/lib/libc/libc_64_M4/sys/syscall.s":20, 0xda93178] 9 _semop(0xf1, 0xffffffcca30, 0x1, 0x1, 0x72, 0x75, 0x80044833070, 0x1) ["/xlv14/patches/4847/work/irix/lib/libc/libc_64_M4/sys/semsys.c":62, 0xda946a4] 10 PGSemaphoreLock(sema = 0x8006483ec08, interruptOK = '\001') ["/pg/postgresql-7.3.2/src/backend/port/pg_sema.c":434, 0x101a8d8c] 11 ProcSleep(lockMethodTable = 0x800648367c8, lockmode = 8, lock = 0x80064861480, holder = 0x800648625d0) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/proc.c":673, 0x101dd5e8] 12 WaitOnLock(lockmethod = 1, lockmode = 8, lock = 0x80064861480, holder = 0x800648625d0) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/lock.c":896, 0x101daa34] 13 LockAcquire(lockmethod = 1, locktag = 0xffffffccc58, xid = 5681, lockmode = 8, dontWait = '') ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/lock.c":685, 0x101da294] 14 LockRelation(relation = 0x104bc560, lockmode = 8) ["/pg/postgresql-7.3.2/src/backend/storage/lmgr/lmgr.c":133, 0x101d81c8] 15 relation_open(relationId = 23467, lockmode = 8) ["/pg/postgresql-7.3.2/src/backend/access/heap/heapam.c":477, 0x1005b46c] 16 LockTableCommand(lockstmt = 0x104c12d8) ["/pg/postgresql-7.3.2/src/backend/commands/lockcmds.c":61, 0x101061e4] 17 ProcessUtility(parsetree = 0x104c12d8, dest = Remote=2, completionTag = 0xffffffccf18 = "") ["/pg/postgresql-7.3.2/src/backend/tcop/utility.c":806, 0x101eb498] 18 pg_exec_query_string(query_string = 0x104c1010, dest = Remote=2, parse_context = 0x104bf120) ["/pg/postgresql-7.3.2/src/backend/tcop/postgres.c":789, 0x101e6cc8] 19 PostgresMain(argc = 4, argv = 0xffffffcd0c0, username = 0x103bf1a9 = "bruc") ["/pg/postgresql-7.3.2/src/backend/tcop/postgres.c":2013, 0x101e8be4] 20 DoBackend(port = 0x103bf078) ["/pg/postgresql-7.3.2/src/backend/postmaster/postmaster.c":2302, 0x101ad4c4] 21 BackendStartup(port = 0x103bf078) ["/pg/postgresql-7.3.2/src/backend/postmaster/postmaster.c":1924, 0x101ac8ec] 22 ServerLoop() ["/pg/postgresql-7.3.2/src/backend/postmaster/postmaster.c":1027, 0x101aae58] 23 PostmasterMain(argc = 8, argv = 0x103b3f98) ["/pg/postgresql-7.3.2/src/backend/postmaster/postmaster.c":788, 0x101aa6c4] 24 main(argc = 8, argv = 0xffffffcdde8) ["/pg/postgresql-7.3.2/src/backend/main/main.c":210, 0x1015fed4] 25 __start() ["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_64_M4/csu/crt1text.s":177, 0x10032c78] (dbx) l 570,590 570 int nConstraints) 571 { 572 int nWaitOrderProcs = 0; 573 int i, 574 j; 575 576 nWaitOrders = 0; 577 578 /* 579 * Scan constraint list backwards. This is because the last-added 580 * constraint is the only one that could fail, and so we want to test 581 * it for inconsistency first. 582 */ 583 for (i = nConstraints; --i >= 0;) 584 { 585 PGPROC *proc = constraints[i].waiter; * 586 LOCK *lock = proc->waitLock; 587 588 /* Did we already make a list for this lock? */ 589 for (j = nWaitOrders; --j >= 0;) 590 { (dbx) p proc 0x7f7f7f7f7f7f7f7f (dbx) p constraints[0] struct {waiter = 0x7f7f7f7f7f7f7f7f, blocker = 0x7f7f7f7f7f7f7f7f, pred = 2139062143, link = 2139062143} (dbx) p constraints[1] struct {waiter = 0x7f7f7f7f7f7f7f7f, blocker = 0x7f7f7f7f7f7f7f7f, pred = 2139062143, link = 2139062143} (dbx) p i 0 (dbx) p nConstraints 1 Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: ---------------------------------------------------------------------- 0) Create a user named tilfordc with all rights. 1) Construct a database using the 'maptracker.sql' schema attached to this message. Use the name, 'maptracker', as an example. 2) Start two psql sessions on maptracker. Issue "BEGIN;" commands in both. 3) In session 1, type "lock mapping;". 4) In session 2, type "lock location;" and then "lock mapping;" 5) In session 1, type "lock location;". The backend will crash in a few seconds. If you know how this problem might be fixed, list the solution below: --------------------------------------------------------------------- +-----------------------------+------------------------------------+ | Robert E. Bruccoleri, Ph.D. | email: bruc@acm.org | | President, Congenomics Inc. | URL: http://www.congen.com/~bruc | | P.O. Box 314 | Phone: 609 818 7251 | | Pennington, NJ 08534 | | +-----------------------------+------------------------------------+ -
Re: Bug report
Tom Lane <tgl@sss.pgh.pa.us> — 2003-03-21T05:34:34Z
"Robert E. Bruccoleri" <bruc@stone.congenomics.com> writes: > The PostgreSQL backend core dumps reproducibly with a set of LOCK commands that > would normally deadlock. Can't duplicate that here, using either 7.3 branch or CVS tip. You sure you have a clean build? regards, tom lane
-
Re: Bug report
Neil Conway <neilc@samurai.com> — 2003-03-21T07:14:50Z
On Thu, 2003-03-20 at 19:26, Robert E. Bruccoleri wrote: > MIPS Pro 7.4 and MIPS Pro 7.3.1.3, 64 bit compilation model. I've seen some other people having troubles with PostgreSQL compiled with Mips Pro on IRIX/MIPS -- does the problem persist if you recompile PostgreSQL with gcc? Cheers, Neil
-
Re: Bug report
Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2003-03-22T04:20:51Z
Dear Neil, > > On Thu, 2003-03-20 at 19:26, Robert E. Bruccoleri wrote: > > MIPS Pro 7.4 and MIPS Pro 7.3.1.3, 64 bit compilation model. > > I've seen some other people having troubles with PostgreSQL compiled > with Mips Pro on IRIX/MIPS -- does the problem persist if you recompile > PostgreSQL with gcc? PostgreSQL does not compile properly with gcc. I've been using PostgreSQL on Irix/MIPS for about six years -- it's quite stable. This bug appears to be related to the use of constraints in deadlock detection, it doesn't look like a compiler problem. --Bob +-----------------------------+------------------------------------+ | Robert E. Bruccoleri, Ph.D. | email: bruc@acm.org | | President, Congenomics Inc. | URL: http://www.congen.com/~bruc | | P.O. Box 314 | Phone: 609 818 7251 | | Pennington, NJ 08534 | | +-----------------------------+------------------------------------+
-
Re: Bug report
Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2003-03-22T04:24:53Z
Dear Tom, > > > "Robert E. Bruccoleri" <bruc@stone.congenomics.com> writes: > > The PostgreSQL backend core dumps reproducibly with a set of LOCK commands that > > would normally deadlock. > > Can't duplicate that here, using either 7.3 branch or CVS tip. You sure > you have a clean build? Oh yes, the regression tests all pass, and we've been using the system heavily. What's different about this case in our shop is the heavy use of constraints. If I gave you access to an SGI running PostgreSQL 7.3.2, would you be willing to log in and explore the problem "live"? If so, I will set this up for you. Regards, Bob +-----------------------------+------------------------------------+ | Robert E. Bruccoleri, Ph.D. | email: bruc@acm.org | | President, Congenomics Inc. | URL: http://www.congen.com/~bruc | | P.O. Box 314 | Phone: 609 818 7251 | | Pennington, NJ 08534 | | +-----------------------------+------------------------------------+
-
Re: Bug report
Tom Lane <tgl@sss.pgh.pa.us> — 2003-03-22T04:52:30Z
> If I gave you access to an SGI running PostgreSQL 7.3.2, would you > be willing to log in and explore the problem "live"? You bet. Do you have gdb installed? regards, tom lane
-
Re: Bug report
Robert E. Bruccoleri <bruc@stone.congenomics.com> — 2003-03-26T00:07:37Z
Dear Tom, > > > > If I gave you access to an SGI running PostgreSQL 7.3.2, would you > > be willing to log in and explore the problem "live"? > > You bet. Do you have gdb installed? Thank you so much. WRT to gdb, it's not available. However, you can use dbx, SGI's debugger. It's similar so you should be able to navigate. We need to discuss the logistics of this. Please call me tomorrow at 609 818 7251 or please send me your phone number, and I'll call you. --Bob +-----------------------------+------------------------------------+ | Robert E. Bruccoleri, Ph.D. | email: bruc@acm.org | | President, Congenomics Inc. | URL: http://www.congen.com/~bruc | | P.O. Box 314 | Phone: 609 818 7251 | | Pennington, NJ 08534 | | +-----------------------------+------------------------------------+