Callback routines registered to Quickwin (Fortran) windows cause a crash. I have been using these for years. There is normally a run time crash after compiling with the debug configuration but this goes away with the release configuration. With the latest Intel Compiler (Intel Parallel Studio XE Cluster edition 2020) and Visual Studio Community Edition 2019 the bug occurs with both debug and release configurations and the program is unusable.
iret=registermouseevent(HP_window, mouse$lbuttondown, move_vd_display)
10 ierr=waitonmouseevent(MOUSE$MOVE, keystate, impos, jmpos)
The crash occurs with this function, the error code says:
Unhandled exception at 0x00007FF822D1D125 (uxtheme.dll) in SpikeSorter.exe: 0xC000041D: An unhandled exception was encountered during a user callback.
A self-contained test case would help us help you. At first I wondered if you were mixing in STDCALL, but I see you are building 64-bit where that's not a thing.
Thanks for the quick response!
The compiler options are pretty much the default ones put in when you select the project type. I am also using OpenMP plus I am doing subclassing to get a toolbar so there is a place there where I might perhaps have an exception handler (not sure about that). However the problem with the debug configuration has been there since before I added OpenMP (and I think the subclassing).
This is the current command line for the compiler:
/nologo /O2 /extend_source:132 /Qopenmp /align:rec1byte /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc160.pdb" /libs:qwin /winapp /c
It is a large program. I could write a smaller one and see if it had the same problem and if so I could send you that.
QuickWin and OpenMP... hmmm... It would not astonish me at all if the QuickWin library wasn't thread-safe. I don't know that's the case - just a supposition. Given that Windows events can happen at any time, it doesn't even matter whether you make any QuickWin calls or do I/O in the parallel region.
For grins, what happens if you build with /Qopenmp-stubs ?
Thanks - no, I would imagine Quickwin is not threadsafe. But I have had a related problem from before the time I started to use OpenMP. The debug version would crash but not the release, so I could live with it. With the most recent compiler it is both.
I wrote a simple Quickwin program (below) to test it. I get the crash with this program using Visual Studio Community Edition 2020 V16.8.1 and the Intel compiler w_comp_lib_2020.4.311. I compiled and linked using the default options for a Quickwin project, except for extending the line width to 132. Both debug and release versions crash as soon as the mouse is moved after the left button click. I do not get the crash when running the same program using a slightly earlier (c. 2019) version of the compiler on a different computer
I am running on a Ryzen CPU but do not have any processor specific options selected.
Here is the code:
10 call sleepqq(100)
TYPE (qwinfo) winfo
TYPE (windowconfig) wc
TYPE (fontinfo) fnt
wc%numxpixels = npixw
wc%numypixels = npixh
wc%numtextcols = -1
wc%numtextrows = -1
wc%numcolors = -1
wc%extendfontname='Times New Roman'C
C wait before calling initializefonts or there will be a crash (?)
if (keystate.eq.1) then
I haven't tried removing any of the above bits to see if they are responsible but will continue to experiment.
Thanks for any suggestions!
Thanks for the example. The call to WaitOnMouseEvent is getting a floating point exception that is mishandled.
19.0.5 - Works
19.1.1 - Works
19.1.2 - Fails
It seems clear to me that it's a QuickWin library error. You should report this at the Intel Online Service Center.
Further to the above, which makes it look as if it is an issue with the newest compiler, I found an old QuickWin sample program, QWPaint, which uses callbacks in much the same way, and it runs without any obvious issues. So there must be something wrong with my code. It would be really nice to know what it was.
Thanks. I sent my previous comment before I saw your last. Perhaps it is a library error, though QWPaint uses the same two functions - registermouseevent and waitonmouseevent and it does not have a problem.
I have tried to find the appropriate Support center but can find no mention of Fortran anywhere - can you give some suggestions how to navigate to the right bit?
This is as close as I could get:
Click on the link I gave above.
I don't think it's specifically WaitOnMouseEvent, but we've gone as far as we can and it's now up to the Intel developers to figure out what's going wrong.
As an obscure test, what happens when you build this as a 32-bit app?
The loosely founded theory is that somewhere down the call stack, some place used INTEGER instead of HANDLE.
I tested this as 32-bit - failed. There is a floating point inexact exception that occurs, and the access violation occurs when that is attempted to be handled.
Thank you - I appreciate your taking time (I presume out of retirement) to help. I will uninstall the latest compiler and install one of the ones you said worked. I have never found Quickwin to be totally dependable - all previous versions I know of have had this same bug when using the debug compiler option. There have been other issues too in the past.
As for contacting Technical support to report the issue, it appears effectively impossible. I get stuck in an endless loop of trying to register for a support account, which appears to be different from this one, but it tells me my email address is already registered and then it sends me back to where I started when I try to log in again. I do not have time to continue this process - perhaps someone else will report the issue.
Case ID is 04881201. Curiously, I don't get the error in 64-bit from the command line, but I do in VS - different from what I saw in 32-bit:
Debug Assertion Failed!
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
Thank you for reporting the problem. It seems murky. I am not sure if I want to use the command line version of the compiler, though perhaps there are some advantages.
In case it helps anyone else, I uninstalled Visual Studio Community 2019, installed Visual Studio Community 2017 and then the Intel Compiler 19.0 (it says '2019 Initial Release' on the download site) and I can now use Quickwin again. There is still the usual problem with the debug compiler option (it comes up with an 'Abort, Try, Fail' type of error message which invariably then kicks you out of the program), but the release version behaves OK.
It would be nice to know what is going on and to have a fix that worked for all the compiler options.
Using VS 2017 I found that the problem (with the debug version) is caused by using the debug version of the Quickwin runtime libraries. So if /libs:qwin /dbglibs is used there is a problem but not if you omit the /dbglibs. Maybe that is not very surprising.
I don't know if the same applies to VS 2019, where there is a problem with both the release and debug options.
There isn't a debug version of the Qwin libraries - what you're getting is the debug version of the MSVC libraries. I still had an error when compiling without /dbglibs from the command line.
Intel has reproduced the problem and are investigating.