Opened 6 years ago

Closed 4 months ago

#9741 closed bug (not reproducible)

KDL when running make check of Postgresql

Reported by: markh Owned by: nobody
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by diver)

Running make check in hrev45614 (containing a fix for #9734 which I needed), causes the following KDL:

Last message repeated 8 times.
PANIC: _mutex_unlock() failure: thread 2779 is trying to release mutex 0x801b6384 (current holder 2218)

Welcome to Kernel Debugging Land...
Thread 2779 "postgres" running on CPU 1
stack trace for thread 2779 "postgres"
    kernel stack: 0xccf44000 to 0xccf40000
      user stack: 0x61b28000 to 0x62b28000
frame               caller     <image>:function + offset
 0 ccf47d58 (+  32) 80132aa2   <kernel_x86> arch_debug_stack_trace + 0x12
 1 ccf47d78 (+  16) 80092db3   <kernel_x86> stack_trace_trampoline(NULL) + 0x0b
 2 ccf47d88 (+  12) 8012553e   <kernel_x86> arch_debug_call_with_fault_handler + 0x1b
 3 ccf47d94 (+  48) 80094856   <kernel_x86> debug_call_with_fault_handler + 0x5e
 4 ccf47dc4 (+  64) 80092fd3   <kernel_x86> kernel_debugger_loop(0x801718f7 "PANIC: ", 0x8016ebe0 "_mutex_unlock() failure: thread %ld is trying to release mutex %p (current holder %ld)
", 0xccf47e70 "
", int32: 1) + 0x21b
 5 ccf47e04 (+  48) 80093337   <kernel_x86> kernel_debugger_internal(0x801718f7 "PANIC: ", 0x8016ebe0 "_mutex_unlock() failure: thread %ld is trying to release mutex %p (current holder %ld)
", 0xccf47e70 "
", int32: 1) + 0x53
 6 ccf47e34 (+  48) 80094be2   <kernel_x86> panic + 0x36
 7 ccf47e64 (+  64) 800894cc   <kernel_x86> _mutex_unlock + 0x74
 8 ccf47ea4 (+ 160) 800f669f   <kernel_x86> _user_xsi_semop + 0x8f3
 9 ccf47f44 (+ 180) 801281e0   <kernel_x86> handle_syscall + 0xcd
user iframe at 0xccf47fa8 (end = 0xccf48000)
 eax 0x1e          ebx 0x23ba188      exc 0x62b27884  edx 0x610e8114
 esi 0x17cd0fc     edi 0x549b19b0     ebp 0x62b278b0  esp 0xccf47fdc
 eip 0x610e8114 eflags 0x3202    user esp 0x62b27884
 vector: 0x63, error code: 0x0
10 ccf47fab (+   0) 610e8114   <commpage> commpage_syscall + 0x04
11 62b278b0 (+  64) 015162w9   <postgres> PGSemaphoreLock + 0x65
12 62b278f0 (+  64) 0155d4be   <postgres> LWLockAcquireOrWait + 0x14e
13 62b27930 (+  80) 013a2e38   <postgres> XLogFlush + 0x80
14 62b27980 (+ 272) 01396092   <postgres> ForceSyncCommit (nearest) + 0x526
15 62b27a90 (+  48) 01396aab   <postgres> ForceSyncCommit (nearest) + 0xf3f
16 62b27ac0 (+  48) 013974b5   <postgres> CommitTransactionCommand + 0x121
17 62b27af0 (+  32) 0156a484   <postgres> check_log_duration (nearest) + 0x8e0
18 62b27b10 (+ 176) 015686a9   <postgres> pg_plan_queries (nearest) + 0x435
19 62b27bc0 (+ 144) 0156c409   <postgres> PostgresMain + 0x839
20 62b27c50 (+  80) 01525fe3   <postgres> ClosePostmasterPorts (nearest) + 0x290b
21 62b27ca0 (+  48) 015257d2   <postgres> ClosePostmasterPorts (nearest) + 0x20fa
22 62b27cd0 (+ 336) 015224f6   <postgres> PostmasterMain (nearest) + 0x19ee
23 62b27e20 (+ 272) 01521df6   <postgres> PostmasterMain + 0x12ee
24 62b27f30 (+  64) 014b903c   <postgres> main (nearest) + 0x208
25 62b27f70 (+  48) 0134bd3b   <postgres> _start + 0x5b
26 62b27fa0 (+  48) 0117f586   </boot/system/runtime_loader@0x01170000> <unknown> + 0xf506
27 62b27fd0 (+   0) 618e825e   <commpage> commpage_thread_exit + 0x00

I don't know yet if it is reproducible as Haiku now gives another KDL when I try to start it. I will have a look at the other KDL and reinstall Haiku again to see if I can reproduce this one. There might be some typos in the KDL output as I made a photo of the KDL and typed it over. I still have the photo, so I can look back if the KDL above contains something odd.

Change History (4)

comment:1 Changed 6 years ago by markh

Booted the system again after a few hours. The KDL on startup does not occur anymore and running "make check" again completes without a KDL as well. Could this be a timing issue?

comment:2 Changed 6 years ago by diver

Description: modified (diff)

comment:3 Changed 2 years ago by axeld

Owner: changed from axeld to nobody
Status: newassigned

comment:4 Changed 4 months ago by waddlesplash

Resolution: not reproducible
Status: assignedclosed

Possibly; but seeing as nobody has seen this since, and XSI semaphores had some user-memcpy-related bugs which might be relevant here, I'm closing this as not reproducible.

Note: See TracTickets for help on using tickets.