Labview Access Violation Handling

[amcelroy]

Howdy folks,

I've a bit of a complex question, so stay with me.  I'm writing an OpenCL add-on for Labview and am running into a tough issue.   

If the user writes a function that accidentally accesses memory outside of what is defined in either Labview or OpenCL, the OpenCL.dll throws an Access Violation.  In C/C++ this causes a program to halt so the issue can be fixed.  

In Labview, an Access Violation causes Labview to shutdown.  Is there ANY way to alter this behavior in Labview to throw an error instead of just shutdown?  I've got everything else worked out, but this is going to cause a lot of angst with the user.

I've tried to add Try/Catch in my DLL that Labview calls, but the error isn't happening in my DLL, but the OpenCL.dll, so Try/Catch doesn't work.

Thanks for any advice,

Austin

[Thomas-B]

Hi Austin, 

I have a few questions. 

1) Is LabVIEW creating a crash report whenever it shuts down? If so, could you please sent it to me? This link discusses where and how to access it if it exists. 

2)  I want to make sure I understand your approach. Are you are calling the .DLL you wrote using LabVIEW, and then your DLL is accessing the OpenCL.dll?

3)  Have you been able to verify that your DLL is able to catch the error being created in the OpenCL.dll?

4)  Do you know if the Call Library Function Node in LabVIEW is receiving the error from OpenCL, or is not making back up to LabVIEW?

I look forward to hearing from you soon.

[amcelroy]

Hey Thomas,

Thanks for responding, this is the last hurdle to overcome before releasing.

1.) Labview doesn't pop up with an Investigate Internal error window.  Every once in a while the Recovery feature will appear, but it doesn't seem to want to today.  There is no file in the folder that indicates a crash report or log file.

2.) That is correct, Labview -> My Dll -> OpenCL.dll 

3.) My DLL is NOT catching the error from OpenCL.dll for this problem.  I've tried to do a try / catch in my DLL for this problem, but the debugger just kicks back an Access Violation (sometimes from labview.exe, but not always) and the only option is to break.

4.) It isn't making it back into Labview.  My DLL has other places where I do try / catches and am able to handle violations like NULL values and pass the proper code back into Labview and a custom error handler, so it is very doable.  Interestingly, this error only seems to be happening on the Intel devices.  Both the AMD and NVIDIA cards seem to execute the bad code without crashing Labview, the timing results and output data is gibberish, but at least it doesn't crash 🙂

Hopefull the benefits of OpenCL offset the hassle of accidental access violations.  When a kernel is baked and debugged, the results are stable (and very fast).  The user manual has a huge warning that this crashing will probably happen and an FAQ to address common reasons why an OpenCL kernel would have this problem.

Thanks for you input on this,

Austin McElroy

[rolfk]

Your understanding about exception handling seems a little bit limited. The program may be halted in a normal C development environment but something like an access violation is not something that can usually be worked around during the program flow and then simply have the program resume. You usually have to do some edits to the source code and recompile/restart everything. This can be typically done in a standard IDE since the debugee is not executed inside the IDE process but as an external process.

LabVIEW works differently since there is only the LabVIEW process itself and the compiled VI code is executed inside that process. So if your program code crashes this crashes LabVIEW itself, not the external process your IDE connected to.

LabVIEW itself is not able to recover from an AcessViolation on it's own as it has absolutely no idea about what caused that violation and even less, about how to recover from it. If you want to access C functions and have exceptions catched and acted upon you will have to do this all yourself, by installing a Windows exception handler and perferming whatever recovery operation you think should be handled. But just ignoring access violations certainly will not work. But read this about handling HW exception types. Basically trying to handle HW (CPU) generated exceptions is a rather unreliable and bad form.

As to accessing external code from within LabVIEW you rather should make sure that your interface library catches every possible invalid parameter BEFORE passing it to the external code, rather than trying to catch the exception that is thrown. This is simply because recovering from serious errors is only possible if you know exactly what was done and how to undo it to continue. But doing that in a generic manner is really not an option.

[amcelroy]

Hey Rolf,

I agree about catching errors before they occur, but in this case, it is almost impossible to catch bad kernel code before it is executed.  The OpenCL stuff is compiled at runtime from an external or internal string or file and I would need to add a massive amount of kernel error checking which isn't really feasible at this point (for me anyway).  It is possible to catch these exceptions using try / catch and __try / __except at runtime and handle them gracefully.  This is one place where the OpenCL.dll and my dll are in seperate threads (try / catch doesn't work on seperate threads) or that the exception is happening in Labview (also another thread) and won't work there either.

The other code sanitizes inputs and limits the damage users can do, this is just one case where a user can easily get outside outside the bounds of managed memory.  There appears to be some ways of catching exceptions in other threads in C#, but this would require a substantial re-write.

Ideally I could inform the user with a Windows form pop-up that says what is going on in why instead of just a complete shut-down of Labview, but none of the Windows based C++ functions are able to supercede Labviews error handler.

Austin

[rolfk]

Well, there are actually two possible ways of exception handling under Windows. One is the standrad try/catch that you only get in C++ and the other is a "simple" WinAPI error handling similar to the standard signals interface in Posix. You do this normally with the SetUnhandledExceptionFilter() API. This should insert your handler in the exception handler chain above any exception handler that the top level application or any intermediate code parts have inserted, so that you have a chance on acting on it first. It probably is still a good idea to not eat up the exception but pass it up anyways, since an Access Violation is serious business, and you could be in fact already lucky if you're able to display a user dialog box without crashing again in there.

Most likely the WinAPI exception handling and the SEH from your Visual C environment can't seemlessly interact with each other and that could also depend on the Visual Studio version. That part of the C runtime library is supposedly rather difficult and also not part of the C runtime source code that you get when installing the Visual C compiler. Partly because the SEH is rather patent encumbered, and partly maybe because that code could be very hairy.

I never used the latter and only very few times the first, so I can't really tell you in detail how they go, but it is a t least a pointer.

[amcelroy]

Hey Rolf,

Yeah, I tried SetUnhandledExceptionFilter() a couple of days ago and the access violation exception would never enter the exception handling code. I tried setting the error handler when the DLL was created and right before the line of code that caused the unhandled exception and neither would work.  

Interesting thought about SEH butting heads with the Windows exception handling, I can try compiling without the SEH exceptions and see if exceptions trigger the code in the custom error handling filter.

Another question in all of this is, "Can Labview handle exceptions from external code in a more graceful maner?"  Runtime exceptions are a serious business, but they can be caught and that info relayed back to the user.  Labview just crashes...

That said, I'm very grateful that NI allows native code to be executed as seamlessly as possible.

Austin

[rolfk]

Normally LabVIEW does handle exceptions by displaying a dialog box informing the user about the fact and suggesting to please shut down. Not sure if it makes an exception about access violations, which I would consider a valid aproach.

Also you need to make sure to not set the Debug level in the Call Library Node configuration to None. This will disable all special exception handling around the Call Library Node and invoke the standard Windows exception handler, which depending on the exception and if it is thrown inside kernel context or not, either will cause a crash dump or simply terminate the process silently.