PDA

View Full Version : PC reboot, could it be one of the QMutex undefined behaviour ?



yellowmat
10th October 2006, 15:43
Hello every body,

Before posting my post here, I have searched a reasonable answer on windows XP forum, without any results so that's why I am now focusing on my application.

As I said in my post title, does a PC reboot could be one of the multiple undefined behaviour of QMutex use ?

I ask the question because I have an application wich has a HMI object, before and after each use of this object I use a QMutex that I lock and unlock. I use mutex to protect my HMI object because multiple threads can access it.

Do you think it could be the reason why my PC reboot ?

Thanks in advance.

high_flyer
10th October 2006, 15:52
Hmm... all thought this is possible, it should not be.
That is to say, it is not likely that your program reboots the PC through a curropt call, since user space programs have no access to system space calls.
But with windows, every thing is possible...
Did you try to run the program on another PC/system?

yellowmat
10th October 2006, 16:08
The program is currently in use on a debug PC with another SYSTEM without any bug ... as the PC and SYSTEM are diffent, it is not possible to say that one or the other is the source of the problem.

In fact my program run on an embedded PC since a few month without any bug. My problem is that I made some changes on the source code of the program a few weeks ago (using QMutex to protect my HMI object access), something very trivial I think, so trivial that I am (quite :rolleyes: ) sure that is not my fault. In my opinion, the source of the problem does not come from my program but I prefer being sure before lookin for the other possible sources I am thinking of.

high_flyer
12th October 2006, 22:48
I could not quite aunderstand if the "new" version of your program, the one with the changes you inserted with the mutex, runs on both systems, or is it that the version with the changes only runs on one system.
You should try to run the "problematic" version on more than one system and see how it behaves.
If it only has problem on one system/configuration then it is more likely the problem is the system (but ofcourse, not 100%), but if the problem is the same on other systems as well, then it is likely that the porblem is your program.
NEVER asume that threads are trivial!!
Small changes in mulithreaded programs can introduce "hidden" problems very easely.