[issue17056] Support Visual Studio 2012

[Gili T.]

New submission from Gili T.:

msvc9compiler needs to check for the VS110COMNTOOLS environment variable in 
order to support Visual Studio 2012. Currently it complains "cannot find 
vcvarsall.bat".

The following workaround works for now:

SET VS90COMNTOOLS=%VS110COMNTOOLS%

--
components: Build
messages: 180808
nosy: cowwoc
priority: normal
severity: normal
status: open
title: Support Visual Studio 2012
type: enhancement
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue17056>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17058] Python crashes with error 0xc0000417

[Gili T.]

New submission from Gili T.:

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 (0xc417).
The thread 0x1bfc has exited with code -1073740777 (0xc417).
The thread 0x39c has exited with code -1073740777 (0xc417).
The thread 0x1fcc has exited with code -1073740777 (0xc417).
The program '[1260] python.exe' has exited with code -1073740777 (0xc417).

and crash. The stack-trace is:

>   msvcr90.dll!71059f64()  Unknown
msvcr90.dll!710551ec()  Unknown
msvcr90.dll!710552d4()  Unknown
msvcr90.dll!7104f335()  Unknown
python27.dll!1e0a89f9() Unknown
python27.dll!1e0a8c0e() Unknown
python27.dll!1e0a9379() Unknown
osutil.pyd!07fefc62176f()   Unknown
python27.dll!1e0c0966() Unknown
python27.dll!1e110484() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e10eba9() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e0b2553() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e099211() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e0e02be() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e10fc7b() Unknown
python27.dll!1e11052a() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e10eb38() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e10eb38() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e0b2553() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e099211() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e0e086e() Unknown
python27.dll!1e0dd5e6() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e10fc7b() Unknown
python27.dll!1e11052a() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e10eba9() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e0b2553() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e099211() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e0e086e() Unknown
python27.dll!1e0dd5e6() Unknown
python27.dll!1e08adf5() Unknown
python27.dll!1e10fc7b() Unknown
python27.dll!1e11052a() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e10eba9() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e115439() Unknown
python27.dll!1e10eba9() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e10eb38() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e10eb38() Unknown
python27.dll!1e110514() Unknown
python27.dll!1e113c34() Unknown
python27.dll!1e10eb38() Unknown
python27.

[issue17056] Support Visual Studio 2012

[Gili T.]

Gili T. added the comment:

Why? :)

I ask because all the application I depend upon only run against Python 2.x 
(Rhodecode, Mercurial, etc). I'd love for them to upgrade but it's not really 
in my control.

Has there been some sort of policy change within Python to stop supporting 2.x?

--

___
Python tracker 
<http://bugs.python.org/issue17056>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17058] Python crashes with error 0xc0000417

[Gili T.]

Gili T. added the comment:

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.

--

___
Python tracker 
<http://bugs.python.org/issue17058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17058] Python crashes with error 0xc0000417

[Gili T.]

Gili T. added the comment:

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?

--

___
Python tracker 
<http://bugs.python.org/issue17058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17058] Python crashes with error 0xc0000417

[Gili T.]

Gili T. added the comment:

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?

--

___
Python tracker 
<http://bugs.python.org/issue17058>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com