Visual Studio C ++：什么是创建这些线程？ [英] Visual Studio C++: what's creating these threads?

问题描述

我的应用程序是基于对话框的MFC GUI，在Windows上使用线程20年，具有四个主对等窗口（它们都不是主窗口）。当MyApp :: InitInstance（）启动时，Debug-> Windows-> Threads窗口只报告一个线程MainThread。当我跨过第一 CDialog :: Create（）调用时，会创建3个工作线程。我不知道这些是什么，并且会喜欢 - 尤其是会喜欢一个完整的解释书或网页的引用。我尝试在 CreateThread（）上放置一个断点，但VS2008报告：无法找到该函数 ！图标。我也不能单步进入它，如果我打破一个函数调用它。我假设它是一个系统调用，因为内核代码VS08无法达到它。

然后我创建一个工作线程输出音频，并设置为THREAD_PRIORITY_TIME_CRITICAL。

但是，一旦我的应用程式离开MyApp :: InitInstance（），就会有一个神秘线程 优先级在调试线程窗口中显示为-8。我不知道那个线程是什么。任何想法或指针的资源？我尝试在 SetThreadPriority（）上设置一个断点，假设我在任何代码中将其设置为非香草优先级，只是 CreateThread（），它不是一个已知的函数。

对于实际问题，关闭我的应用程序，我破坏和释放所有使用的内存，并得到这个-8线程崩溃，而我这样做。没有源，只是程序集，没有堆栈跟踪或符号。没有提示程序，它的堆损坏，如符号出现在其堆栈或输出窗口。

我可以想到的关于应用程序是：

- 它接收MIDI事件罚款并有多年

工作线程，计算声缓冲器的数据;我设置一个sentinel布尔标志，并等待它以 GetExitCodeThread（）结束;我确实得到退出代码，所以我确定这不是-8线程。 （它的优先级是TimeCritical反正，而不是-8）

- 一切都是无问题，除了内存泄漏，我现在使用 _CRTDBG_MAP_ALLOC 。没有释放数据，我没有崩溃。但是，发现什么确切的对象导致问题，我仍然失去，因为 - 再次 - 我没有实际创建一个线程引用该对象。

解决方案

感谢您帮助找出如何断开线程创建。它变得立即清楚，它是在音频处理库内创建。因为一个给库的一块内存包含要播放的样本，我已经free'd这是主要候选人。

阅读Microsoft文档的行之间，我发现两个额外的函数可能关闭这样的线程（ waveOutReset（）和 waveOutClose（）。在调用它们之后，访问冲突就消失了。对于这种类型的bug，它很难肯定，但对我来说，这似乎是问题的原因。

年，程序只是退出用户命令，没有释放存储，没有问题，只是添加清理代码，问题变得可见，这些事实也支持疑似原因。

I've been using threads for 20 years on Unix and just learning them on Windows, with Visual Studio 2008.

My app is dialogs-based MFC GUI, with four main "peer" windows (none of them a "main" window). When MyApp::InitInstance() starts, the Debug->Windows->Threads window reports just a single thread, MainThread. As I step past the first CDialog::Create() call, 3 worker threads are created. I don't know what these are and would love to--and especially would love a reference to a full explanation book or web page. I tried putting a breakpoint on CreateThread() but VS2008 reports: The function cannot be found. in the hover over the ! icon in the Breakpoints window. I also cannot single-step into it if I break in a function that calls it. I assume its a system call and as kernel code VS08 can't reach into it.

I then create a worker thread that outputs audio and is set to THREAD_PRIORITY_TIME_CRITICAL. This has worked stably for a long time.

However once my app leaves MyApp::InitInstance(), there is a mystery thread created with "Priority" shown as -8 in the Debug Threads window. I don't know what that thread is. Any ideas or pointers to resources? I tried putting a breakpoint on SetThreadPriority(), assuming that I'd hit that in whatever code is setting it to this non-vanilla priority, and just as CreateThread(), it isn't a known function.

And on to the actual issue, as opposed to mere mystery: in shutting down my app, I'm destructing and freeing all the memory I used, and getting a crash in this "-8" thread while I do so. There's no source, just assembly, and no stack trace or symbols. There's no hint from the program that its heap corruption, such as symbols appearing on on its stack or the Output window.

The only extra info I can think to give about the app is that:

-- it receives MIDI events fine and has for years

-- it has one worker thread, calculating data for a sound buffer; I set a sentinel boolean flag and wait for it to end with GetExitCodeThread(); I indeed get the exit code so I'm sure this isn't the -8 thread. (And its priority is "TimeCritical" anyway, not -8)

-- everything is problem free except for memory leaks, which I'm addressing now using _CRTDBG_MAP_ALLOC . Without freeing data, I'm not having the crash. But having found out what exact object is causing the problem, I'm still at a loss because--again--I haven't actually created a thread that refers to that object.

解决方案

Thanks to your help in figuring out how to breakpoint the thread creation. It became instantly clear that it was being created inside the audio processing library. As one gives that library a block of memory containing samples to play, and I had free'd that was the prime candidate.

Reading between the lines of the Microsoft documentation, I found two additional functions that might potentially shut down such a thread (to wit waveOutReset() and waveOutClose(). After calling those, the access violations have disappeared. With this type of bug its hard to be positive, but for me this seems like a likely cause of the problem.

For years, the program simply exited upon user command, without deallocating storage, and didn't have issues. It was only upon adding cleanup code that the problem became visible. These facts also support the suspected cause.

这篇关于Visual Studio C ++：什么是创建这些线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！