- Status Closed
- Percent Complete
- Task Type Bugs
- Category Operating System/Drivers
- Assigned To No-one
- Operating System Generic RaaA
- Severity Medium
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#12921 - *PANIC* mutex_unlock->wrong thread
This panic just occurred in an application build with “(buffering != audio)” with SDL threads.
Backtrace
1: mutex_unlock()
2: sim_read()
3: buffer_handle()
4-5: <somewhere in buffering.c>
How can this happen. Shouldn’t mutexes be 100% safe?
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
Just happened again, this time the other way around: “(audio != buffering)”
BT:
1. mutex_unlock()
2. sim_read()
3. get_filename()
4. playlist_peek()
Mutexes are 100% safe to use as mutexes, sure, but other than that, I’m not sure what that means.
They are owned by the thread in the critical section so mutex_unlock should only be called by the thread that successfully locked it.
A problem, I do see with a thread not its calls being balanced.
Another issue could be that some change or difference causes multiple inits for that mutex.
So how can a thread unlock a mutex that a different thread locked?
It’s not allowed because of priority inheritance which makes the object owned by the locker. A single count semaphore could be used instead but because semaphores don’t have inheritance, priority inversion is possible (it was a constant unpleasant issue before implementing inheritance). My recommendation would be to fix unbalanced calls. Why is that happening now?
I don’t see unbalanced calls, nor multiple inits. Do you see them? The mutex in question is the one taken by sim_read() and it’s released in the same function.
I don’t have the code before me atm and I never encountered the issue myself in the app. Is every thread calling actually a registered thread in the scheduler? Could something be clobbering the mutex from elsewhere?
Yes and no.
It just happened on a normal clipv1 simulator too, configured for SDL threads. Perhaps that’s the issue?
SDL threads? What’s happening in SDL threads these days? That would be the “non-fiber” version, correct? I suppose a normal target build could be checked to see if it’s just that threading.
Going by the backtrace it’s related to the sim_thread_unlock() mechansim in io.c too
Technically, the thread is outside the rockbox kernel at that point and that thread cannot call into the rockbox kernel until it calls sim_thread_lock. Perhaps something recently changed to the calls made during the temporary leave during I/O?
Are multiple thread getting to the host’s io call? This could cause the problem, but shouldn’t happen since they should be serialized by the rockbox mutex before unlocking the scheduler lock.
Wait, there’s no priority in this implementation (there wasn’t when this sim io routine was implemented so I’m going by last knowledge). Mutexes shouldn’t have priority ownership without priority scheduling.
Well, it’s most probable that multiple threads are calling into sim-io. However, as you say there is a mutex that should protect this CS. It’s the same mutex for which the above panic is thrown.
How does priority play a role for this issue? Indeed there is no priority implementated for the sdl threads.
Does this even happen now?