Resolving the "unhandled exception in app.exe (qtguid4.dll): 0xc0000005: access violation" error

Cause:

A few days ago, a feature was added without a stable version, and the program often crashed relentlessly.

Symptom:

When debugging crashes, the system prompts "unhandled exception in app.exe (qtguid4.dll): 0xc0000005: access violation", which will be transferred to the setenabled location of the label;

After shielding the relevant code, run it again and jump to the setpalette of the button;

After shielding the relevant code, run it again and tune it to the settext of the label;

After shielding the relevant code, run it again and jump to the at (I) position of a vector variable.

After blocking, you can.

Release crashes unfixed. The log reports common debug information:

Warning: QT has caught an exception thrown from an event handler.

Throwing exceptions from an event handler is not supported in QT.

You must reimplement qapplication: Policy () and catch all exception there.

Reproduction:

Often, although the time is not fixed, it is easy to repeat (not to reproduce ).

Debugging:

If you use try () catch (...) to block the problematic code, the debugging will crash to the QT kernel.

I want to find it on the Internet. The error is not obvious, and the network speed is slow, so I have to worry about it myself.

Thoughts:

If you want to go, there may be a few things that will cause the crash:

1. Improper pointers are used, leading to messy system variables. However, it is unlikely that a variable can be set in disorder, so it will not be a, B, c, or D.

2. The system uses the qtimer timer, but uses a long delay. It may impede the action of the main thread or serial thread, and impede the overflow of the data buffer zone of the main thread parsing serial port, resulting in a crash.

3. The system results must be regularly saved to a local Excel file. It may be that the Excel module has some serious problems, which may cause the system to crash randomly after a long time.

4. What software has been installed or uninstalled by others may cause changes in the operating system environment, affect the debugging and running environment, and eventually cause a crash.

5. Or the QT environment is unstable. Think about it, too. After all, it has been more than a decade, and the general application should be okay. If there is a problem, congratulations.

Roll back to a stable version:

What is the difference between a stable version and the current version:

1. the latency is 200 ms, and the current latency is 4000 Ms.

2. added the average value output function and introduced the average value data storage variable (array ).

3. The original 20*1 button and 20*4 labels are expanded to 30*1 button and 30*4 labels.

Gradually add features:

1. The average value output function is added, which is normal. It does not appear to be caused by the introduction of new variables.

2. added the interface button, which is normal;

3. Increase latency and crash.

Finally found the problem:

It turns out that the delay is too long, causing a crash.

Loop in the qtime timer used in the main thread causes program thread congestion:

Void cdelaytimer: delaytime (unsigned long ndelaytime) // MS
{
Qtime time;
Time. Start ();
While (time. elapsed () <ndelaytime)
{
// Empty statement, delay effect
}
}

According to the QT Chinese manual7-3Response when the system is busy (Staying responsive during intensive processing:

Void cdelaytimer: delaytime (unsigned long ndelaytime) // MS
{
Qtime time;
Time. Start ();
While (time. elapsed () <ndelaytime)
{
// Empty statement, delay effect
Qapplication: processevents ();
}
}

Conclusion:

In fact, I personally feel that this is not the reason, or it may be that a variable is written simultaneously in the timer and main thread, causing a variable write violation, which causes this problem.

However, no corresponding location is found yet.

Thoughts:

1. knowledge points for taking care of other events during a delay:

Qapplication: processevents ();
2. Define and introduce a variable in a multi-threaded program. Consider the scope of the variable and hold the principle of "no definition, no definition, no definition.

I personally feel that if a variable is frequently modified, we should actively consider whether it will cause conflicts and minimize maintenance costs.

3. build an environment that can be debugged and track it step by step.

In my situation, debugging can be performed on the development machine, but cannot be performed on the production machine.

Debugging fails when the qwidget font style and variable content are overwritten.

Legacy problems:

1. The production machine cannot be debugged. I still don't know why.

2. The root cause remains unclear and is currently available, but further research is required.