Threading n00b: process becomes Zombie!


I’m writing a simple console based MIDI player (Linux) just to test some midi ideas. No GUI classes, so no JUCEApplication either. The single threaded one worked beautifully, using Time::waitForMillisecondCounter [didn’t expect the timing to be so rock solid, but I’m on a realtime kernel here].

Anyway so I decided to put the midi file playing logic in a separate thread, started from the int main(), and have a while loop to read keyboard commands to stop/quit.

I subclassed Thread - class MidiPlayerThread : public Thread - and implemented run(), as well as a custom function setParams (to set midi file name, midi device etc.). In the run() function’s playback loop, I check threadShouldExit(), and if yes, the loop breaks, and the run() function ends. The destructor of this class sets any references to = 0.

Trouble is, when I type “q”, the main thread calls Player.stopThread(), and the playback stops. After this, I delete the thread and some other variables on the heap, and return 0. However, at this point, the program doesn’t actually exit back to the command prompt! ps -aux says the program is .

What am I doing wrong? The source code is here (~130 lines) :

EDIT: I also tried Thread.signalThreadShouldExit(). No difference. Player.isThreadRunning() says no it’s not, and just before return 0, I added cout << Thread::getNumRunningThread(), and it says 0 threads are running just before the final exit. What the hell is wrong?!


try this one, it doesn’t give any problems here:

probably you just forgot to initialiseJuce_NonGUI / shutdownJuce_NonGUI ?



Thanks a lot. I didn’t know about the initialiseJuce_NonGUI functions!

However it still didn’t fix the problem on my end :frowning:
In GDB the “Program exited normally” but not while running directly.
Don’t know what’s up. I’ll try some other tweaks, since if it works on your system, I can be sure the approach is fine.


Update: This issue happens only with the debug builds. With release builds, the threads are shut down properly and the process exits. With debug builds, the thread is killed forcefully, and the process still gets zombified.

A possible bug?


It’s really unlikely that’s a JUCE bug. I suggest you start by looking at the call stack for the thread in question and see where it’s stuck.