anyone else seeing this? 1) using a local windows build, I keep getting complaints about a missing symbol in the python22.dll: _PyGC_Insert an easy way to get this is to import the "xmlrpclib" module into a clean interpreter. (fwiw, this doesn't stop Python -- once you click OK, the interpreter proceeds as if nothing happened...) 2) most C functions that expect 8-bit strings crash if you hand them a unicode string containing non-ascii characters. an example:
import socket socket.gethostbyname(u"pythönware.com")
this works as expected in 2.1.1 (that is, I get an exception). it doesn't work in a local build of 2.2a2. </F>
anyone else seeing this?
1) using a local windows build, I keep getting complaints about a missing symbol in the python22.dll:
_PyGC_Insert
an easy way to get this is to import the "xmlrpclib" module into a clean interpreter.
(fwiw, this doesn't stop Python -- once you click OK, the interpreter proceeds as if nothing happened...)
Works fine in 2.2a3. Sounds like a version mismatch between DLL and PYD file -- Neil changed the GC API, but did it with macros.
2) most C functions that expect 8-bit strings crash if you hand them a unicode string containing non-ascii characters.
an example:
import socket socket.gethostbyname(u"pythönware.com")
this works as expected in 2.1.1 (that is, I get an exception). it doesn't work in a local build of 2.2a2.
Yes, confirmed in 2.2a3 :-( Tim? Time for a debug session? --Guido van Rossum (home page: http://www.python.org/~guido/)
2) most C functions that expect 8-bit strings crash if you hand them a unicode string containing non-ascii characters.
an example:
import socket socket.gethostbyname(u"pythönware.com")
this works as expected in 2.1.1 (that is, I get an exception). it doesn't work in a local build of 2.2a2.
Yes, confirmed in 2.2a3 :-(
Tim? Time for a debug session?
Never mind, Tim. :-) This crashes on Linux too. This patch fixes it, but I'm not sure if that's right -- more eyes, please? (Maybe the fix is simpler and it should just replace the test for Py_None with a test for NULL?) Index: getargs.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/getargs.c,v retrieving revision 2.63 diff -c -r2.63 getargs.c *** getargs.c 2001/08/28 16:37:51 2.63 --- getargs.c 2001/09/07 19:56:21 *************** *** 369,374 **** --- 369,375 ---- { assert (expected != NULL); sprintf(msgbuf, "must be %.50s, not %.50s", expected, + arg == NULL ? "NULL" : arg == Py_None ? "None" : arg->ob_type->tp_name); return msgbuf; } --Guido van Rossum (home page: http://www.python.org/~guido/)
[Guido]
This crashes on Linux too. This patch fixes it, but I'm not sure if that's right -- more eyes, please? (Maybe the fix is simpler and it should just replace the test for Py_None with a test for NULL?)
Well, converterr gets called from 56(!) places, and I spaced out after looking at 10 of them. Still, I can't imagine that removing the Py_None test could hurt anything, and a NULL test is definitely needed.
Index: getargs.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/getargs.c,v retrieving revision 2.63 diff -c -r2.63 getargs.c *** getargs.c 2001/08/28 16:37:51 2.63 --- getargs.c 2001/09/07 19:56:21 *************** *** 369,374 **** --- 369,375 ---- { assert (expected != NULL); sprintf(msgbuf, "must be %.50s, not %.50s", expected, + arg == NULL ? "NULL" : arg == Py_None ? "None" : arg->ob_type->tp_name); return msgbuf; }
I have a better solution for the bug, which I will check in as soon as I come up with a good testcase. Here's the long explanation: The problem was introduced by a refactoring. convertsimple() used to be a wrapper that called convertsimple1() and generated an error message if convertsimple1() returned NULL. I turned it inside out: convertsimple() became converterr() and convertsimple1() became convertsimple(). When the old convertsimple1() returned NULL, the new convertsimple() calls converterr(). The problem is that the Unicode routines change the value of the arg variable and set it to NULL if an error occurs. Then when the error routine is called, the arg variable is set to NULL. In the old code, the error routine used the value of arg in the caller -- so the assignment in the Unicode path wasn't relevant. The test for NULL isn't a good solution, because the original value for arg should be getting passed instead of NULL. Jeremy
Fredrik Lundh wrote:
anyone else seeing this?
1) using a local windows build, I keep getting complaints about a missing symbol in the python22.dll:
_PyGC_Insert
an easy way to get this is to import the "xmlrpclib" module into a clean interpreter.
Has the xmlrpclib module been compiled using the 2.2a3 headers? I changed the binary API between 2.2a2 and 2.2a3 (sorry). If you did recompile module then something is very wrong. Neil
[Fredrik Lundh]
anyone else seeing this?
1) using a local windows build, I keep getting complaints about a missing symbol in the python22.dll:
_PyGC_Insert
an easy way to get this is to import the "xmlrpclib" module into a clean interpreter.
Can't reproduce. Perhaps it has to do with this?: try: # optional xmlrpclib accelerator. for more information on this # component, contact info@pythonware.com import _xmlrpclib ... That module doesn't exist on my box, but I bet it does on yours. There are no references to _PyGC_Insert anywhere in core 2.2a3.
(fwiw, this doesn't stop Python -- once you click OK, the interpreter proceeds as if nothing happened...)
Consistent with the guess above if that causes the import to raise an exception.
participants (6)
-
Fredrik Lundh -
Fredrik Lundh -
Guido van Rossum -
Jeremy Hylton -
Neil Schemenauer -
Tim Peters