Handling Unhandled Exceptions Gracefully

[amcelroy]

Hey guys,

 

I'm developing an OpenCL add-on for Labview and the one issue that is really causing grief are unhandled exceptions in OpenCL kernels.  It is really easy for the end user to write an OpenCL kernel that goes outside the bounds of the memory that was allocated in Labview.  Unfortunately, there isn't really a way to prevent the user from doing this except warning them in the manual.

 

Accessing memory outside of what is allocated by Labview causes an Unhandled Exception in which causes Labview to just quit.

 

I've tried all sorts of stuff in C/C++: try/catch, __try/__except, enabling SEH exception handling, and trying SetUnhandledExceptionFilter.  

 

Does anyone know any tricks that can prevent Labview crashing on an Unhandled Exception?  

 

The next option is to write everything in C# and try out the error handling there, but OpenCL doesn't have a verified C# implementation at this point.

 

Thanks,

Austin

[Aristos Queue]

Hey guys,

causes an Unhandled Exception

Exactly which exception is thrown? What code actually throws the unhandled exception? Is it OpenCL kernel throwing the unhandled exception? I suspect it is not, otherwise you'd be able to catch it.

 

There are two ways that the out-of-bounds-write exception could be generated:

1. The exception could be thrown by the kernel code that is bounds checking every memory write *before* that write occurs
   
2. The exception could be thrown by LabVIEW when it inspects the guard bytes around the allocation *after* that write occurs
   

I suspect it is *LabVIEW* that is throwing the unhandled exception because LabVIEW is detecting the overwrite *after* the write has already occurred. Since the overwrite has already occurred, there's nothing to except shutdown -- memory is at that point known to be corrupted. Safe execution is not possible after that. It is common for kernels to not do bounds checking because it can be a severe performance hit.

 

Basically, if this is what is happening, you're not going to be able to stop LV from shutting down because LV has already determined that it is not able to safely continue executing.

[amcelroy]

Hey Aristos,

 

The error the dreaded Access Violation exception.  Sometimes the VS2010 error handler points to Labview.exe, other times it is some memory address on the stack.  The chain of calls is Labview->My Library->OpenCL.  Either the problem is un-catchable in the OpenCL library or is exactly as you say: Labview is throwing the error.  Either way, the problem doesn't appear to be solvable.

 

I have a huge warning in the user manual and an FAQ on most common causes of this happening in OpenCL, hopefully the trade-off of using OpenCL is enough to overcome the development crashes.  Everything is stable (and VERY fast) as long as the kernel is legit.

 

Thanks for taking the time to give a good answer,

Austin