Issue29908
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2017-03-26 03:53 by cmckain, last changed 2022-04-11 14:58 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
Desctop screenshot.png | cmckain, 2017-03-27 20:30 | VS debugging of crash |
Messages (12) | |||
---|---|---|---|
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 <module> 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 <module> 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.) |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:58:44 | admin | set | github: 74094 |
2017-03-28 16:04:17 | steve.dower | set | messages: + msg290736 |
2017-03-28 10:00:30 | eryksun | set | messages: + msg290692 |
2017-03-28 02:01:49 | cmckain | set | messages: + msg290676 |
2017-03-27 23:28:06 | steve.dower | set | messages: + msg290667 |
2017-03-27 20:30:45 | cmckain | set | files:
+ Desctop screenshot.png messages: + msg290643 |
2017-03-27 13:57:28 | steve.dower | set | messages: + msg290611 |
2017-03-27 05:58:06 | cmckain | set | status: open -> closed resolution: out of date messages: + msg290564 stage: resolved |
2017-03-27 04:41:18 | eryksun | set | messages:
+ msg290562 versions: - Python 3.5 |
2017-03-27 01:06:51 | steve.dower | set | messages: + msg290553 |
2017-03-26 18:21:13 | cmckain | set | messages: + msg290545 |
2017-03-26 16:08:42 | eryksun | set | versions:
+ Python 3.5, Python 3.6, Python 3.7 nosy: + paul.moore, tim.golden, eryksun, zach.ware, steve.dower messages: + msg290537 components: + Windows |
2017-03-26 04:15:43 | cmckain | set | type: crash |
2017-03-26 03:53:33 | cmckain | create |