Anyone else get this error? I seem to get it randomly while testing one of our games,
and I'm not sure what it's linked to. The only thing I can think of is that maybe it's a thread/
timer issue with one of the modules in the engine, but it doesn't give me much to go off of,
even as I use the terminal to view debugging info. Maybe one thread is running over another
or something, or maybe the program is too impatient. This doesn't happen on the PC port so
I'm assuming it's something to do with KOS and how our port interacts with it.
Any tips? I maybe thought of getting rid of that assertion in the following bolded KOS code:
/* Is there anyone waiting? If so, pass off to them */
else if(sm->count < 0)
{
woken = genwait_wake_cnt(sm, 1, 0);
assert(woken == 1);
sm->count++;
}
else
{
/* No one is waiting, so just add another tick */
sm->count++;
}
}
Maybe commenting that assertion out and replacing it with
a while or something (equivalent to sem_trywait), or something
to that effect. I get the feeling the program is moving too fast
for whatever is happening.
For reference, here's the last few lines of our Debug output:
I am using dcload/dctool, but I am only executing the .ELF from dctool, while theglTexImage2D[211]: 64x64 & 3 BPP @0x8c6c6288
LoadImageOGL: Loading "ANIM1"
glTexImage2D[212]: 64x64 & 3 BPP @0x8c6c6288
LoadImageOGL: Loading "STARTAN2"
glTexImage2D[213]: 16x16 & 4 BPP @0x8c6b4970
W_PrecacheModels()
RGL_PreCacheSky()
Ticker: 190 secs
Ticker: 200 secs
Ticker: 200 secs
Ticker: 210 secs
M_SaveDefaults:
config file written
VMUFS: vmu_unlink on invalid path '/a1/dc3dge.cfg'
Config saved to dc3dge.cfg
*** ASSERTION FAILURE ***
Assertion "woken == 1" failed at sem.c:171 in `sem_signal'
mutex_lock: called inside interrupt
arch: shutting down kernel
maple: final stats -- device count = 2, vbl_cntr = 13471, dma_cntr = 13469
vid_set_mode: 640x480 NTSC
mutex_lock: called inside interrupt
mutex_lock: called inside interrupt
mutex_lock: called inside interrupt
mutex_lock: called inside interrupt
mutex_lock: called inside interrupt
mutex_lock: called inside interrupt
Process returned 0 (0x0) execution time : 227.415 s
Press any key to continue.
game data/etc is done on the disc itself. I briefly thought that maybe this is happening
because it's still constantly pinging the router and might get hung up somehow.
Or maybe I totally have the wrong idea, in which case, I will bow to the wizards here.
Other than that, if anyone has any ideas on how I can dig into this further and find out the
exact cause I'm open to that as well.
Thanks!
-Cora
EDIT: Could this be due to the BBA connection? In hindsight, even though I send the ELF and
stream the data from disc, I didn't think that it could be running into trouble because of that...