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 , 15 years ago
comment:2 by , 15 years ago
| Component: | - General → System/Kernel |
|---|---|
| Owner: | changed from to |
Michael would know if that has been fixed.
comment:3 by , 15 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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.
It looks like it have been fixed. I cannot reproduce it with current revision.