0

As a native Java developer, I think I have reached a situation which is what I am used to.

I am developing a multi-threaded Python 2.7 application using PyDev and running from Eclipse on Windows 7 64 bit. It is multi-threaded because it uses wxPython and so it uses the GUI main thread and heavy lifting threads (and my or my there is some heavy lifting) with one thread per callback.

I have reached a point where I get a popup 0xc00000fd error in python27.dll with an appcrash message. This occurs as a function in a thread returns a value. If I reduce the amount of data the callback is working with, the piece of code works fine so I am pretty sure that there is just too much stuff on the stack and there is no recursion gone bad anywhere.

I could call stack_size on the thread before creation to increase the space available to me and perhaps this could work for a time if I were to figure out how much space would satisfy it. The thread is going to have to do more not less work going forward so this seems like a band-aid situation.

I thought that Python created the stack using heap memory and so this should not be a problem in Python? Is it one of my many third party apis which is the real offender? So then without that low level memory creation decision making ability I would have in C, how do I get some of this off the stack and into heap memory?

demongolem
  • 9,474
  • 36
  • 90
  • 105
  • It's clearly rather abnormal for the interpreter to crash. Is there any way you could generate a low-level crash report, with stack traces (I mean the CPU stack, not the Python stack), register values, threads etc? – NPE Dec 19 '12 at 15:04
  • As a preliminary, going into visual studio 2010. I see the line multiarray.pyd!00000000052e13b3() over and over again. Perhaps Numpy or Numpy/Scipy interaction? The final line is python27.dll!000000001e0a0a36. I will try to delve deeper out of python and into registers and such. – demongolem Dec 19 '12 at 15:44
  • Looking at the modules list, there are 3 externals: scipy, sklearn and wx-2-8-msw-unicode (that is wxPython). The threads list has 7 threads listed. Thread ID 6284 with listed location 1e0a0077 is where it crashed . I am really thinking at this point the combination of Scipy (0.11.0), Numpy (1.6.2 MLK), and 64 bit Windows is what is doing me in. – demongolem Dec 19 '12 at 16:02

1 Answers1

6

Python should never crash out, as Guido said:

I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained.

So a crash is considered a bug with Python itself if it happens. This is highly unlikely, and it is most likely one of your extension modules is doing something bad, and taking Python with it.

My suggestion is strip out things until you find exactly what the problem is. If it happens with only core python stuff, then you need to submit a bug report, otherwise, it needs to go to the developers of whatever extension module is causing it.

Gareth Latty
  • 86,389
  • 17
  • 178
  • 183
  • This isn't quite true. Sometimes recursion can cause problems when e.g. pickling large objects. [This answer](http://stackoverflow.com/questions/20629027/process-finished-with-exit-code-1073741571) solved it for me. – simonzack May 14 '16 at 15:20