dangerous QThread

**Radagast** · 20th July 2008, 13:49

well, I have a main thread with QApplication exec()-ing and then I start a secondary QThread. There something very bad might happen (for example attempt to read data of another process, which isn't catched even with catch(...)). Are there any means to make OS terminate not the whole process, but only the secondary thread and send appropriate signal to the main thread? I'd be happy for WinXP/Vista and Linux solution, but cross-platform (as Qt itself) solution would be ideal. Thanks in advance!

**wysota** · 21st July 2008, 10:25

Don't you think it would be better to implement your application in such a way that it doesn't do things that are not allowed?

As threads share memory space, if one of them tries to corrupt the memory, the whole process has to be terminated. If you wish to avoid that, you have to make sure each of the execution flows has its own memory space, for example by using separate processes instead of separate threads. You can then use one of many available IPC mechanisms to communicate between the processes.

**Radagast** · 21st July 2008, 19:00

If it is only ATTEMPT to corrupt memory, the main thread shouldn't be corrupted after the termination of the secondary thread afaik. The sec.thread has its own code and stack segments, OS clear them and then pass the control to the main thread, perhaps notifying it "oops I've just killed your child".
Anyway I've just discovered SEH exceptions, I suppose it will help.

What do you think, which errors may rise while reading corrupted binary file of complex structure (ints, floats, strings, bitmaps etc)?

**marcel** · 21st July 2008, 19:17

Originally Posted by Radagast

What do you think, which errors may rise while reading corrupted binary file of complex structure (ints, floats, strings, bitmaps etc)?

mostly buffer overruns, but depends what/how you read... you could implement a completely safe file loader... all applications have mechanisms to detect corrupted files.
I just think you're trying to reinvent the wheel there.

**Radagast** · 21st July 2008, 19:33

I mean loading with QFile and QDataStream:

perator<<
wheel..perhaps. I'm new to Qt

**wysota** · 22nd July 2008, 23:05

Originally Posted by Radagast

If it is only ATTEMPT to corrupt memory, the main thread shouldn't be corrupted after the termination of the secondary thread afaik.

If there is at least one case when this is not true, then this whole statement is not true. And there is at least one case when this is not true, for instance when writing to an area of memory that is protected from write access - you might write some data and then reach the protected page/segment/area - the application did something that it shouldn't have and thus should be terminated.