OK .. now I have to understand "WHAT THE FUCK is going on" ..
Apparently the reason is ..
Code: Select all
SDK Assertion Failure: '!(mutex->_ownerThread == current)' in LockMutex() at pid=134(T4K-Switch), tid=631(MainThread)
nn::os::LockMutex(): <translated from japanese > An attempt was made to recursively lock a mutex that cannot be recursively locked.
While calling my :
Code: Select all
uint32_t AudioRendererThread::playSoundWithRate(int soundNumber, float with_rate, float vol);
Now HOW IN THE HECK this can even happen "it should not be possible", the thread that calls that thing is a totally separate one from the thread that does shit with that thing .. then "it should be totally impossible" that function that does a thing like Lock/set some parms/unlock/return could ever be called "twice in the middle" from the SAME thread ..
It's like "the same thing that should be 'locked' into a thing lock/update/unlock someway manages to do a thing like "lock/who knows what" "lock again" .. which should not be possible .. there's some SHIT going on !!
At least thank to that guy on twitter that found a 100% repeateable way to make it happen.
This is the culprit that does the bug ..
Code: Select all
void fShot::explode()
{
particleInitialiser pi=piDefaults;
pi.posBase=pos;
pi.startScale.x=16*g_g->POINT_SIZE;
pi.startScale.y=20*g_g->POINT_SIZE;
pi.endScale.x=4*g_g->POINT_SIZE;
pi.endScale.y=4*g_g->POINT_SIZE;
g->audio.playSound(SND_EXPLO, 1);
That "playsound" that then calls another little thing when the "fShot" explodes.
This needs .. "deep investigation" ...
5 .. MINS LATER ...
MA DIO (*&$*(£"&$( £",, ,MA DIO (")£$("$(£*$()"£ ..,. MA D*$(£)"$*()"£$
BECAUSE I AM F*(DSDHJSDS * STUPID !! HOW ! HOW ! IT NEVER HAPPENED HERE IN MONTHS !!!
IT'S SO STUPID !!! It's ONE LINE CODE FIX !!!
.. ok so the logic goes .. NOTE it need that mutex "lock" because there's another thread that "pumps samples" into the "channels" and does the mixing/effects/etc. so when you read/update some params "it has to be exclusive" otherwise you'd mess up with memory and have all sort of shit going on.
The "logic" goes ..
0. If already too many instances of that sound are in play don't even try
1. Lock the mutex
2. check if there's a "channel" available
3. if not "they are all busy with sounds can't add more", return
4. found a "channel", fill it with params
5. unlock the mutex
6. return
... can you see the SUPER STUPID error ...
I had "incredible weird shit errors" in this port that sometime took me A WEEK to find out what they actually were .. and turns out it was all "super crappy shit" like "forgot to initialise a var" ( that in 99.99% of cases was '0' and all was going on except in 0.01% cases ) .. oh dear ..
So the fix ?
Goes simply as that :
3. if not "they are all busy with sounds can't add more", { UNLOCK THE MUTEX, return }
... fuck ...
[edit] - "added for a sheep" .. 再帰ロック不可のミューテックスを再帰ロックしようとしました。
I down want to invest an hour plus in Pure or Survival if at any point it will freeze but I am sure Giles will fix asap and its all good practice !
