B3 genre kit hangs on exit

#21 Ok, think I may have found the problem. Can someone try out the following:

In platform/threads/threadSafePriorityQueue.h@159 update the isEmpty() method there to read:

template< typename T, typename K, bool SORT_MIN_TO_MAX, U32 MAX_LEVEL, U32 PROBABILISTIC_BIAS >
bool ThreadSafePriorityQueue< T, K, SORT_MIN_TO_MAX, MAX_LEVEL, PROBABILISTIC_BIAS >::isEmpty()
{
   helpDelete(); // This line is new.
   return ( mHead->getNext( 0 ) == mTail );
}

#22 When I have $pref::SFX::provider = ""; - For XAudio and DirectSound it hangs. I don't have option for OpenAL and when I put it in, it resets the prefs to "";

I'll try your code bit in about 45 minutes. Got to run for a moment.

#23 It's still hanging with that new code :(

#24
Thanks a lot for all the testing, Matt. Much appreciated.

I'll be looking further into this and keep you updated. Hope to have it resolved soon.

#25 I get the same behavior on WinXP SP3.

The problem doesn't occur as long as I stay on the menu of the FPS Genre Kit. I can change the Audio Provider and the Audio Device without problem, and I can exit normally.

But when I'm in blank Room, I can't change the Audio Provider or Audio device without hanging.
And even if I didn't touch them, once in Blank room, I can't exit without hanging.

And I have no sound output at all (I think I had sound yesterday with this beta3).

I didn't test today with the other levels for simplicity.

Nicolas Buquet
www.buquet-net.com/cv/

PS : tested with the PureLight demos : the hang doesn't occur, even if I change the sound provider during level. But I don't think these demos use sound at all.

#26 Maybe I have the same problem. When I am exiting, does not matter if it is in play mode or from the editors, it hangs, but I can close the application from the windows taskbar. I am running Windows XP.

#27 click 4 times on the "X" close button, and it closes, for what its worth

#28 I have no sush problem on windows 7 x86 (are you guys with this issue using a x64 version?)

Sound works fine even on default setting

But i did have T3D hang on physics demo yesterday - will look into this later

#29
Okay, making slow progress on this one.

@Nicolas+Richard
What are your hardware specs? Are you running 64bit systems?

@All
Can someone uncomment the line

//#define DEBUG_SPEW

in platform/threads/threadPool.cpp, recompile, run and produce the hang and then send me a complete copy of the debug output of Visual Studio? (not the console log as that does not include the debug output strings)

This would be most helpful.

So far, I think this happens only on 64bit Windows where for some reason the ThreadPool ends up miscommunicating with its worker threads.

If this happens on a 32bit system for you, please post here.

#30 @Rene

I confirmed last night that I am having the same issue on 32-bit Vista occurring with both XAudio and DirectSound devices. Sorry. =(

I applied your suggested change to the 'isEmpty' method but my results were the same as Matt.

I just got to the office so I won't be able to debug any further until this evening but I will keep an eye on the thread and follow up if I can add anything when I get to it.

#31
Ok, "platform-specific issue" off the table. Thanks for the info, Mike.

I'm now pretty sure it's the ThreadPool not synchronizing properly with its worker threads. The debug output from a hang will shed more light on this.

#32 just had the chance to go at again

the physics demo didn't hang and sound works perfectly

that one time yesterday must have been a fluke

So now i have no hanging and no sound issues with stock beta 3

#33 Rene, my Windows is XP SP3 32-bits, in VMWare Fusion.

So, no 64-bits, sorry.

#34 @Rene
I've sent over a couple runs of debug output with SPEW_DEBUG on and a call stack to the email in your profile.

#35 Mike, that's a golden star for you today. Thanks a lot! Very helpful.

You didn't get any sound in your test runs, did you?

Judging from the debug output, what appears to happen is that the worker threads in the thread pool are never started. This explains both this issue as well as the no-sound issue that people have. The worker threads are supposed to handle all the loading here. The pool spawns them and then pumps work items into the queues. However, when there are no actual threads running, no sound ever gets loaded and the SFX shutdown will deadlock waiting for the work item queue to empty out.

Digging into the Thread code now.

#36

Quote:You didn't get any sound in your test runs, did you?

Correct.

Quote:... However, when there are no actual threads running, no sound ever gets loaded and the SFX shutdown will deadlock waiting for the work item queue to empty out.

Sounds like you have a good handle on it now. Let me know if there is anything else I can help with.

#37 Oh holy c**p!! This thing is so dumb I am shying away from getting public with this :)

Look at this nifty little snippet of mine (in platform/threads/threadPool.cpp):

CPUInfo::CPUCount( numLogical, numCores, numPhysical );

      mNumThreads = ( numCores - 1 ) * 4;

Oh yeah. What's 0*4?? <Bangs his head heavily against the wall>

So, in short: all single-core systems (or systems where the detection failed) will see this issue.

Please change the above to:

CPUInfo::CPUCount( numLogical, numCores, numPhysical );

      const U32 baseCount = getMax( numLogical, numCores );
      if( baseCount )
         mNumThreads = baseCount * 2;
      else
         mNumThreads = 2;

This issue and the no-sound issue probably disappears.

#38 Bingo. Sound is back and shutdown is normal. Stepped through and confirmed the system was detected (incorrectly) as a single core.

Thanks for the fix Rene!

#39
Ok, great. Thanks for all the testing.

BTW, what CPU are you running this on? For Windows, I have plugged some detection code from Intel in there. If it turns out, this thing is unreliable, I'll throw it out and replace it.

#40

Quote:Ok, great. Thanks for all the testing.

Glad to help.

Quote:BTW, what CPU are you running this on?

AMD64 Athlon X2.