[ python-Bugs-1723338 ] Crash in ctypes callproc function with unicode string arg
Bugs item #1723338, was opened at 2007-05-22 10:43 Message generated for change (Comment added) made by claplace You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: Works For Me Priority: 5 Private: No Submitted By: Colin Laplace (claplace) Assigned to: Thomas Heller (theller) Summary: Crash in ctypes callproc function with unicode string arg Initial Comment: I've recently came to a bug using ctypes. I was using ctypes to call a syscall and and passing it a string argument, which was in fact in unicode. This resulted in a python crash in the callproc function. You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py ) tested with python 2.5 -- >Comment By: Colin Laplace (claplace) Date: 2007-05-28 09:58 Message: Logged In: YES user_id=25510 Originator: YES The argtypes thing fixed my problem, thank you. -- Comment By: Thomas Heller (theller) Date: 2007-05-23 18:35 Message: Logged In: YES user_id=11105 Originator: NO Unfortunately your test script does not run for me (I don't have twisted installed on Linux). I fear this is not a bug. When the .argtypes attribute for a foreign function is not set, you can pass (among others) Python strings *and* Python unicode strings to the function. The foreign function will receive a 'char *' in the former case, and a 'wchar_t *' in the latter case - the unicode string will *not* be converted. If this is your problem, and the foreign function expects a 'char *', you have several choices: 1. You can convert the unicode string to an ascii string in the Python code yourself. 2. You can wrap the unicode string in a c_char_p instance, and ctypes will do the conversion for you. 3. You can set the correct .argtypes attribute on the function, and ctypes will do the conversion for you. If this is not your problem, please provide a self-contained test case. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-23 04:06 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1723338 ] Crash in ctypes callproc function with unicode string arg
Bugs item #1723338, was opened at 2007-05-22 12:43 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Colin Laplace (claplace) Assigned to: Thomas Heller (theller) Summary: Crash in ctypes callproc function with unicode string arg Initial Comment: I've recently came to a bug using ctypes. I was using ctypes to call a syscall and and passing it a string argument, which was in fact in unicode. This resulted in a python crash in the callproc function. You can easily reproduce the crash by launching the attached python file (or at this link: https://core.fluendo.com/elisa/trac/browser/branches/rewrite-1/elisa/extern/inotify.py ) tested with python 2.5 -- >Comment By: Thomas Heller (theller) Date: 2007-05-28 17:39 Message: Logged In: YES user_id=11105 Originator: NO Thanks, closing then. -- Comment By: Colin Laplace (claplace) Date: 2007-05-28 11:58 Message: Logged In: YES user_id=25510 Originator: YES The argtypes thing fixed my problem, thank you. -- Comment By: Thomas Heller (theller) Date: 2007-05-23 20:35 Message: Logged In: YES user_id=11105 Originator: NO Unfortunately your test script does not run for me (I don't have twisted installed on Linux). I fear this is not a bug. When the .argtypes attribute for a foreign function is not set, you can pass (among others) Python strings *and* Python unicode strings to the function. The foreign function will receive a 'char *' in the former case, and a 'wchar_t *' in the latter case - the unicode string will *not* be converted. If this is your problem, and the foreign function expects a 'char *', you have several choices: 1. You can convert the unicode string to an ascii string in the Python code yourself. 2. You can wrap the unicode string in a c_char_p instance, and ctypes will do the conversion for you. 3. You can set the correct .argtypes attribute on the function, and ctypes will do the conversion for you. If this is not your problem, please provide a self-contained test case. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-23 06:06 Message: Logged In: YES user_id=33168 Originator: NO Thomas, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1723338&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1727024 ] subprocess: unreliability of returncode not clear from docs
Bugs item #1727024, was opened at 2007-05-28 17:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dan O'Huiginn (ohuiginn)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess: unreliability of returncode not clear from docs
Initial Comment:
The docs for the subprocess module (http://docs.python.org/lib/node533.html)
give the impression that you can reliably find the return code of a process by
checking returncode:
returncode
The child return code. A None value indicates that the process hasn't
terminated yet. A negative value -N indicates that the child was terminated by
signal N (Unix only).
But in fact, returncode is only updated when the poll() method is called, and
therefore will often be out-of-date. For instance
>>> process=subprocess.Popen('true') #*nix command to do nothing
>>> process.returncode
>>> process.returncode==None
True
>>> process.poll()
0
>>> process.returncode
0
As far as I can see, it is always better to use poll() to check the status or
return code of a subprocess. It might be good to either remove returncode from
the docs entirely, or at least to explain that it won't always be correct.
[incidentally, having returncode/poll() give None for a running process, and 0
for a process that has exited successfully, seems like a recipe for generating
bugs. But I guess it's too late to do anything about that now]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1727024&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1726026 ] Typo in ctypes.wintypes definition of WIN32_FIND_DATA field
Bugs item #1726026, was opened at 2007-05-26 18:38 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Koby Kahane (kobyk) >Assigned to: Thomas Heller (theller) Summary: Typo in ctypes.wintypes definition of WIN32_FIND_DATA field Initial Comment: In ctypes/wintypes.py, the ANSI and Unicode versions of the Win32 WIN32_FIND_DATA structure are defined. Both definitions share a typo in the definition of the last field. It is incorrectly spelled as "cAlternameFileName" when it should be "cAlternateFileName" as per the Windows SDK definition of the structure. -- >Comment By: George Yoshida (quiver) Date: 2007-05-29 12:35 Message: Logged In: YES user_id=671362 Originator: NO Thomas, can you take a look? The reporter seems to be correct. http://msdn2.microsoft.com/en-us/library/aa365740.aspx -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1726026&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1724366 ] cPickle module doesn't work with universal line endings
Bugs item #1724366, was opened at 2007-05-23 18:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Geoffrey Bache (gjb1002) >Assigned to: Jack Jansen (jackjansen) Summary: cPickle module doesn't work with universal line endings Initial Comment: On UNIX, I cannot read pickle files created on Windows using the cPickle module, even if I open the file with universal line endings. It works fine with the pickle module but is of course slower (and I have to read lots of them) I attach a test case that pickles and unpickles an smptlib.SMTP object, converting the file to DOS format in between. There is nothing special about SMTP, you can use any object at all in a different module. On my system (RHEL4 with Python 2.4.3) I get the following output: portmoller : pickletest.py cPickle unix2dos: converting file dump to DOS format ... Traceback (most recent call last): File "pickletest.py", line 14, in ? print load(readFile) ImportError: No module named smtplib portmoller : pickletest.py pickle unix2dos: converting file dump to DOS format ... -- >Comment By: Martin v. Löwis (loewis) Date: 2007-05-29 07:14 Message: Logged In: YES user_id=21627 Originator: NO Jack, can you take a look? If not, please unassign. -- Comment By: Geoffrey Bache (gjb1002) Date: 2007-05-25 19:24 Message: Logged In: YES user_id=769182 Originator: YES Yes, I'm sure Python is trying to import "smtplib\r". For various reasons I need to use protocol 0: not least because I use the pickle files as test data and it's much easier to administer a load of text files than a load of binary files. I will experiment with reading the files in binary mode on Monday and get back to you. My current workaround is to do loads(file.read()) instead of load(file) which I guess is a performance penalty. Any idea whether this is likely to be slower than just using the pickle module? (I haven't tested this) -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-25 12:29 Message: Logged In: YES user_id=479790 Originator: NO The culprit is cPickle.c; it takes certain shortcuts for read() and readline() depending on which type of file you pass in. For a true file object, it uses its own implementation for those two methods, ignoring the file mode. But it appears that there is NO WAY universal line endings could work if the pickle contains any unicode object. The pickle format for Unicode quotes any \n but *not* \r so the unpickler cannot determine, when it sees a "\r", if it is a MAC end-of-line or an embedded "\r". So, the only safe end-of-line character for a pickle using protocol 0 is "\n", and that means that the file must be written in binary mode. (This may also indicate that you cannot read unicode objects with embedded \r in a MAC using protocol 0, but I don't have a MAC to test it). So, until this is fixed (either the module or the documentation), one should forget about universal line endings and write all pickle files as binary. (This way ALL lines end in \n and it should work fine on all platforms) -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-25 11:04 Message: Logged In: YES user_id=479790 Originator: NO I don't see any "Attach" button... Just add these lines near the top of the test script: original__import = __import__ def myimport(name, *args): print "import",repr(name) return original__import(name,*args) #end myimport __builtins__.__import__ = myimport -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-05-25 11:00 Message: Logged In: YES user_id=479790 Originator: NO Please try again with this modified version. I think you will see that Python is trying to import "smtplib\r" On Windows, trying to read a pickle file with MAC line endings gives a different error: cPickle.UnpicklingError: pickle data was truncated It seems that cPickle support for protocol 0 is broken. If you can, try to use the higher, binary, protocols, they don't have this problem. Even if you must use protocol 0, opening the file always in binary mode should not have this problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1724366&group_id=5470
