• 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
Attached to Project: Rockbox
Opened by kugel. - 2013-12-22
Last edited by Bilgus - 2019-08-04

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

This panic just occurred in an application build with “(buffering != audio)” with SDL threads.

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?

Closed by  Bilgus
2019-08-04 19:22
Reason for closing:  Works For Me

Just happened again, this time the other way around: “(audio != buffering)”

1. mutex_unlock()
2. sim_read()
3. get_filename()
4. playlist_peek()

MikeS commented on 2013-12-22 21:15

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.

MikeS commented on 2013-12-22 21:25

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?

MikeS commented on 2013-12-22 21:38

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.

MikeS commented on 2013-12-22 21:51

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?

MikeS commented on 2014-01-10 15:37

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

MikeS commented on 2014-01-10 16:44

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?

MikeS commented on 2014-01-10 16:57

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.

MikeS commented on 2014-01-10 17:06

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.

MikeS commented on 2014-09-16 03:10

Does this even happen now?


Available keyboard shortcuts


Task Details

Task Editing