|
Pages: [1]
|
 |
|
Author
|
Topic: OS X "semaphore" lockup - ugly workaround (Read 2847 times)
|
Foo von Bar
Guest
|
Well, I found a rather unpleasant workaround to the problem I posted here before about, i.e. UQM locking up with a message about semaphores -- but giving no stack backtrace or anything, even in debugging mode.
The workaround -- to disable the second processor on my dual-CPU G4! The very same compile of the very same current CVS version of UQM runs just fine on my system when booted with only a single CPU running. (However, UQM runs just fine on my dual-P3 Linux box in the office ....)
Now, that's a little bit extreme of a workaround, so I do hope this discovery can help those who actually know something about SMP and threading find what's wrong! Again, the problem occurs during what I'd call scene transitions, e.g. when loading the melee menu back up after a battle, or landing on a planet, or loading the starmap -- and is intermittent.
Incidentally, if there are any other Mac users here who don't know how to shut off the second CPU on a dual system, here's the trick: boot into Open Firmware (Cmd-Option-O-F) and enter "setenv boot-args cpus=1", then "boot". To turn the second CPU back on, go back into Open Firmware and "setenv boot-args cpus=2".
|
|
|
|
|
Logged
|
|
|
|
PhracturedBlue
Frungy champion
 Offline
Posts: 88
Me developer. Here me roar!
|
Exactly which semaphore message are you getting?
|
|
|
|
|
Logged
|
|
|
|
Foo von Bar
Guest
|
Exactly which semaphore message are you getting?
Just prior to the crash:
WARNING: trying to clear a free semaphore (value=1)
And then, when hitting Ctrl-C to exit the program (the ` key does not work):
WARNING: SetSemaphore did not return 0, this could be bad!
|
|
|
|
|
Logged
|
|
|
|
PhracturedBlue
Frungy champion
Offline
Posts: 88
Me developer. Here me roar!
|
Well I put that message there, and it should be harmless if you see it as the game loads (there is a problem with the clock semaphore initialization that causes it). If you see it at any other time, it is bad. Assuming you are compiling from source, go into libs/threads/thrcommon.c and in ClearSemaphore, comment out the 'return' right after that Warning message. that will allow the semaphore to be double freed, and should cause a spew of identical warnings while in SolarSystem view. If it stops the hang, that would be VERY useful to know.
|
|
|
|
|
Logged
|
|
|
|
PhracturedBlue
Frungy champion
Offline
Posts: 88
Me developer. Here me roar!
|
Okay, I just reread your original post, and my previous message may not be of much use after all. Do you have IRC access? In general, I can add code to monitor all of the Semaphores, and tell you which one failed (which would be very helpful), but it is a non-trivial patch, and I'm not sure I want to place it in CVS without getting it tested (and since I can't duplicate your problems, I can't test it too thoroughly). If you cann't get on IRC, I can probably post a patch here for you to test, but it'd be easier in a more rapid-response environment.
By the way, for anyone interested, even though Semaphores can have values >1, in UQM they should only have values of 1 and 0.
|
|
|
|
|
Logged
|
|
|
|
PhracturedBlue
Frungy champion
Offline
Posts: 88
Me developer. Here me roar!
|
Alright here you go:
http://phracturedblue.com/sc2/semcheck.diff
This patch should help you debug any semaphore locking issues.
It will basically spew out information about any possible probblems it sees with the semaphores (not everything that is reported is a problem though) Hopefully it can help you determine where the deadlock is.
note that this patch will not go into CVS (at least in its current form), so use it at your own risk. You'll need the latest CVS (as of 12/22) forit to patch in cleanly.
|
|
|
|
|
Logged
|
|
|
|
PhracturedBlue
Frungy champion
Offline
Posts: 88
Me developer. Here me roar!
|
Okay one more update.
CVS currently includes a modified version of the patch I posted earlier, and it should help. There is also a deadlock debugger in the code (disabled by default). Enable it by going into libs/threads/thrcommon.c and changing
#undef DEBUG_SEM_DEADLOCK
to
#define DEUG_SEM_DEADLOCK
This will turn on code that will report a message whenever a SemaphoreSet is blocked for more than 60 seconds. You will get messages whenever you spend time in planet view, etc, but if your system seems to deadlock, it should print out a message after a minute telling you what is going on.
|
|
|
|
|
Logged
|
|
|
|
Foo von Bar
Guest
|
This will turn on code that will report a message whenever a SemaphoreSet is blocked for more than 60 seconds. You will get messages whenever you spend time in planet view, etc, but if your system seems to deadlock, it should print out a message after a minute telling you what is going on.
Well, I'm now running the current CVS build with two processors, and I am happy to say that I have not had a chance yet to use this debugger ... since it is not crashing. I am, I suppose, a *happy camper*. Thanks! If it does start crashing, I will show up again here *frumple* with a useful debug message.
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1]
|
|
|
|
|
