Since optimizing my python-ctypes-dll based geoprocessing tool, it seems to cancel itself a lot. Followed by arcmap reporting a pure virtual function call (which is odd, because you'd think any such bug would show up in ArcSOCP, right..?)
I'm currently working on the presumption that I've done something stupid in my DLL and have some good old C++ undefined behaviour going on. But if anyone has other suggestions as to why tools can cancel their own execution at runtime, I'm all ears.
I'm using the intel compiler, multithreading with openmp and the stlport standard library, for what it's worth.
Ok, so it turns out what is happening is this. Attaching a debugger (*) gives the following error (caught as a first chance exception):
"The application called an interface that was marshalled for a different thread."
So, I'm using callback functions in ctypes to call SetProgressor from the DLL, and it seems something somewhere complains that these get called by more than one thread (even though it wasn't happening concurrently). The execution thread then terminates and arcmap later thinks its cancelled, probably due to a timeout or something.
I've still not found an elegant solution to setting the progressor from inside an OMP parallel for loop, but at least the problem is identified.
(*) attaching the debugger was itself not all that easy. For some reason it works best to (1) load the project in visual studio; (2) run from arcmap; (3) go to task manager - not visual studio - to find the process (arcmap or arcsocp depending on fg/bg execution); (4) right click -> debug; (5) open the 'debug->threads' pane in visual studio to select the correct thread, of many.