Tell me more ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.
up vote 3 down vote favorite

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.

share|improve this question
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. – Howard Butler Oct 5 '11 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! – Sideshow Bob Oct 5 '11 at 13:56
@SideshowBob I'm not familiar with the 4 hour feature ... what's it saying? – Kirk Kuykendall Oct 5 '11 at 14:52
@KirkKuykendall and Sideshow Bob meta.gis.stackexchange.com/questions/630/… – matt wilkie♦ Oct 5 '11 at 17:19
Wow a whole thread about me, I'm honoured. – Sideshow Bob Oct 6 '11 at 10:03

1 Answer

up vote 3 down vote accepted

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.

share|improve this answer
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 '11 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/… – Sideshow Bob Oct 7 '11 at 10:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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