- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
e.g.
iret=registermouseevent(HP_window, mouse$lbuttondown, move_vd_display)
followed by
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
program quickwin_test
integer*4 npixw,npixh
npixw=600
npixh=400
call init_window(npixw,npixh)
10 call sleepqq(100)
goto 10
stop
end
subroutine init_window(npixw,npixh)
USE IFQWIN
USE IFWIN
logical*4 status
integer*4 npixw,npixh,HP_window
TYPE (qwinfo) winfo
TYPE (windowconfig) wc
TYPE (fontinfo) fnt
parameter (HP_window=30)
INTERFACE
subroutine move_display(n_window,mouseevent,keystate,MouseXpos,MouseYpos)
integer*4 n_window,mouseevent,keystate,MouseXpos,MouseYpos
end subroutine
END INTERFACE
open(HP_window,file='user',title=' ')
wc%numxpixels = npixw
wc%numypixels = npixh
wc%numtextcols = -1
wc%numtextrows = -1
wc%numcolors = -1
wc%fontsize=#0008000C
wc%title='Test window'C
wc%bitsperpixel=-1
wc%numvideopages=-1
wc%mode=-1
wc%extendfontname='Times New Roman'C
wc%extendfontsize=-1
wc%extendfontattributes=-1
status=SETWINDOWCONFIG(wc)
C wait before calling initializefonts or there will be a crash (?)
call sleepqq(50)
i4=initializefonts()
i2=focusqq(HP_window)
i2=displaycursor($GCURSOROFF)
i2=setfont('t''Courier''h12w8f')
ir=registermouseevent(HP_window,mouse$lbuttondown,move_display)
winfo%h=npixh
winfo%w=npixw
winfo%x=5
winfo%y=5
winfo%type=QWIN$SET
ir=setwsizeqq(HP_window,winfo)
i4=setbkcolorrgb(#FFFFFF)
call clearscreen($GCLEARSCREEN)
return
end
subroutine move_display(n_window,mouseevent,keystate,MouseXpos,MouseYpos)
USE IFQWIN
integer*4 n_window,mouseevent,keystate,MouseXpos,MouseYpos
impos_last=MouseXpos
jmpos_last=MouseYpos
10 ierr=waitonmouseevent(MOUSE$MOVE,keystate,impos,jmpos)
if (keystate.eq.1) then
idx=impos-impos_last
idy=jmpos-jmpos_last
impos_last=impos
jmpos_last=jmpos
goto 10
endif
return
end
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!
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
https://www.intel.com/content/www/us/en/support/products/67709/software.html#67017
Thanks,
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Best wishes,
Nick Swindale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Program: C:\Users\Steve\source\repos\QWin1\x64\Debug\QWin1.exe
File: minkernel\crts\ucrt\src\appcrt\tran\amd64\ieee.c
Line: 106Expression: (mask&~(_MCW_DN|_MCW_EM|_MCW_RC))==0
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Thanks again,
Nick Swindale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compiler is the same, but a VS project applies some non-default options that may be relevant. I didn't try to narrow these down.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. I look forward to finding out more.
On the topic of Quickwin bugs I might mention a problem with the inbuilt menu routines WINSELECTTEXT and WINCOPY. Using these in the past (and again when reinstated today) I get an error message that says 'Internal error - unexpected error file 'qwgwnd.c' line 3628'. This does not throw you out of the program but is annoying (I have since written my own copy and paste routines to avoid using the Quickwin ones). In the past there were also random 'Unresolved contention for resource' errors, when starting a program though I haven't had those for some time now.
Nick
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The problem reported in the initial post has been fixed in the 2021.2 release. If you encounter other issues, please start a new thread for them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
Nick
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page