I would be worried if I found a strange process on my development PC (ie:PDM.exe)
> I have no idea what PDM is. None of the functions on the stack are from > my mod. My mod is compiled with symbols for both client and server. > Yes none of those functions are from your Mod code but they, no doubt, are the result of the calls made by the game engine. Any Win32 user mode process that calls an API like ... CreateFile() (which happens to exist in kernel32.dll) will eventually call a stub function in NTDLL.dll (the user mode interface to the native NT API) that then results in a kernel mode call, to service the request, via the file I/O driver, and then the hall.dll. So these functions on the stack, so to speak, are from your code. (I assume you aren't running another app at the same time). > The symbol files for the engine would be useful. I am not hopefull of > seeing them though ... Unless I win the big Christmas lotto draw and buy > a source license :) Microsoft has released symbol files for all Win32 images as well as native NT API. This is not releasing the source at all and posess little risk to Valve. Valve should be freindly here I think and give it up. Read this: http://www.microsoft.com/mspress/books/sampchap/2345a.asp Then read this which is more to the point : http://www.microsoft.com/mspress/books/sampchap/2345b.asp I think a thread in the game engine is waiting for a kernel object to become signaled. At the bottom of the second page that I referenced, it says this: ============================================================================ ===== In reality, the algorithm Microsoft uses is simply the popular "first in, first out" scheme. The thread that has waited the longest for an object gets the object. However, actions can occur in the system that alter this behavior, making it less predictable. This is why Microsoft doesn't explicitly state how the algorithm works. One such action is a thread getting suspended. If a thread waits for an object and then the thread is suspended, the system forgets that the thread is waiting for the object. This is a feature because there is no reason to schedule a suspended thread. When the thread is later resumed, the system thinks that the thread just started waiting on the object. While you debug a process, all threads within that process are suspended when breakpoints are hit. So debugging a process makes the "first in, first out" algorithm highly unpredictable because threads are frequently suspended and resumed. ============================================================================ ====== This scares me. It means that the thread or threads that are suspended, (and will be woken up, when the object or objects become signaled), under some conditions, could result in a situation as you describe where the objects are signaled (or ready) and the thread stalls. Sorry I can't be of more help. Something really weird is going on here and I think your code has uncovered (inadvertantly) this weird phenominon. This is the type of situation where a coder's code (which has no compile errors) causes a problem in the underlying OS API's and it is one of the most frustrating things that can happen. Bottom line is to step back for a moment .. go over your code from stem to stern ... look for anything that is not right. What code has changed since it ran ok ? Look back at your previous code changes to see if you can get it back to working, then you will have narrowed it down. Good luck you will need it. ----- Original Message ----- From: "Codiac" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 23, 2003 8:35 PM Subject: Re: [hlcoders] Registry values for installs and other things > I have no idea what PDM is. None of the functions on the stack are from > my mod. My mod is compiled with symbols for both client and server. > > Google trolling seems to indicate that WaitForMultipleObjects can be > linked to race conditions, which seems to be the situation here. > > Unfortunately I can't figure out what is causing the race conmdition. > > The symbol files for the engine would be useful. I am not hopefull of > seeing them though ... Unless I win the big Christmas lotto draw and buy > a source license :) > > Jeff. > > K. Mike Bradley wrote: > > Yes debuging is fun eh? > > > > The object now is to find out where to set a break point so that you can > > single step perhaps into the user mode calls. > > > > The wait for multiple objects looks suspicious. > > > > I can't tell if these multiple objects (being waited on), are newly created? > > Or are failing (hanging) when created. > > > > I, alas, am not a mod coder and have only just started looking into the SDK. > > > > What is the PDM process? is this your mod code? > > > > You should be able to generate symbols at compile time for the client dll. > > I wonder if Valve offers symbols for their part of the code so one may trace > > into calls there ??? > > > > > > Anyone from Valve have an answer? > > > > > > > > > > > > ----- Original Message ----- > > From: "Codiac" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, December 23, 2003 2:11 AM > > Subject: Re: [hlcoders] Registry values for installs and other things > > > > > > > >>Thanks, but it seems like I got the little buggers installed ok :) > >> > >>K. Mike Bradley wrote: > >> > >> > It's been a while since I set up symbols in Visual studio (VC++) 6 SP5 > >> > but let me know how it goes. I could look up my old notes. > >> > > >> > >>This is what the stack has to say now: > >> > >>NTDLL! [EMAIL PROTECTED] + 11 bytes > >>KERNEL32! [EMAIL PROTECTED] + 158 bytes > >>USER32! [EMAIL PROTECTED] + 224 bytes > >>USER32! [EMAIL PROTECTED] + 29 bytes > >>PDM! 4a00888c() > >>PDM! 4a008aa5() > >>PDM! 4a008a29() > >>KERNEL32! [EMAIL PROTECTED] + 82 bytes > >>565308ec() > >> > >>Still leaves me with no idea wtf is going on :P > >> > >>Jeff. > >> > >> > >>_______________________________________________ > >>To unsubscribe, edit your list preferences, or view the list archives, > > > > please visit: > > > >>http://list.valvesoftware.com/mailman/listinfo/hlcoders > >> > >> > > > > > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > > -- > > Jeff "Codiac" Fearn > ----------------------------------------------------------------- > Lead Coder, Web Master, Server Administrator for SWARM > http://swarm.hlgaming.com > > Coder for Wizard Wars > http://www.planethalflife.com/wizardwars/ > ----------------------------------------------------------------- > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
