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.

  • This question has way too many unknown things going on to be answerable right now. Boil your problem down to Python -> ctypes -> your.dll for starters and take Arc* out of the mix. Oct 5, 2011 at 13:27
  • Already done that, and it works just fine outside of arcmap. Actually, thanks for your help but I have an answer now. Alas stackexchange won't let me post it for another 4 hours! Oct 5, 2011 at 13:56
  • @SideshowBob I'm not familiar with the 4 hour feature ... what's it saying? Oct 5, 2011 at 14:52
  • @KirkKuykendall and Sideshow Bob meta.gis.stackexchange.com/questions/630/… Oct 5, 2011 at 17:19
  • Wow a whole thread about me, I'm honoured. Oct 6, 2011 at 10:03

1 Answer 1


Ok, thanks for your concern on the self answering everyone. I would now like to answer my own question, so anyone with a similar problem might get put on the right track.

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 arcpy.SetProgressor from the DLL, and something (ArcMap?) complains that these get called by more than one thread (even though it wasn't happening concurrently - I was using critical sections to ensure that). Possibly it would complain if called by any thread other than ArcSOCP - the one that loaded my dll in the first place - i.e. the master thread within the dll.

I think the dll code terminates at that point, but arcmap doesn't respond until a while later when it suddenly shows the geoprocessing task as cancelled. Maybe due to some timeout, or maybe it cancelled straight away but took its time cancelling (anyone who has tried to cancel gp operations mid-flow will know what I mean!).

Ensuring that SetProgressor is only called from the DLL's master thread fixes the problem.

(*) attaching the debugger for some reason, didn't work the way I'd normally do it, from 'attach process' in visual studio. For some reason it worked 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.

  • If you resolve the callback functions issue please let us know! Otherwise ask another question, I'm interested in seeing how it is resolved as well.
    – blah238
    Oct 6, 2011 at 19:59
  • 1
    Callbacks now called only from the master thread, and it works. Oddly you can't use the #pragma omp master directive for this, have to check manually -- stackoverflow.com/questions/7661114/… Oct 7, 2011 at 10:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.