B3 genre kit hangs on exit

#41 @Rene
I don't want to take the thread too far off topic but if it helps you to know the CPUInfo::CPUCount call reports 2 logical processors, 1 core, 1 physical.

I've been meaning to see if I can help add to the AMD CPU info as I have quite a few AMD systems here to test with. If I make any progress I'll pick up on it over in thread going about that.

#42
Hmm, that is good information. I'll change the code to take this into account.

As for testing, I'd be curious to know whether the code reports 1,1,1 for some system that is indeed multi-processing (multicore or multiprocessor).

#43
@Mike
I've modified the snippet somewhat. Should hopefully correctly handle AMD now.

#44 @Rene
Should do the trick.

And here I was deep in the bowels of platformCPUCount.cpp ... thanks for freeing up my evening with the simple fix. =D

#45 That worked Rene, thanks!

#46 @Rene
I have changed the threadpool.cpp according to your suggestions.

Quote:
const U32 baseCount = getMax( numLogical, numCores );
04. if( baseCount )
05. mNumThreads = baseCount * 2;
06. else
07. mNumThreads = 2;

Started a new project, but after quitting it still hangs (XP/32-bits).

Do I have to rebuild the engine? If so, how? I can not find a .sln to rebuild (Visual C++ 2008).

#47 @Matt
Great!

@Richard
Yes, you need to do a build. In your project directory, there's a "generateProjects.bat" file. Run this and then open the solution file in "buildFiles/Visual Studio 2008/" and do a build. This should solve the problem.

#48 awesome fix!!!
thanks Rene

#49
@deepscratch
Thank you, deepscratch. Glad this annoying thing is out of the way for you all.

#50 just one question,
I'm using an amd quad core, shouldnt the fix be 4 and not 2?
there are many people with quads,
and what about dual quads?
maybe change to 8?

I realy dont know

#51 The 2 is just a multiplier. It will spawn two threads per core/processor, so in your case it'll spawn 8 worker threads in total.

//PS: the "mNumThreads = 2" is only for when detection fails and the code couldn't find how many processors/cores there are.

#52 ahh, I understand,
thanks for the explaiation Rene.

#53 This can be moved to the resolved section can't it?

I had to dig through the threads for this when I found I had this problem on a second machine...

#54 This fix actually makes the problem worse for me... :(

I wasn't having the problem consistently, despite numThreads resolving to 0 on my machine, but my artist was seeing the process stick around. I would occasionally see a crash on exit, but the process cleaned up at least.

Now that I've put this fix in the process sticks around on my machine as well. I'll look into it further, but does anyone have any ideas what could cause this?

#55
Yeah, I figure its Thread::join() that is messing up in your case. There's an unresolved race condition there. Pending a fix ATM. Reverting the Thread class to B2 may temporarily solve the issue.

As for numThreads, if zero worker threads are spawned on the SFX's thread pool, then the system *will* deadlock if any SFX resource is requested.

#56 @Rene

It worked out well. Thanks.

#57 Not entirely sure what is causing it, but we have the fixes in and still having issues with closing down the client (we are using quite a bit of modified code from the mmo kit).

Tracked the issue down to winSemaphore. It is trying to aquire the thread before it shuts down. The thread is in a block state and it will literally sit there and wait forever because of this line.

WaitForSingleObject(*(HANDLE*)(mData->semaphore), INFINITE);

I changed the INFINITE to 1000 and it will way for 1 second and that is all. Not entirely sure what is causing the thread to be blocked and never coming out like that, but that was our problem.

#58 The only time I've seen this happen is when the threads got killed off in a forced shutdown using ExitProcess. This left all the synchronization structures in bad state and the main thread was left behind waiting for things that never happen. In B3, Platform::forceShutdown() will cause this kind of deadlock.

I take it, though, that in your case you are seeing this for normal shutdowns.

What is the state of the other threads? Each thread will signal the semaphore before exiting. What do the threads that is being waited on do? Have they already exited?

Are these ThreadPool worker threads that is being waited on? (On Windows 32bit, threads are named and can be easily distinguished)

Is this happening in global dtor cleanup? Has a normal shutdown occurred before?

#59 A normal shutdown would happen once every 10 tries or so. I will need to check to see if the exit process has been rerouted a bit with all of our changes as our entry has. More likely it is something we did, just a note as it seemed Andy was having a similiar issue it seemed. We also have python thrown in the mix, so it just makes things more complicated.

What tool are you using to see the threads (Windows Process Explorer?) or should that be accessable through the Task Manager?

#60
Process explorer shows the threads, too, but likely without names. I meant inside of VS. There's a toolbar called "Debug Location" that shows a dropdown for all threads including their numeric IDs and names.

Can you post a stacktrace you get when breaking at the WaitForSingleObject() call above? And also a list of the threads that are live at that point?

That would be helpful.