[issue13129] bad argument exceptions observed in AST
New submission from rmtew : Platform Windows 7. hg id: a3f2dba93743+ (3.2) I do not know any reproduction steps for this bug outside as a side-effect within an incomplete and problematic Stackless merge. This bug also seems to exist in cpython, and is not in Stackless specific code. It seems to be bad exception handling, but maybe I do not understand all cases where this code is used. 1. ast_error_finish is called. 2. It calls PyErr_Fetch(&type, &value, &tback); 3. It them proceeds to treat 'value' as a tuple which results in PyErr_BadInternalCall being called and then being used in place of the original exception. Reproduction steps: 1. Sync http://hg.python.org/stackless. 2. Update to 3.2-slp branch. 3. Merge in changes from v3.2.1 to v3.2.2. 4. Compile and run regression tests. 5. Several exceptions will happen along the lines of bad argument where ast exceptions have happened and hit the problem above. -- files: ast.diff keywords: patch messages: 145158 nosy: rmtew priority: normal severity: normal status: open title: bad argument exceptions observed in AST versions: Python 3.2 Added file: http://bugs.python.org/file23343/ast.diff ___ Python tracker <http://bugs.python.org/issue13129> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13129] bad argument exceptions observed in AST
rmtew added the comment: False alarm, must have reproduced this in wrong source tree :-( Purely Stackless-specific. -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue13129> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
New submission from rmtew : zlibmodule.c calling inflateInit2 and deflateInit2 will subsequently proceed to crash in the case where these functions return Z_VERSION_ERROR. zlib implementation note: When you compile against zlib, several functions (actually macros) like inflateInit2 and deflateInit2 compile the version of zlib you are compiling against into the actual call of the underlying real zlib API function. Our situation: We are compiling Python as a static library. When we link Python against our main project, it links against the version of zlib used by that main project. The version numbers are different, and rather than getting a nice exception we get a crash. Expected result: Proper error handling in zlibmodule.c, and not crash. Unhandled errors in zlibmodule.c are passed into the custom function zlib_error which looks at the msg field of the zst struct. In the case of Z_VERSION_ERROR the msg field is not initialised and a crash will result from use of the nonsense value in msg. -- components: None messages: 142954 nosy: rmtew priority: normal severity: normal status: open title: zlibmodule cannot handle Z_VERSION_ERROR zlib error type: crash versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue12839> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12839] zlibmodule cannot handle Z_VERSION_ERROR zlib error
rmtew added the comment: Attached is a patch to fix the issue, generated using "p4 diff -du" which should hopefully be usable. -- keywords: +patch Added file: http://bugs.python.org/file23044/zlibmodule.patch ___ Python tracker <http://bugs.python.org/issue12839> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11070] test_capi crashes and fails
New submission from rmtew : OS: Windows 7 Compiler: Visual Studio 2008 Build: Win32 (Debug and Release) The main problem is observed in both debug and release builds, and even though the test effectively passes in both it also fails in release build. ** In a debug build I see the following: test_instancemethod (__main__.CAPITest) ... ok test_no_FatalError_infinite_loop (__main__.CAPITest) ... Then a dialog pops up telling me that Python has crashed. The unit test execution pauses until this dialog is dealt with. This then becomes: test_no_FatalError_infinite_loop (__main__.CAPITest) ... ok And the unit tests proceed to pass. ** In a release build I see the following: test_instancemethod (__main__.CAPITest) ... ok test_no_FatalError_infinite_loop (__main__.CAPITest) ... Then the crash dialog also pops up. Dismissing it results in the test failing however. test_no_FatalError_infinite_loop (__main__.CAPITest) ... FAIL == FAIL: test_no_FatalError_infinite_loop (__main__.CAPITest) -- Traceback (most recent call last): File "Lib\test\test_capi.py", line 50, in test_no_FatalError_infinite_loop b'Fatal Python error:' AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\nPlease contact the application's support team for more information." != b'Fatal Python error: PyThreadState_Get: no current thread' Is there some information I am missing somewhere (that I have not found via googling) or is this part of the gauntlet of unit test execution on Python now? -- components: Tests, Windows messages: 127512 nosy: rmtew priority: normal severity: normal status: open title: test_capi crashes and fails type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue11070> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11112] UDPTimeoutTest derives from SocketTCPTest
New submission from rmtew : File: Lib\test\test_socket.py Code: class UDPTimeoutTest(SocketTCPTest): Problem: This test is intended to test UDP sockets, but derives from SocketTCPTest. Logic dictates this should derive from SocketUDPTest. I've searched for UDP (with differing case, as that seems to matter) in several different fields on this site, and found no relevant matches. -- components: Tests messages: 127863 nosy: rmtew priority: normal severity: normal status: open title: UDPTimeoutTest derives from SocketTCPTest versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
