Toolkit Pro - App Hangs in CXTPSoundManager

Print Page | Close Window

App Hangs in CXTPSoundManager

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=22888
Printed Date: 22 December 2024 at 10:40pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: App Hangs in CXTPSoundManager

Posted By: cpede
Subject: App Hangs in CXTPSoundManager
Date Posted: 09 February 2016 at 10:42am

I have seen a problem when closing down my application. It sometimes hangs in the WaitForSingleObject in the following code in XTPSystemHelpers:

void CXTPSoundManager::StopThread()

{

if (NULL != m_hThread)

{

PostThreadMessage(m_dwThreadId, WM_QUIT, 0, 0);

::WaitForSingleObject(m_hThread, INFINITE);

::CloseHandle(m_hThread);

m_hThread = 0;

m_dwThreadId = 0;

}

I'm not using sound, but it think that the code is always called by v17.0.0.

I'm I the only one seeing this problem?

-cpede

-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)

Replies:

Posted By: SvenC
Date Posted: 10 February 2016 at 1:42am

Did you check what the thread with id m_dwThreadId is doing?

-------------
--
SvenC

Toolkit Pro 15.3.1, 16.2.4, 16.3.1, 16.4.0, 17.2.0, 17.3.0, 18.0.1, 18.2 with VC++ 2010, 2012, 2013, 2015, 2017

Posted By: cpede
Date Posted: 10 February 2016 at 3:28am

I have found that the problem lies in the stopping of the sound manager thread from a DLL.

It seems that a DLL opened using LoadLibrary creates a new instance of the CXTPSoundManager* AFX_CDECL XTPSoundManager() and then calls a new instance of the sound thread in void CXTPSoundManager::StartThread().

So now there is a sound manager for the main application and one for each DLL loaded calling e.g. CXTPCommandBars::TrackPopupMenu.

Then it seem that unloading the DLL calls void CXTPSoundManager::StopThread(), but the WM_QUIT thread message send to the SoundThreadProc is never received.

Any ideas?

Should I do something about XTPCommandBars in the InitInstance of the DLLs.

Can I call CXTPSoundManager::StopThread() earlier from the DLLs?

-cpede

-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)

Posted By: cpede
Date Posted: 10 February 2016 at 5:15am

I can see that the code for void CXTPSoundManager::StopThread() has changed a lot since v15.3.1.

I think the problem is related to loader lock of the DLL, meaning that the thread events are somehow locked, during exiting the DLL.

Looking at the v15.3.1 code it always eventually calls TerminateThread in the DLLs, most likely since the GetExitCodeThread does not return the correct exit code.

CJ probably needs to look at similar constructions for ending threads, and avoiding INFINITE waits.

-cpede

-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)

Posted By: cpede
Date Posted: 25 August 2016 at 10:34am

This problem still exist in v1720.

My call-stack looks like this:

It happens when I try to unload a DLL using ::FreeLibrary.

Just noted this parallel thread:

Could that cause some kind of lock?

-cpede

-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)

Posted By: cpede
Date Posted: 26 September 2016 at 10:26am

Anyone looked at this problem?

-cpede

-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)

Posted By: cpede
Date Posted: 15 November 2018 at 5:05am

Am I really the only one having this problem?

void CXTPSoundManager::StopThread()
{
  if (NULL != m_hThread)
  {
    // start changed code
    PostThreadMessage(m_dwThreadId, WM_QUIT, 0, 0);
    DWORD dwCount = 0, dwExitCode = 0;
    while (GetExitCodeThread(m_hThread, &dwExitCode) && dwExitCode == STILL_ACTIVE)
    {
      dwCount++;
      if (dwCount > 10)
      {
          TerminateThread(m_hThread, 0);
          break;
      }
      ::WaitForSingleObject(m_hThread, 100);
    }
    // end changed code

    // start changed code
    // PostThreadMessage(m_dwThreadId, WM_QUIT, 0, 0);
    // ::WaitForSingleObject(m_hThread, INFINITE);
    // end changed code

    ::CloseHandle(m_hThread);
    m_hThread = 0;
    m_dwThreadId = 0;
  }
}

The PostThreadMessage does not get through unless a Sleep or WaitForSingleObject is forcing a thread shift? The correction above works in all cases also when freeing a DLL.

-cpede

-------------
Product: Xtreme ToolkitPro (24.0.0)
Platform: Windows 10 (x64)
Language: Visual Studio 2017 (C++)