classification
Title: Python crashes with error 0xc0000417
Type: crash Stage: resolved
Components: Windows Versions: Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: brian.curtin, cowwoc, r.david.murray
Priority: normal Keywords:

Created on 2013-01-28 01:00 by cowwoc, last changed 2013-01-28 07:01 by brian.curtin. This issue is now closed.

Messages (9)
msg180816 - (view) Author: Gili T. (cowwoc) Date: 2013-01-28 01:00
Python keeps on crashing with error:

The following repro steps are a slight variation of http://packages.python.org/RhodeCode/setup.html.

My installation environment is Windows 7, 64-bit, Visual Studio 2012. I doubt the bug is specific to this environment but I'm providing it as a point of reference. This issue is 100% reproducible for me:

1. Install Python 2.7.3, 64-bit
2. Download https://raw.github.com/pypa/virtualenv/master/virtualenv.py
3. From a VS2012 64-bit command-prompt, run "python virtualenv c:\users\<name>\documents\rhodecode"
4. "cd \users\<name>\documents\rhodecode"
5. "scripts\activate"
6. "pip install rhodecode"
7. "paster make-config RhodeCode production.ini"
8. "paster setup-rhodecode production.ini"
9. You need to point at a directory that contains at least one Mercurial repository.

Code will output:
  [...]
  2013-01-27 19:51:05,855 INFO sqlalchemy.engine.base.Engine ()
  2013-01-27 19:51:05.861 INFO  [rhodecode.model.scm] scanning for repositories in
   C:\Users\Gili\Documents\MercurialRepositories

The thread 0x3b4 has exited with code -1073740777 (0xc0000417).
The thread 0x1bfc has exited with code -1073740777 (0xc0000417).
The thread 0x39c has exited with code -1073740777 (0xc0000417).
The thread 0x1fcc has exited with code -1073740777 (0xc0000417).
The program '[1260] python.exe' has exited with code -1073740777 (0xc0000417).

and crash. The stack-trace is:

>	msvcr90.dll!0000000071059f64()	Unknown
 	msvcr90.dll!00000000710551ec()	Unknown
 	msvcr90.dll!00000000710552d4()	Unknown
 	msvcr90.dll!000000007104f335()	Unknown
 	python27.dll!000000001e0a89f9()	Unknown
 	python27.dll!000000001e0a8c0e()	Unknown
 	python27.dll!000000001e0a9379()	Unknown
 	osutil.pyd!000007fefc62176f()	Unknown
 	python27.dll!000000001e0c0966()	Unknown
 	python27.dll!000000001e110484()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e0b2553()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e099211()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e0e02be()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e10fc7b()	Unknown
 	python27.dll!000000001e11052a()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e0b2553()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e099211()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e0e086e()	Unknown
 	python27.dll!000000001e0dd5e6()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e10fc7b()	Unknown
 	python27.dll!000000001e11052a()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e0b2553()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e099211()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e0e086e()	Unknown
 	python27.dll!000000001e0dd5e6()	Unknown
 	python27.dll!000000001e08adf5()	Unknown
 	python27.dll!000000001e10fc7b()	Unknown
 	python27.dll!000000001e11052a()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e10eb38()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e10eba9()	Unknown
 	python27.dll!000000001e110514()	Unknown
 	python27.dll!000000001e113c34()	Unknown
 	python27.dll!000000001e115439()	Unknown
 	python27.dll!000000001e1154d9()	Unknown
 	python27.dll!000000001e14166a()	Unknown
 	python27.dll!000000001e14295a()	Unknown
 	python27.dll!000000001e142f9a()	Unknown
 	python27.dll!000000001e1439c3()	Unknown
 	python27.dll!000000001e0443c0()	Unknown
 	python.exe!000000001d00119e()	Unknown
 	kernel32.dll!000000007746652d()	Unknown
 	ntdll.dll!0000000077a5c521()	Unknown

There is no known workaround.
msg180823 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-28 03:16
Is VS2012 actually involved in anything here?  Does something get compiled when you install rhodecode?

Since it is a third party package, it may be that no one here will volunteer to reproduce this (though it is possible).  If you can isolate the failure more, that would be a big help.
msg180827 - (view) Author: Gili T. (cowwoc) Date: 2013-01-28 05:55
Yes, Visual Studio 2012 is used when installing Rhodecode. I'd love to isolate this further but I don't know anything about Python. I'm just an end-user of Rhodecode.

I filed a bug report with the Rhodecode author (asking for help) but I think we can both agree this is actually a Python bug (python.exe is the one crashing).

I try to reproduce this with Visual Studio 2010 if you are more comfortable with that environment.
msg180829 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2013-01-28 06:06
You need to compile rhodecode with VS2008 to match Python 2.7.

You'd have this same problem mixing runtimes regardless of rhodecode or Python being involved.
msg180830 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2013-01-28 06:22
A more correct way to say my last message is that you'd need to have Python and rhodecode linked to the same runtime, by compiling with the same Visual Studio.

If you require VS2012 with Python 2.7, you'll need to port Python on your own and then your setup would work. We can't accept your patch on #17056, so you'd have to do the work to make 2.7 work with 2012 and maintain the patch yourself.
msg180831 - (view) Author: Gili T. (cowwoc) Date: 2013-01-28 06:33
Hey Brian,

I'm curious why mixing different versions of Visual Studio runtimes would  result in a problem. I thought you can mix different runtimes so long as:

1. You link against a DLL (as opposed to static linking).
2. You use the same kind of library (debug vs release, 32-bit vs 64-bit).

Meaning, if one project links against a 64-bit Release DLL from 2008 I expect it to interoperate fine with a 64-bit Release DLL from 2010. The DLL is supposed to be backwards compatible, is it not?
msg180832 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2013-01-28 06:39
Passing CRT objects (like a file handle) across runtime boundaries results in unexpected behavior, which is probably what's happening here.

In the past people have mentioned porting 2.7 to VS2010 which would encounter the same issues you're seeing here. Here's a link to that discussion: http://mail.python.org/pipermail/python-dev/2012-August/121406.html
msg180833 - (view) Author: Gili T. (cowwoc) Date: 2013-01-28 06:53
I read http://mail.python.org/pipermail/python-dev/2012-August/121460.html and I believe they are wrong.

I have personally run into these problems (each library maintaining its own CRT with separate heaps, file handles, etc) when static linking was used, but when dynamic linking is used there is only one CRT instance and therefore you only end up with one heap, set of file handles, etc. I've never seen the kind of problems you're referring to if dynamic linking is used.

My guess is that someone (Python or an extension) is using static linking which is causing these problems. Is that a reasonable assumption?
msg180834 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2013-01-28 07:01
Maybe you should email python-dev.
History
Date User Action Args
2013-01-28 07:01:45brian.curtinsetmessages: + msg180834
2013-01-28 06:53:47cowwocsetmessages: + msg180833
2013-01-28 06:39:29brian.curtinsetmessages: + msg180832
2013-01-28 06:33:06cowwocsetmessages: + msg180831
2013-01-28 06:22:59brian.curtinsetmessages: + msg180830
2013-01-28 06:18:55brian.curtinsetstatus: open -> closed
resolution: not a bug
stage: resolved
2013-01-28 06:06:33brian.curtinsetnosy: + brian.curtin
messages: + msg180829
2013-01-28 05:55:24cowwocsetmessages: + msg180827
2013-01-28 03:16:35r.david.murraysetnosy: + r.david.murray
messages: + msg180823
2013-01-28 01:00:14cowwoccreate