| 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\\documents\rhodecode" 4. "cd \users\\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) *  |
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) * |
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) * |
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) * |
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) * |
Date: 2013-01-28 07:01 |
| Maybe you should email python-dev. |
|
|