New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
python.exe crashes or hangs on help() modules when bad modules found #54269
Comments
2010-10-10 python.exe crashes or hangs on help() modules ####################################################################### The python.exe command line interpreter crashes or hangs when Python 2.7 WinXP SP3 see version details in OUTPUT sections # ----------------------- The workaround is simply remove the corrupt package. # ----------------------- Python command line interperter doesn't gracefully exit the When entering python.exe, idle.exe or pycrust.bat (runs pycrust.py),
In my case you will note the problem occurs on my install of the I installed a new version pythonwin just after installing Python 2.7. However, having a corrupt installed package shouldn't crash python. pythonwin version: pywin32 build214 # -----------------------
However, I went directly to the folder holding python.exe # ----------------------- # ----------------------- ####################################################################### Q:\Projects\Python27>python.exe
Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> help() Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out Enter the name of any module, keyword, or topic to get help on writing To get a list of available modules, keywords, or topics, type "modules", help> modules Please wait a moment while I gather a list of all available modules... AutoComplete _threading_local itertools sspi Enter any module name to get more help. Or, type "modules spam" to search Q:\Projects\Python27> #---------------------------------------------------------------------- ####################################################################### Python 2.7 (r27:82525, Jul 4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out Enter the name of any module, keyword, or topic to get help on writing To get a list of available modules, keywords, or topics, type "modules", help> modules Please wait a moment while I gather a list of all available modules... AutoComplete _threading_local itertools sspi Enter any module name to get more help. Or, type "modules spam" to search Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
help()
File "Q:\Python27\lib\site.py", line 453, in __call__
return pydoc.help(*args, **kwds)
File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
self.interact()
File "Q:\Python27\lib\pydoc.py", line 1735, in interact
request = self.getline('help> ')
File "Q:\Python27\lib\pydoc.py", line 1746, in getline
return raw_input(prompt)
File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
ret=dialog.GetSimpleInput(prompt)
File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist
>>> #---------------------------------------------------------------------- ####################################################################### PyCrust 0.9.8 - The Flakiest Python Shell Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out Enter the name of any module, keyword, or topic to get help on writing To get a list of available modules, keywords, or topics, type "modules", help> modules Please wait a moment while I gather a list of all available modules... AutoComplete _threading_local itertools sspi Enter any module name to get more help. Or, type "modules spam" to search Traceback (most recent call last):
File "<input>", line 1, in <module>
File "Q:\Python27\lib\site.py", line 453, in __call__
return pydoc.help(*args, **kwds)
File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
self.interact()
File "Q:\Python27\lib\pydoc.py", line 1735, in interact
request = self.getline('help> ')
File "Q:\Python27\lib\pydoc.py", line 1746, in getline
return raw_input(prompt)
File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
ret=dialog.GetSimpleInput(prompt)
File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist #---------------------------------------------------------------------- ####################################################################### |
There isn't much that Python can do if there is a sufficiently broken C-based module in sys.path. All you report about the problematic module is that it is 'bad' or 'corrupt'. Can you give more information about what makes it bad? |
I believe that a 3rd party package is corrupt. Whether it is or not I don't know. However whether or not a package is corrupt or not is not what I am reporting as a bug. I am reporting that python.exe crashes when I do help() modules. In GUI wrappers around python.exe, such as idle and pycrust, I get more information to the problem then when just in python.exe command line interpreter. As per the first post the errors I get in pycrust and idle are: To be honest the meaning of these errors is beyond my expertise, or lack of thereof. I attempted to give as much info on what I experienced with running python.exe help() modules as I saw. If there is a direction you can point me to that I can gather more information then what I've already given, I'll give that a go as well. Other pointers to reported problems of a similar nature: Again this is not a report of a corrupt package. It is a report of python.exe crashing using commands considered part of Python.exe; that being help() then modules. An external library may be the cause or may not. But if it is an external library that is corrupt I would hope python.exe would not fail because of it, but instead just either ignore the package or report an error. Another reason why I think python.exe shouldn't crash because of external library integrity is what if there is a file or some such thing in one's Python path that looks like and smells like a Python module/package but isn't? Should python.exe fail because of such a file? I do not know the structure of a Python package or whether pythonwin on my PC is corrupt. However I imaging that if a fake package can be made so that IT is corrupt (perhaps make a missing file) that testing would be relatively easy. Sorry I don't have more information for you. But hearing from others who have tried their python.exe help() modules works or fails would be a start. |
What I am saying is that if an extension module (one that provides non-python code in a load module) is corrupt, then it can totally screw up Python's internal bookkeeping, and there is nothing Python can do to protect itself against that. If the "corrupt" module in question is pure Python, then you are correct, 'help' should not fail. If, however, the corrupt module is not pure Python, then there may be nothing that can be done by Python to prevent the failure. Can you reproduce the problem using a pure Python 'corrupt' module? |
When in python.exe, and you type help() then modules, aren't you really If help() modules is in fact looking for just a Python module file with I do not know enough atm about how PythonWin is packaged. I'll look into it Perhaps an idea here too: If python.exe help() modules crashes when it In other words, perhaps the Python interpreter can call an external routine |
The unnamed quasi-html file loaded with msg118397 was a unless, essentially unreadable duplicate of that message, hence removed. |
There are half a dozen duplicate bugs of this one, with various suggestions on each. They should be summed up and linked. I should be able to do it this week-end if no-one does it first. |
Another thing I've noticed that makes the issue more complicated (or perhaps less complicated depending on your view). When running the python.exe at the DOS prompt (in a window on WinXP), then issuing the help() then modules commands, python.exe seems to hang at times, when it doesn't crash. However this apparent hang sometimes seems to be related to the attached "help" child window/dialog popup instantating with "focus" behind the DOS window. This popup with the focus (and behind it's parent window and being modal) prevents the mouse from moving the DOS window (holding the running python.exe) from being moved. The -sometimes- solution to this "apparent" hang is ALT-TAB back to the DOS window which will put the help-modal-dialog on top of said DOS window (which is running Python). |
Éric, go ahead and consolidate to one issue if you can get to it. 'Dev': your original post is way too long. The welcome message and module lists could have been snipped to one line plus ellipsis. Example:
Welcome .... help> modules Please wait.... and continue with traceback. |
import win32ui
from win32ui import GetMainFrame
dir(win32ui.GetMainFrame)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__']
dir(GetMainFrame)
['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] Is this normal? I'd expect at least GetWindowText() in the dir(). |
from GetMainFrame import GetWindowText
Traceback (most recent call last):
File "<input>", line 1, in <module>
ImportError: No module named GetMainFrame Also, I installed from the MS-Windows installer file: not from "pywin32-214.zip" which I think is the source distrobution. I've tried reinstallation but I get the same results. |
Oh I am running on an Intel Pentium 4 3.2GHz/3.2Ghz. http://sourceforge.net/projects/pywin32/files/pywin32/Build%20214/ |
Dev: I have no idea how what you just posted relates to the subject of this issue. Could you clarify please? |
It was suggested that a corrupt package would be where I'm experiencing the I included the information in the previous posts in case it helps in the Why does python.exe help() fail when an object, in this case win32ui, in the The dir() outputs in my previous posts show an object pywin32 package Why would help() fail on that? BTW I've created a ticket in the pywin32 at sourceforge.net. - Because I Traceback reprinted: Traceback (most recent call last):
File "<input>", line 1, in <module>
File "Q:\Python27\lib\site.py", line 453, in __call__
return pydoc.help(*args, **kwds)
File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
self.interact()
File "Q:\Python27\lib\pydoc.py", line 1735, in interact
request = self.getline('help> ')
File "Q:\Python27\lib\pydoc.py", line 1746, in getline
return raw_input(prompt)
File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py",
line 367, in Win32RawInput
ret=dialog.GetSimpleInput(prompt)
File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line
223, in GetSimpleInput
if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist |
mhammond added a recent note at: python.exe help() modules crashes - ID: 3150027 Scroll down below the detail and click the "Comments" link. View the note from mhammond's on 4/24/2011. Although this note will likely solve my particular problem, I suspect it does not directly solve "any corrput package" that would cause "python.exe" "help()" "modules" to crash or "appear to crash" (i.e. the modal popup appearing behind it's parent window). |
What about this application modal popup window appearing behind the DOS window? (See attached) That popup window may only need to have a system style flag to push it to the top of the window z-order stack. What causes that popup to appear? Is it Python source code or compiled C code built into python.exe? There is a MS-Windows win32 function called SetForegroundWindow() that may be the issue if it's not Python source code. http://stackoverflow.com/questions/3772233/win32-setforegroundwindow-unreliable I am grasping for straws here. Perhaps the python.exe app crashes in the cmd.exe window because of attempts to do something with the cmd.exe window while the app modal popup windows is behind it? As per my previous post is seems mhammond has a solution for his pythonwin package causing python.exe-help()-modules to crash. (If that's the case) it still doesn't address "other" packages having the same ability to crash python.exe, IDLE and other interactive interpreters thru help()-modules. |
Just delete the previous message... please. |
(Note: the word is 'separate', 2 e's and 2 a's, not 'seperate') Help is not built in to python.exe. It is added to builtins when the site module is imported. That import can be suppressed with the '-S' startup option. It is strictly intended for interactive use. I do not see this as much of a security issue. Crashing apps and especially servers should not be an issue because neither should be using help. Anyway, I should think that a hacker that can install a broken C extension could do much worse things. Help has three modes.
I am inclined to close this issue as I do not see any action needed by Cpython developers. Contrary to your assertion, running corrupt C-coded extensions *does* crash the process, and I do not think there is much we can do about it, as C lacks try:...except:. Certainly, there is no promise to guard against such. In my view, removing a corrupt package is an answer, not a workaround! |
This issue still seems to be about bad extension modules crashing CPython and we cannot fix that. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: