Rockbox

Tasklist

FS#12921 - *PANIC* mutex_unlock->wrong thread

Attached to Project: Rockbox
Opened by Thomas Martitz (kugel.) - Sunday, 22 December 2013, 13:43 GMT
Last edited by Thomas Martitz (kugel.) - Sunday, 22 December 2013, 13:43 GMT
Task Type Bugs
Category Operating System/Drivers
Status New
Assigned To No-one
Operating System Generic RaaA
Severity Medium
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

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?
This task depends upon

Comment by Thomas Martitz (kugel.) - Sunday, 22 December 2013, 13:45 GMT
Just happened again, this time the other way around: "(audio != buffering)"

BT:
1. mutex_unlock()
2. sim_read()
3. get_filename()
4. playlist_peek()
Comment by Michael Sevakis (MikeS) - Sunday, 22 December 2013, 21:15 GMT
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.
Comment by Michael Sevakis (MikeS) - Sunday, 22 December 2013, 21:25 GMT
Another issue could be that some change or difference causes multiple inits for that mutex.
Comment by Thomas Martitz (kugel.) - Sunday, 22 December 2013, 21:29 GMT
So how can a thread unlock a mutex that a different thread locked?
Comment by Michael Sevakis (MikeS) - Sunday, 22 December 2013, 21:38 GMT
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?
Comment by Thomas Martitz (kugel.) - Sunday, 22 December 2013, 21:45 GMT
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.
Comment by Michael Sevakis (MikeS) - Sunday, 22 December 2013, 21:51 GMT
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?
Comment by Thomas Martitz (kugel.) - Monday, 23 December 2013, 18:06 GMT
Yes and no.
Comment by Thomas Martitz (kugel.) - Wednesday, 08 January 2014, 11:45 GMT
It just happened on a normal clipv1 simulator too, configured for SDL threads. Perhaps that's the issue?
Comment by Michael Sevakis (MikeS) - Friday, 10 January 2014, 15:37 GMT
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.
Comment by Thomas Martitz (kugel.) - Friday, 10 January 2014, 15:59 GMT
Going by the backtrace it's related to the sim_thread_unlock() mechansim in io.c too
Comment by Michael Sevakis (MikeS) - Friday, 10 January 2014, 16:44 GMT
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?
Comment by Michael Sevakis (MikeS) - Friday, 10 January 2014, 16:57 GMT
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.
Comment by Michael Sevakis (MikeS) - Friday, 10 January 2014, 17:06 GMT
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.
Comment by Thomas Martitz (kugel.) - Friday, 10 January 2014, 18:24 GMT
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.

Loading...