Opened 16 years ago

Closed 15 years ago

#3131 closed bug (fixed)

PANIC: _mutex_unlock() failure: thread 43 is trying to release mutex 0x834ec3c0 (current holder 0)

Reported by: kaliber Owned by: mmlr
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

I cannot reproduce the bug, but backtrace may be useful.

PANIC: _mutex_unlock() failure: thread 43 is trying to release mutex 0x834ec3c0 (current holder 0)

Welcome to Kernel Debugging Land...
Thread 43 "timer_thread" running on CPU 0
kdebug> bt
stack trace for thread 43 "timer_thread"
    kernel stack: 0x8021c000 to 0x80220000
      user stack: 0x70041000 to 0x70081000
frame               caller     <image>:function + offset
 0 8021faa4 (+  48) 8005bcd5   <kernel_x86>:invoke_debugger_command + 0x00f5
 1 8021fad4 (+  64) 8005bac5   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x80122a60, int32: 0, 0x0 "<NULL>") + 0x0079
 2 8021fb14 (+  64) 8005be4c   <kernel_x86>:invoke_debugger_command_pipe + 0x009c
 3 8021fb54 (+  48) 8005d3d4   <kernel_x86> ExpressionParser<0x8021fc08>::_ParseCommandPipe(0x8021fc04) + 0x0234
 4 8021fb84 (+  64) 8005c80e   <kernel_x86> ExpressionParser<0x8021fc08>::EvaluateCommand(0x801128a0 "bt", 0x8021fc04) + 0x02ba
 5 8021fbc4 (+ 224) 8005e7fc   <kernel_x86>:evaluate_debug_command + 0x0088
 6 8021fca4 (+  64) 80059bea   <kernel_x86> kernel_debugger_loop() + 0x01ae
 7 8021fce4 (+  32) 8005aa55   <kernel_x86>:kernel_debugger + 0x004d
 8 8021fd04 (+ 192) 8005a9fd   <kernel_x86>:panic + 0x0029
 9 8021fdc4 (+  64) 8003ce20   <kernel_x86>:_mutex_unlock + 0x0074
10 8021fe04 (+  48) 80038b20   <kernel_x86>:heap_memalign + 0x0070
11 8021fe34 (+  48) 8003992a   <kernel_x86>:memalign + 0x0146
12 8021fe64 (+  32) 80039ab0   <kernel_x86>:malloc + 0x0014
13 8021fe84 (+  48) 8004341c   <kernel_x86> get_port_msg(int32: 1886023792, uint32: 0x6c (108)) + 0x0018
14 8021feb4 (+  64) 80044b98   <kernel_x86>:writev_port_etc + 0x0180
15 8021fef4 (+  80) 80045304   <kernel_x86>:_user_write_port_etc + 0x00dc
16 8021ff44 (+ 100) 800cdff2   <kernel_x86>:handle_syscall + 0x00af
user iframe at 0x8021ffa8 (end = 0x80220000)
 eax 0xc7           ebx 0x5ca560        ecx 0x70080c70   edx 0xffff0104
 esi 0x0            edi 0x706a7070      ebp 0x70080cac   esp 0x8021ffdc
 eip 0xffff0104  eflags 0x217      user esp 0x70080c70
 vector: 0x63, error code: 0x0
17 8021ffa8 (+   0) ffff0104   <commpage>:commpage_syscall + 0x0004
18 70080cac (+  64) 00340f59   <libbe.so> BMessage<0x18042480>::_SendFlattenedMessage(0x6c, int32: 258171, int32: 12, int32: 0, int64: 1729878823849164800) + 0x0089
19 70080cec (+  64) 0023c55b   <_APP_> MessageDeliverer<0x18014330>::_SendMessage(MessageDeliverer::Message*: 0x1803e1b0, int32: 258171, int32: 12) + 0x0033
20 70080d2c (+ 128) 0023bdeb   <_APP_> MessageDeliverer<0x18014330>::DeliverMessage(0x18044928, int32: 108, MessagingTargetSet&: 0x70080e7c, int64: 9223372036854775807) + 0x028f
21 70080dac (+ 112) 0023baf1   <_APP_> MessageDeliverer<0x18014330>::DeliverMessage(BMessage*: 0x1800ff50, MessagingTargetSet&: 0x70080e7c, int64: 9223372036854775807) + 0x0095
22 70080e1c (+ 112) 0023b9b6   <_APP_> MessageDeliverer<0x18014330>::DeliverMessage(BMessage*: 0x1800ff50, BMessenger: 0x70080ee8, int64: 9223372036854775807) + 0x004e
23 70080e8c (+ 128) 002405f7   <_APP_> MessageRunnerManager<0x18015ff8>::_DoEvent(MessageRunnerManager::RunnerInfo*: 0x180209d0) + 0x011f
24 70080f0c (+  48) 0024095e   <_APP_> MessageRunnerManager::RunnerEvent<0x1801bf40>::Do(EventQueue*: 0x18022368) + 0x0026
25 70080f3c (+  64) 0023b200   <_APP_> EventQueue<0x18022368>::_EventLooper(0x0) + 0x0114
26 70080f7c (+  48) 0023b0e3   <_APP_> EventQueue<0x18022368>::_EventLooperEntry(NULL) + 0x001f
27 70080fac (+  48) 0053e9b8   <libroot.so>:_get_next_team_info (nearest) + 0x005c
28 70080fdc (+   0) 70080fec   2380:timer_thread_43_stack@0x70041000 + 0x3ffec

Change History (3)

comment:1 by kaliber, 15 years ago

It looks like it have been fixed. I cannot reproduce it with current revision.

comment:2 by axeld, 15 years ago

Component: - GeneralSystem/Kernel
Owner: changed from axeld to mmlr

Michael would know if that has been fixed.

comment:3 by mmlr, 15 years ago

Resolution: fixed
Status: newclosed

Well, it looks like this was a bug in a previous locking strategy (one which I don't really see could have happened with the pretty simple logic back then). In any case the heap locking was recently reworked completely, so it's not possible that this bug could still happen. That sadly doesn't mean that there aren't any other ones hiding :-)

Note: See TracTickets for help on using tickets.