[ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Bugs item #1467450, was opened at 2006-04-10 03:21
Message generated for change (Comment added) made by theller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&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.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Thomas Heller (theller)
Summary: test_ctypes fails on OSX 10.3
Initial Comment:
test test_ctypes failed -- Traceback (most recent call
last):
File
"/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py",
line 30, in test_load
cdll.load(libc_name)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 112, in load
return self._load(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 153, in _load
return self.load_library(pathname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/_loader.py",
line 124, in load_library
return self._dlltype(libname, mode)
File
"/Users/anthonybaxter/python/Lib/ctypes/__init__.py",
line 288, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlcompat: unable to open this file with RTLD_LOCAL
This happens both with and without the patch in r43748.
Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed
Mar 30 20:11:17 PST 2005;
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power
Macintosh powerpc
GCC version:
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
--
>Comment By: Thomas Heller (theller)
Date: 2006-07-12 10:44
Message:
Logged In: YES
user_id=11105
Committed as r50601.
--
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-07-11 19:45
Message:
Logged In: YES
user_id=580910
With this patch test_ctypes passed on 10.3.
I'm in favor of applying this patch.
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-07-10 11:43
Message:
Logged In: YES
user_id=29957
I'm not going to get the opportunity to look at this before
the b2 freeze tomorrow morning, but will look at it soon after.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 11:07
Message:
Logged In: YES
user_id=11105
Even better would imo be to call the Gestalt function in the
_ctypes extensions module itself.
--
Comment By: Thomas Heller (theller)
Date: 2006-07-10 10:13
Message:
Logged In: YES
user_id=11105
Here is a patch that I hope will fix this problem. Ronald
Oussuren suggested in private email to use RTLD_GLOBAL as
default library loading mode on OS X 10.3. He suggested to
use the platform module to find out the osx version, however
I don't like. Instead I found by examining platform that
gestalt.gestalt("sysv") returns the information I need.
I still don't have access to 10.3 (and Python does not
compile on the 10.2.8 sourceforge osx compile farm machine -
should I add a bug for that one?), so I cannot really test
the patch myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-10 06:14
Message:
Logged In: YES
user_id=33168
Anthony is this still a problem?
--
Comment By: Thomas Heller (theller)
Date: 2006-05-09 20:38
Message:
Logged In: YES
user_id=11105
Does this failure still occur with Python 2.5a2, or the
current SVN trunk?
--
Comment By: Thomas Heller (theller)
Date: 2006-04-13 08:59
Message:
Logged In: YES
user_id=11105
I'm trying to get a copy of OS X 10.3, then will try to
install it and look after this problem.
OTOH, the ctypes loading code is currently rewritten in the
upstream version - this will probably prevent this failure.
In the meantime, can you try to find out the cause of this
failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is
the library file missing?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512814 ] Incorrect lineno's in code objects
Bugs item #1512814, was opened at 2006-06-26 18:01 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&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: Parser/Compiler Group: Python 2.5 >Status: Open >Resolution: None >Priority: 7 Submitted By: Thomas Wouters (twouters) Assigned to: Neal Norwitz (nnorwitz) Summary: Incorrect lineno's in code objects Initial Comment: The 2.5 compiler forgets how to count linenumbers in certain situations: >>> s255 = "".join(["\n"] * 255 + ["spam"]) >>> s256 = "".join(["\n"] * 256 + ["spam"]) >>> exec s255 Traceback (most recent call last): File "", line 1, in File "", line 256, in NameError: name 'spam' is not defined >>> exec s256 Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: name 'spam' is not defined Notice the 'line 1' linenumber in the case of 256 blank lines. The same happens for 'pass' statements or 'if 0' blocks instead of blank lines. The problem is in the actual code objects created: >>> dis.disco(compile(s255, "", "exec")) 256 0 LOAD_NAME0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE >>> dis.disco(compile(s256, "", "exec")) 1 0 LOAD_NAME0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE -- >Comment By: Thomas Wouters (twouters) Date: 2006-07-12 15:11 Message: Logged In: YES user_id=34209 Unfortunately, it isn't quite fixed. It's fixed for code in the global scope, but not for functions: >>> s255 = "def foo():\n " + "".join(["\n "] * 254 + [" spam\n"]) >>> exec s255 >>> dis.dis(foo) .256 0 LOAD_GLOBAL 0 (spam) . 3 POP_TOP . 4 LOAD_CONST 0 (None) . 7 RETURN_VALUE >>> s256 = "def foo():\n " + "".join(["\n "] * 255 + [" spam\n"]) >>> exec s256 >>> dis.dis(foo) . 1 0 LOAD_GLOBAL 0 (spam) . 3 POP_TOP . 4 LOAD_CONST 0 (None) . 7 RETURN_VALUE I haven't tried figuring out for what else it's broken like this, sorry :) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-10 02:04 Message: Logged In: YES user_id=33168 Committed revision 50500. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Bugs item #1521375, was opened at 2006-07-12 13:22 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=1521375&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 Submitted By: Scot Doyle (scotdoyle) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes test overwrites /dev/null Initial Comment: Steps to reproduce on Debian Sarge: 1. ls -l /dev/null 2. wget http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz 3. tar xvzf Pyth* 4. cd Pyth* 5. ./configure 6. make 7. su 8. make test 9. ls -l /dev/null /dev/null goes from being a special character device to a normal file of length zero. The following command can be used instead of step 8 above to delete /dev/null ./python -c 'import ctypes.test.test_find' To recreate /dev/null: 1. su 2. rm /dev/null 3. mknod -m 666 /dev/null c 1 3 4. chown root:root /dev/null -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Bugs item #1521375, was opened at 2006-07-12 20:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&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 Submitted By: Scot Doyle (scotdoyle) >Assigned to: Thomas Heller (theller) Summary: ctypes test overwrites /dev/null Initial Comment: Steps to reproduce on Debian Sarge: 1. ls -l /dev/null 2. wget http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz 3. tar xvzf Pyth* 4. cd Pyth* 5. ./configure 6. make 7. su 8. make test 9. ls -l /dev/null /dev/null goes from being a special character device to a normal file of length zero. The following command can be used instead of step 8 above to delete /dev/null ./python -c 'import ctypes.test.test_find' To recreate /dev/null: 1. su 2. rm /dev/null 3. mknod -m 666 /dev/null c 1 3 4. chown root:root /dev/null -- >Comment By: Thomas Heller (theller) Date: 2006-07-12 20:53 Message: Logged In: YES user_id=11105 Now, that is an 'interesting' bug. ctypes.util.find_library does execute shell commands that happen to have '/dev/null' in them, but it is completely unclear to me how one can overwrite /dev/null (even if root). Can you see anything that's wrong there (That code is not from me, and I'm not at all an expert in linux programming)? BTW, I cannot reproduce this on ubuntu with 'sudo ./python -c "import ctypes.test.test_find"'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521491 ] file.seek() influelce write() when opened with a+ mode
Bugs item #1521491, was opened at 2006-07-12 22:04
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=1521491&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode
Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"
Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):
from __future__ import with_statement
with open(path,'a+') as f:
f.seek(0,2) # go to end
pos = f.tell()
f.seek(0,0)
line = f.readline().strip()
f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
f.write("something")
Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521491 ] file.seek() influelce write() when opened with a+ mode
Bugs item #1521491, was opened at 2006-07-12 22:04
Message generated for change (Comment added) made by rudnik_lior
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode
Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"
Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):
from __future__ import with_statement
with open(path,'a+') as f:
f.seek(0,2) # go to end
pos = f.tell()
f.seek(0,0)
line = f.readline().strip()
f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
f.write("something")
Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)
--
>Comment By: Lior (rudnik_lior)
Date: 2006-07-12 22:09
Message:
Logged In: YES
user_id=1364480
Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521375 ] ctypes test overwrites /dev/null
Bugs item #1521375, was opened at 2006-07-12 13:22 Message generated for change (Comment added) made by scotdoyle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&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 Submitted By: Scot Doyle (scotdoyle) Assigned to: Thomas Heller (theller) Summary: ctypes test overwrites /dev/null Initial Comment: Steps to reproduce on Debian Sarge: 1. ls -l /dev/null 2. wget http://www.python.org/ftp/python/2.5/Python-2.5b2.tgz 3. tar xvzf Pyth* 4. cd Pyth* 5. ./configure 6. make 7. su 8. make test 9. ls -l /dev/null /dev/null goes from being a special character device to a normal file of length zero. The following command can be used instead of step 8 above to delete /dev/null ./python -c 'import ctypes.test.test_find' To recreate /dev/null: 1. su 2. rm /dev/null 3. mknod -m 666 /dev/null c 1 3 4. chown root:root /dev/null -- >Comment By: Scot Doyle (scotdoyle) Date: 2006-07-12 17:17 Message: Logged In: YES user_id=1554504 Hey Thomas, that pointer is just what I needed :-) /dev/null was being deleted by gcc. Discussion at http://www.cs.helsinki.fi/linux/linux-kernel/2001-38/1503.html The attached patch fixed the problem on Debian Sarge and Ubuntu 6.06. -- Comment By: Thomas Heller (theller) Date: 2006-07-12 13:53 Message: Logged In: YES user_id=11105 Now, that is an 'interesting' bug. ctypes.util.find_library does execute shell commands that happen to have '/dev/null' in them, but it is completely unclear to me how one can overwrite /dev/null (even if root). Can you see anything that's wrong there (That code is not from me, and I'm not at all an expert in linux programming)? BTW, I cannot reproduce this on ubuntu with 'sudo ./python -c "import ctypes.test.test_find"'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521375&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512814 ] Incorrect lineno's in code objects
Bugs item #1512814, was opened at 2006-06-26 09:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&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: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Thomas Wouters (twouters) >Assigned to: Thomas Wouters (twouters) Summary: Incorrect lineno's in code objects Initial Comment: The 2.5 compiler forgets how to count linenumbers in certain situations: >>> s255 = "".join(["\n"] * 255 + ["spam"]) >>> s256 = "".join(["\n"] * 256 + ["spam"]) >>> exec s255 Traceback (most recent call last): File "", line 1, in File "", line 256, in NameError: name 'spam' is not defined >>> exec s256 Traceback (most recent call last): File "", line 1, in File "", line 1, in NameError: name 'spam' is not defined Notice the 'line 1' linenumber in the case of 256 blank lines. The same happens for 'pass' statements or 'if 0' blocks instead of blank lines. The problem is in the actual code objects created: >>> dis.disco(compile(s255, "", "exec")) 256 0 LOAD_NAME0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE >>> dis.disco(compile(s256, "", "exec")) 1 0 LOAD_NAME0 (spam) 3 POP_TOP 4 LOAD_CONST 0 (None) 7 RETURN_VALUE -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-12 22:59 Message: Logged In: YES user_id=33168 Try the attached patch on for size. Let me know if you can find any other holes. -- Comment By: Thomas Wouters (twouters) Date: 2006-07-12 06:11 Message: Logged In: YES user_id=34209 Unfortunately, it isn't quite fixed. It's fixed for code in the global scope, but not for functions: >>> s255 = "def foo():\n " + "".join(["\n "] * 254 + [" spam\n"]) >>> exec s255 >>> dis.dis(foo) .256 0 LOAD_GLOBAL 0 (spam) . 3 POP_TOP . 4 LOAD_CONST 0 (None) . 7 RETURN_VALUE >>> s256 = "def foo():\n " + "".join(["\n "] * 255 + [" spam\n"]) >>> exec s256 >>> dis.dis(foo) . 1 0 LOAD_GLOBAL 0 (spam) . 3 POP_TOP . 4 LOAD_CONST 0 (None) . 7 RETURN_VALUE I haven't tried figuring out for what else it's broken like this, sorry :) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-09 17:04 Message: Logged In: YES user_id=33168 Committed revision 50500. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512814&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1521491 ] file.seek() influelce write() when opened with a+ mode
Bugs item #1521491, was opened at 2006-07-12 15:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior (rudnik_lior)
Assigned to: Nobody/Anonymous (nobody)
Summary: file.seek() influelce write() when opened with a+ mode
Initial Comment:
Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33)
Assuming documentation is correct: (from seek() help
"Note that if the file is opened for appending (mode
'a' or 'a+'), any seek() operations will be undone at
the next write"
Doing the following is __not__ undoing the seek
operation after calling this a few times (Simplified
code snippet):
from __future__ import with_statement
with open(path,'a+') as f:
f.seek(0,2) # go to end
pos = f.tell()
f.seek(0,0)
line = f.readline().strip()
f.seek(0,2) # go to end, not effective if opened
with mode a/a+ (currently bug?)
f.write("something")
Calling the above code repeatedly didnt increase the
file size beyond 166 bytes (in my code)
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-07-12 23:29
Message:
Logged In: YES
user_id=33168
This seems to work for me on Linux. Maybe we are testing
differently. What o/s and version are you using? Does this
work with Python 2.4? Can you attach a complete test case
that demonstrates this problem?
Thanks.
--
Comment By: Lior (rudnik_lior)
Date: 2006-07-12 15:09
Message:
Logged In: YES
user_id=1364480
Re-tried the code with empty file - it doesnt grow beyond
creating and writting at position 0 so it seems the seek
does influence the write position.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1521491&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
