QT exec() command crash - c++

I´m developing an application in QT 4.7.3. This application is called from Matlab(simulink) using a mexFunction (*.mexw32)
When I try to open a dialog using dialog.exec() command, the form is displayed but I get a "non responding application" instantaneously. After that, matlab crashes.
If i try to open the dialog using dialog.show() command, it works fine.
I really have no idea of whats going on, since both commands are somehow similar, as described here
Does anyone know what is happening?

dialog.exec() spins a local event loop that doesn't integrate well with the one that Matlab itself is spinning. Thus the crash. Conversely, you're banking on Matlab doing the right thing as far as its own event loop being compatible with Qt's requirements goes. This doesn't hold on all platforms, unfortunately, although on Windows it seems to work.
You should never be using exec() outside of main anyway.

Related

Understanding and managing c++ program crash handling in windows

I have a c++ program compiled with MinGW which links to libmicrohttpd to run a webserver. It normally functions correctly, but I am trying to do some robustness testing and for my current test I have tried to disable the network interface. This results in the program crashing with the dialog box: "MyProgram.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Rather than debug the program and potentially its dependencies, for my purposes, it would be fine if it would just crash silently without making the dialog box (I have another component that is meant to restart it). Is this possible to do via some sort of manifest or Windows API call?
It turns out there is a Windows API function called SetErrorMode. Passing the parameter SEM_NOGPFAULTERRORBOX will prevent the error dialog from being displayed on a crash.
There is also the RegisterApplicationRestart function which can be used to have Windows restart an application in the event of a crash (or other configurable reasons).

Strange freezing cases of Qt GUI event loop on Windows

I try to ask here if somebody has encountered such a problem.
From time to time, I have a situation: I launch my Qt app on Windows (in debug mode, but I am not sure if it matters) via cmd.exe and then I work with it and then I stop working with it for some time. Then I return it to be focused and very rarely I experience this: the app is Not Responding even though I do not have any logic for it to react on being returned to be focused. Then I wait and wait and noting happens and then I press any key in my cmd.exe, and instead of being killed, my app suddenly wakes up and continues to work, and then I do not experience any problems anymore.
What can be the problem? On Linux I do not experience such a problem. I ask because I cannot trace the problem, as it happens not very often. Also, I am not very good acquainted with Windows. If it was Linux I would use gdp -p and try to see where the app hangs. But what can I do on Windows? Any advice on how to catch this?
UPDATE: I can press any key in my cmd.exe to unfreeze the program.
UPDATE:
It looks like it freezes on one of my debug-printfs:
STACK_TEXT:
: ntdll!NtWriteFile+0x14
: KERNELBASE!WriteFile+0x76
!write_text_ansi_nolock+0x183
!_write_nolock+0x451
!_write_internal+0x377
!__acrt_stdio_flush_nolock+0xc4
!__acrt_stdio_end_temporary_buffering_nolock+0x54
!__acrt_stdio_temporary_buffering_guard::~__acrt_stdio_temporary_buffering_guard+0x28
!<lambda_303760bc4008a2b3ec4768a30b06a80c>::operator()+0x104
!__crt_seh_guarded_call<int>::operator()<<lambda_d854c62834386a3b23916ad6dae2782d>,<lambda_303760bc4008a2b3ec4768a30b06a80c> &,<lambda_4780a7ea4f8cbd2590aec34bd14e2bbf> >+0x35
!__acrt_lock_stream_and_call<<lambda_303760bc4008a2b3ec4768a30b06a80c> >+0x58
!common_vfprintf<__crt_stdio_output::standard_base,char>+0x21a
!__stdio_common_vfprintf+0x5c
!_vfprintf_l+0x3f
!printf+0x58
! MyClass::myfunc -- that executes my handler of the button pressed (which freezes)
Why can be so? I mean it's just a printf writing to cmd.
Here is the answer to my question:
https://stackoverflow.com/a/33883532/4781940
I really have that Select Command Prompt title when the freeze happens.

Debugging a Win32 application c++

My application started life as a c++ Console application in VS2019. Code was provided as part of an SDK. Worked perfect. Great response from the manufacturer USB device. Later, I wanted to graduate is to a GUI application, much as I've been doing in VB and c#. Lo and behold, I managed to reconstruct the application in both Qt and Win32 but I'm running into a situation where the application becomes unresponsive and I have no way to tell what's going on.
In the Console application, I have to execute this code to interface with the device AFTER sending a "TakeMeasurement" command :
if (SDK_SUCCESSFUL(sdkError)) {
printf("\nWaiting for measurement to complete...\n");
while (!isMeasureWait) {
if (isDisConnect) break;
this_thread::sleep_for(chrono::milliseconds(1000));
}
}
This code works like a charm! Ater one or two iteration, the device has completed the measurement and I can get to the data easily.
On the Win32 side, I use the exact same code. Only, once control enters the loop, it never returns.
Any idea how I could diagnose the error? I have the impression that the "timing" is critical, between the exact moment where the Measurement command is initiated to the exact moment the instrument signals that it's done, and the data ready to be picked up.
My naive hypothesis is that, in debug mode on both 'platforms', I must be getting some timing differences? Sadly, I can't get more information from the manufacturer in this regard but I suspect I have a small window of time within which the instrument's response can be acted on? And I begin to suspect that, on Win32, that "time" is too long? Compared to on the Console side?
I was thinking of, perhaps, "measuring" that time, in milliseconds? First, on the Console side, to see what kind of delay "works", and then, to see how the delay compares with the Win32 side.
I may be wasting my time and I sure don't mean to waste yours.
How would I go about getting an idea of time elapsed in a c++ application? I'll take a look around VS2019, they have all kinds of "performance" things that popup at run time?
Any help is appreciated.
I am not sure I completely understand what is going on.
Execution of the thread wait loop was not not the culprit.
I'm not 100% sure but what happens is that, in my 'Export data to CSV TEXT file', if I tried to execute the call to :
SetWindowText(hEditMeasure, wMeasurements);
The application always hung. I placed breakpoints right before the call in the code, to trace execution, and it did not strike me at first but, in VS toolbar, there was a "thread" comboBox? With the value showing = DEVICE.DLL? and to its right, the name of my Export function as the Stackframe. In searching for additional information on the setWindowText function, I came accross the reference to use VM_SETTEXT to send to "different application"? Could it be unknowingly I was sending a message to "another thread", the DLL thread? And that's why it hung? I did not know enough to tell. So I started to move the setWindowText line around, ultimately inside the code that is called by the "Measure" button, and it worked!
I'm not out of the woods yet but I feel I'm making progress. Thank you all for your help and patience.

C++ application that uses Qt libraries stops working when screen saver starts

I have a C++ application that uses some Qt libraries.
The application works fine until the screen saver pops up and starts.
After that if I quit from screen saver the application crashes and I have to re-start it again. I have tested the application on Windows 7 and XP and this happens on both.
Is there anything I can change in the code so this does not happen?
Luca Carlon give you good and fairly popular advice -- use debugger. In your case, you can get a lot of information about debugging from official documentation.
When you run debug of your program, you must replay situation when your program falls: you must manually start screensaver, or hurry up screensaver to start.
When your program fails -- get back-trace, and try to understand, what was wrong.

Running a terminal via QT

I am a beginner is C++. I am trying to find, is it possible to run my program in both in QT window and Linux based. When the user logins into my system, the user can select GUI or terminal mode to run the system.
Thus, I would like to know is it possible to do it. If possible how can I proceed on? What command should I use to switch from a QT window to a terminal?
Do I need to create a separate set of project for both individually or using the same set of classes?
All Linux programs (unless explicitly disabled) print out text to a terminal. If you run the program in a graphical environment you will probably not run it from a console, therefore you won't see the output, but it will be still there.
If you want your program to be usable from a console, just test whether you could create the main window and if not, fallback to simple text output.
Note that the binary will still require the X server and Qt libraries to be installed.
You can construct your application with or without the GUI enabled through the QApplication constructor. Consult the example in Qt's documentation:
http://qt-project.org/doc/qt-4.8/qapplication.html#QApplication-2
Though, it should be noted that everything in Let_Me_Be's response is correct. In fact, the Qt example does exactly what he's suggesting. Please take the time to understand his answer before you plunge into coding.