| msg290504 - (view) |
Author: cmckain (cmckain) |
Date: 2017-03-26 03:53 |
| Almost every time I attempt to run my Django server ("python manage.py runserver") from PyCharm, python.exe crashes with the error "Unhandled exception at 0x7647BD9E (ucrtbase.dll) in python.exe: 0xC0000005: Access violation reading location 0x03BF8000." and "Process finished with exit code -1073741819 (0xC0000005)" is printed in the console. These errors only happen about 90% of the time. |
|
|
| msg290537 - (view) |
Author: Eryk Sun (eryksun) *  |
Date: 2017-03-26 16:08 |
| The offset in ucrtbase.dll where it's crashing may hint at the culprit. The following command should print the full event log for the most recent crash: wevtutil qe application /rd:true /c:1 /format:text /q:"*[System[Provider[@Name='Application Error']]][EventData[Data='python.exe'][Data='ucrtbase.dll']]" |
|
|
| msg290545 - (view) |
Author: cmckain (cmckain) |
Date: 2017-03-26 18:21 |
| C:\Users\cmcka\PycharmProjects\test>wevtutil qe application /rd:true /c:1 /format:text /q:"*[System[Provider[@Name='Application Error']]][EventData[Data='python.exe'][Data='ucrtbase.dll']]" Event[0]: Log Name: Application Source: Application Error Date: 2017-03-26T01:46:20.230 Event ID: 1000 Task: Application Crashing Events Level: Error Opcode: Info Keyword: Classic User: N/A User Name: N/A Computer: CAMERON-OMEN Description: Faulting application name: python.exe, version: 3.6.1150.1013, time stamp: 0x58d169bd Faulting module name: ucrtbase.dll, version: 10.0.14393.0, time stamp: 0x57898db2 Exception code: 0xc0000005 Fault offset: 0x0003bd9e Faulting process id: 0x4464 Faulting application start time: 0x01d2a60d6fdf23d2 Faulting application path: C:\Python36\python.exe Faulting module path: C:\windows\System32\ucrtbase.dll Report Id: 109058c0-4e02-4bb6-a799-d6a975fe0d6f Faulting package full name: Faulting package-relative application ID: This is from Python's faulthandler as well: Windows fatal exception: access violation Thread 0x000044b0 (most recent call first): File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\pydevd.py", line 96 in _on_run File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\pydevd_comm.py", line 291 in run File "C:\Python36\lib\threading.py", line 916 in _bootstrap_inner File "C:\Python36\lib\threading.py", line 884 in _bootstrap Thread 0x000044ac (most recent call first): File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\pydevd_comm.py", line 353 in _on_run File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\pydevd_comm.py", line 291 in run File "C:\Python36\lib\threading.py", line 916 in _bootstrap_inner File "C:\Python36\lib\threading.py", line 884 in _bootstrap Thread 0x000039d4 (most recent call first): File "C:\Python36\lib\threading.py", line 299 in wait File "C:\Python36\lib\queue.py", line 173 in get File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\pydevd_comm.py", line 430 in _on_run File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydevd_bundle\pydevd_comm.py", line 291 in run File "C:\Python36\lib\threading.py", line 916 in _bootstrap_inner File "C:\Python36\lib\threading.py", line 884 in _bootstrap Current thread 0x0000446c (most recent call first): File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydev_bundle\pydev_monkey.py", line 380 in new_spawnve File "C:\Python36\lib\site-packages\django\utils\autoreload.py", line 290 in restart_with_reloader File "C:\Python36\lib\site-packages\django\utils\autoreload.py", line 304 in python_reloader File "C:\Python36\lib\site-packages\django\utils\autoreload.py", line 333 in main File "C:\Python36\lib\site-packages\django\core\management\commands\runserver.py", line 106 in run File "C:\Python36\lib\site-packages\django\core\management\commands\runserver.py", line 97 in handle File "C:\Python36\lib\site-packages\django\core\management\base.py", line 345 in execute File "C:\Python36\lib\site-packages\django\core\management\commands\runserver.py", line 58 in execute File "C:\Python36\lib\site-packages\django\core\management\base.py", line 294 in run_from_argv File "C:\Python36\lib\site-packages\django\core\management\__init__.py", line 359 in execute File "C:\Python36\lib\site-packages\django\core\management\__init__.py", line 367 in execute_from_command_line File "C:/Users/cmcka/PycharmProjects/test/manage.py", line 22 in File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\_pydev_imps\_pydev_execfile.py", line 18 in execfile File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\pydevd.py", line 1015 in run File "C:\Users\cmcka\AppData\Local\JetBrains\Toolbox\apps\PyCharm-P\ch-0\171.3780.115\helpers\pydev\pydevd.py", line 1578 in Process finished with exit code -1073741819 (0xC0000005) |
|
|
| msg290553 - (view) |
Author: Steve Dower (steve.dower) *  |
Date: 2017-03-27 01:06 |
| Have you confirmed this occurring with 3.5? PyCharm has a very invasive debugger that is almost certainly responsible, but there's a significant difference between the 3.5 and 3.6 implementations that is probably relevant. |
|
|
| msg290562 - (view) |
Author: Eryk Sun (eryksun) * |
Date: 2017-03-27 04:41 |
| Steve, I added 3.5 because the crash involved ucrtbase.dll. I'll remove it for now since the problem is only confirmed in 3.6. Offset 0x3bd9e in 32-bit ucrtbase.dll is in wdupenv_s [1]. It's probably from calling new_spawnve in pydev_monkey.py, as shown in the faulthandler output. I don't use PyCharm, so I can't confirm this, but we know wdupenv_s is called by the CRT's wspawnve function. For example: >>> os.spawnve(os.P_WAIT, sys.executable, ['python', '-V'], os.environ) Breakpoint 0 hit eax=01b412b0 ebx=00000000 ecx=01b41280 edx=01b412b2 esi=01b41280 edi=00000000 eip=7672bd9e esp=013ef368 ebp=013ef380 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202 ucrtbase!wdupenv_s+0x18e: 7672bd9e 668b08 mov cx,word ptr [eax] ds:002b:01b412b0=0070 0:000> kc 7 ucrtbase!wdupenv_s ucrtbase!wsearchenv_s ucrtbase!wspawnlpe ucrtbase!wspawnlpe ucrtbase!wspawnve python36!os_spawnve_impl python36!os_spawnve [1]: https://msdn.microsoft.com/en-us/library/ms175774.aspx |
|
|
| msg290564 - (view) |
Author: cmckain (cmckain) |
Date: 2017-03-27 05:58 |
| The problem was fixed after updating to Django 1.11; apparently, Django 1.10 is not fully compatible with Python 3.6. Thanks for your time. |
|
|
| msg290611 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2017-03-27 13:57 |
| Do you have a reference to an issue from their side about this? Python should never crash due to pure Python code, so we'd like to be able to prevent this in the future. |
|
|
| msg290643 - (view) |
Author: cmckain (cmckain) |
Date: 2017-03-27 20:30 |
| No, my PyCharm issue has not been responded to by any of their people. Here is the link: https://youtrack.jetbrains.com/issue/PY-23297 Also, I have uploaded a screenshot of VS's debugging of the crash if it will be helpful. |
|
|
| msg290667 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2017-03-27 23:28 |
| I was thinking of a Django issue. It'd be nice to know what they fixed that prevents the problem occurring. |
|
|
| msg290676 - (view) |
Author: cmckain (cmckain) |
Date: 2017-03-28 02:01 |
| See this here: https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/18355615-ucrtbase-bug-wspawnve-is-broken |
|
|
| msg290692 - (view) |
Author: Eryk Sun (eryksun) * |
Date: 2017-03-28 10:00 |
| I can confirm that the CRT function construct_environment_block() does cause an access violation sometimes when no "=x:" shell variables are defined in the current environment. These "=x:" environment variables are the way that Windows emulates DOS per-drive working directories in a shell. The API itself never sets these variables; it only uses them if they're defined. You should be able to avoid this bug by defining the environment variable "=C:". The simplest way to do this in Python is via os.chdir. For example: import os cwd = os.getcwd() try: os.chdir('C:') finally: os.chdir(cwd) The implementation of os.chdir calls SetCurrentDirectoryW, which, for a drive-relative path such as "C:", will first look for an "=x:" environment variable and otherwise default to the root directory. After it changes the process current working directory, chdir() calls GetCurrentDirectoryW and SetEnvironmentVariableW to set the new value of the "=x:" variable. |
|
|
| msg290736 - (view) |
Author: Steve Dower (steve.dower) * |
Date: 2017-03-28 16:04 |
| Thanks for the link! I've reported it to the C Runtime team and they'll get it fixed. (Because this is an operating system component, the fix will come through normal Windows Updates and apply to any version of Python 3.5+, so I'd rather not build a workaround into the product for it.) |
|
|
