Memory corruption related to signal emission?

[stampede]

I'd rather not post the entire program online

I understand.
Does it crash if you do not startReceiver() ? You said that there are threads involved - to me its always first place to look for potential errors.
//edit: ok, probably there you have the "emit" statements. You may try to implement single-threaded version of the receiver, my bet is that threads are somehow responsible for the app crash.

[blooglet]

It does not crash if I don't call startReceiver(). But like I said here: if I remove these two signal emission commands (they're executed on the receiver thread, by the way) and still call startReceiver(), the program doesn't crash either. Even when no slots are connected to these signals, the mere emission of these signals causes a SIGSEGV somewhere else in the program. This leads me to believe it's not a thread safety issue but a memory corruption issue. I build with Qt 4.7.4, but any time I suspect an error is my code is caused by a Qt-related bug it turns out I'm wrong.

[stampede]

I think its not possible to help you more without digging through the sources.
Its all up to your creative thinking now. You may try to create separate application, where you can test the VideoStream and VideoStreamerSession classes, without the gui layer. Or try to implement single-threaded version of receiver. Or try to allocate the _vss on heap (if you are out of ideas, why not try this).
Sorry, but without seeing the code, I can't help you more.

[blooglet]

Holy smokes... I just did some more digging and I found the culprit. I looked through all the "// TODO" comments in my code and then I remembered I had an odd issue with a signal/slot connection on a QTimer* that produced a warning in the debug output. The timer just wouldn't fire. I commented out the connect() command because I had more important things to do. When I came back to this snippet of code, I noticed that I hadn't initialized the QTimer*... I feel like crap for wasting your and my own time. Too bad Valgrind didn't detect this, because then the error would have been exposed much earlier.

Thanks for your help, though!

[amleto]

that uninited pointer isnt around or as a consequence of launchGui, is it? your valgrind output says ''uninit'd value was created by a stack allocation'' main.cpp:30

[blooglet]

I've posted main.cpp here. I have no idea what Valgrind is referring to. Probably char* ip but since argv[1] isn't deallocated until the program stops I don't see a problem here.