[ python-Bugs-1200686 ] SyntaxError raised on win32 for correct files
Bugs item #1200686, was opened at 2005-05-12 16:19
Message generated for change (Comment added) made by julien_sagnard
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: SyntaxError raised on win32 for correct files
Initial Comment:
Try to import the attached file (dt.py) on Windows with
Python 2.4 or 2.4.1 and you'll get a SyntaxError (the
file was written a long time ago, and worked perfectly
well on Python 2.1, 2.2 and 2.3.) The same does not
happen when importing the same module on Linux (tested
with 2.4 and 2.4.1). When the module imports fine
you'll get an ImportError (don't want to attach all
dependencies here) but the SyntaxError comes before that.
Also note that compiling the file with
compiler.compileFile("dt.py") generates a perfectly
good .pyc file that can be later imported just fine
(tested with 2.4 and 2.4.1 on Windows).
--
Comment By: Julien Sagnard (julien_sagnard)
Date: 2005-07-20 11:37
Message:
Logged In: YES
user_id=1181710
It's ok if I remove coding declaration.
I have no access to current cvs, but if someone send me a
zip with latest version, I can try it.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-07-19 18:19
Message:
Logged In: YES
user_id=89016
This bug should be fixed in the current CVS version. So, can
you retry with current CVS? As a workaround you might also
want to remove the PEP 263 coding declaration if you don't
have any special character in your file.
--
Comment By: Julien Sagnard (julien_sagnard)
Date: 2005-07-19 18:05
Message:
Logged In: YES
user_id=1181710
I have a similar problem with an other file (log.py).
On my computer ( Windows 2000 ) this 2 files ( log.py and
dt.py ) works with python 2.4 but raise a syntax error on
python 2.4.1 :
D:\dvt\tmp\bug2_4_1>python -c "import log"
Traceback (most recent call last):
File "", line 1, in ?
File "D:\dvt\tmp\bug2_4_1\log.py", line 356
w = 72
^
SyntaxError: invalid syntax
--
Comment By: Greg Chapman (glchapman)
Date: 2005-05-18 16:15
Message:
Logged In: YES
user_id=86307
I'm fairly sure this is caused by the bug described here:
www.python.org/sf/1175396
The module imports without syntax error on my Windows system
(with a patched codecs.py to work around the above bug).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1200686&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241507 ] StreamReader broken for byte string to byte string codecs
Bugs item #1241507, was opened at 2005-07-20 12:47 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=1241507&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 Submitted By: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader broken for byte string to byte string codecs Initial Comment: print sys.version 2.4.1 (#2, Jul 12 2005, 09:22:25) [GCC 4.0.1 (Debian 4.0.1-1)] Decoding to what (according to the documentation) should be a byte string (using StreamReader) does one of 2 incorrect things, depending on the default encoding: 1) If the byte string has values not in the current default encoding then StreamReader.read() incorrectly triggers an exception. 2) If the byte string can be accomodated by the current default encoding then StreamReader.read() incorrectly returns a unicode object. The documentation says in lib/standard-encodings.html: "The result of the ``decoding'' direction is listed as operand type in the table." "base64_codec ... byte string" (This bug does not exist in python2.2 or 2.3) The attached script demonstrates the 2 related bugs. Many thanks, Graham -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241507&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 08:27 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=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-567972 ] Missing 4 socket object properties
Feature Requests item #567972, was opened at 2002-06-12 12:56
Message generated for change (Comment added) made by grahamh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&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: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Graham Horler (grahamh)
Assigned to: Martin v. Löwis (loewis)
Summary: Missing 4 socket object properties
Initial Comment:
The C socketmodule has a struct PySocketSockObject,
with family, type and proto members.
These would be terribly helpful to have access to in
Python, when implementing some generic socket helper
functions.
The "blocking" flag could also be made available, but
would require some extra coding.
(I'm using Python 2.1.3 under Linux 2.4.16, so I cannot
extend the socket class itself ((as in py2.2)), and don't
want to slow down sockets with a complete wrapper, as I
use them heavily.)
Thanks, Graham.
--
>Comment By: Graham Horler (grahamh)
Date: 2005-07-20 15:47
Message:
Logged In: YES
user_id=543663
The patch applies, compiles, runs OK for me (thanks).
However it does not add access to the blocking flag.
Under Linux I can go:
fcntl.fcntl(fd, fcntl.F_GETFL) & os.O_NDELAY != 0
But this is not portable, and is probably repeating code.
Also the 3 added members are not available from an instance
of the _socketobject wrapper, you have to go
mysock._sock.family.
(The _socketobject wrapper in socket.py is a little bizarre
IMVHO.)
Perhaps they could be added using instances of property().
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-07-17 14:49
Message:
Logged In: YES
user_id=1188172
Attaching a patch which implements the three members of
_socket.socket.
Please review.
--
Comment By: Martin v. Löwis (loewis)
Date: 2002-06-15 14:21
Message:
Logged In: YES
user_id=21627
Sounds good. Would you like to produce a patch implementing
this feature?
--
Comment By: Graham Horler (grahamh)
Date: 2002-06-12 13:00
Message:
Logged In: YES
user_id=543663
Oh yes, the repr of a socket object includes the missing info,
so to get hold of the family, I go:
int(repr(sock).split(' ')[3].split('=')[1][:-1])
Similar for type and protocol, not nice!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=567972&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241619 ] -m does not find dotted modules
Bugs item #1241619, was opened at 2005-07-20 15:06 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=1241619&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: -m does not find dotted modules Initial Comment: -m does not appear to find modules that are referenced to with dots on windows: D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>echo print 'found!' > found.py D:\Python24\Lib\site-packages>python -m found found! D:\Python24\Lib\site-packages>mkdir directory D:\Python24\Lib\site-packages>move found.py directory D:\Python24\Lib\site-packages>del found.pyc Could Not Find D:\Python24\Lib\site-packages\found.pyc D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>python -m directory.found python: module directory.found not found D:\Python24\Lib\site-packages>python directory\found.py found! D:\Python24\Lib\site-packages> This should use the standard python finding mechanism to cope with dotted packages. Also with package\__init__.py -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241619&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1241619 ] -m does not find dotted modules
Feature Requests item #1241619, was opened at 2005-07-20 10:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1241619&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: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Giles Antonio Radford (mewf) Assigned to: Nobody/Anonymous (nobody) Summary: -m does not find dotted modules Initial Comment: -m does not appear to find modules that are referenced to with dots on windows: D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>echo print 'found!' > found.py D:\Python24\Lib\site-packages>python -m found found! D:\Python24\Lib\site-packages>mkdir directory D:\Python24\Lib\site-packages>move found.py directory D:\Python24\Lib\site-packages>del found.pyc Could Not Find D:\Python24\Lib\site-packages\found.pyc D:\Python24\Lib\site-packages>python -m found python: module found not found D:\Python24\Lib\site-packages>python -m directory.found python: module directory.found not found D:\Python24\Lib\site-packages>python directory\found.py found! D:\Python24\Lib\site-packages> This should use the standard python finding mechanism to cope with dotted packages. Also with package\__init__.py -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-20 12:54 Message: Logged In: YES user_id=80475 The initial implementation of -m was intentionally confined to the simplest case. The issues pertaining to packages are dealt with through the PEP process: http://www.python.org/peps/pep-0338.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1241619&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 13:27 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 21:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? -- Comment By: munder12 (munder12) Date: 2005-07-20 21:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 09:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: Tim Peters (tim_one) Date: 2005-07-20 17:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 17:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? -- Comment By: munder12 (munder12) Date: 2005-07-20 17:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241507 ] StreamReader broken for byte string to byte string codecs
Bugs item #1241507, was opened at 2005-07-20 13:47 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241507&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Graham Horler (grahamh) Assigned to: Nobody/Anonymous (nobody) Summary: StreamReader broken for byte string to byte string codecs Initial Comment: print sys.version 2.4.1 (#2, Jul 12 2005, 09:22:25) [GCC 4.0.1 (Debian 4.0.1-1)] Decoding to what (according to the documentation) should be a byte string (using StreamReader) does one of 2 incorrect things, depending on the default encoding: 1) If the byte string has values not in the current default encoding then StreamReader.read() incorrectly triggers an exception. 2) If the byte string can be accomodated by the current default encoding then StreamReader.read() incorrectly returns a unicode object. The documentation says in lib/standard-encodings.html: "The result of the ``decoding'' direction is listed as operand type in the table." "base64_codec ... byte string" (This bug does not exist in python2.2 or 2.3) The attached script demonstrates the 2 related bugs. Many thanks, Graham -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-07-21 00:53 Message: Logged In: YES user_id=89016 Checked in a fix as: Lib/codecs.py 1.46 Lib/test/test_codecs.py 1.24 Lib/codecs.py 1.35.2.8 Lib/test/test_codecs.py 1.15.2.6 Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241507&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 08:27 Message generated for change (Comment added) made by munder12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: munder12 (munder12) Date: 2005-07-20 19:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 16:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 16:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? -- Comment By: munder12 (munder12) Date: 2005-07-20 16:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1241545 ] garbage collection asserts failing
Bugs item #1241545, was opened at 2005-07-20 09:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&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: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: munder12 (munder12) Assigned to: Nobody/Anonymous (nobody) Summary: garbage collection asserts failing Initial Comment: Modules/gcmodule.c:294: visit_reachable: Assertion `gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed. Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp). Also tried Python 2.3.5. When searching Google for this error, found following link where someone using yum updates was getting same error from python http://forums.fedoraforum.org/showthread.php?t=54704 -- >Comment By: Tim Peters (tim_one) Date: 2005-07-20 20:35 Message: Logged In: YES user_id=31435 I'm intimately familiar with the gc code, and I'm sure this assert has never triggered in any core Python release, or in any Zope release, not even in between-releases buggy development states. It means some memory gc is staring at has an insane value, one that can't possibly arise in intended operation. If you get into gdb (whatever debugger you have), it might be useful to know what value gc_refs _does_ have at this point. One possibility is that you're mixing a debug-build Python (which you are using: asserts never trigger in a release-build Python, simply because the assert() macro expands to nothing then) with one or more release-build extension modules. Trying to mix like that can blow up in all sorts of "impossible" ways. -- Comment By: munder12 (munder12) Date: 2005-07-20 20:04 Message: Logged In: YES user_id=1156202 Sorry, I realize it is not much to go on but I cannot currently get it to fail other than when I run this one script. It is all written in python. It is a simulation running a genetic algorithm that is set up to run about 24 hours straight. This error occurs within about 5 hours into the simulation (repeatedly). Running similar simulations that complete in less than a couple hours run without a problem. Was hoping someone familiar with the gc routines might go "oh, yeah... -4 is valid now too.." or something similar. In the meantime, I will be trying to continue to reduce the number of imported modules where I can still get the problem to happen There are 2 modules psyco and pyro that are non- core and Tkinter. But since the Google search turned up yum giving same error (which I doubt uses psyco, pyro, or Tkinter), I thought I would mention it here as I continued searching. -- Comment By: Tim Peters (tim_one) Date: 2005-07-20 17:24 Message: Logged In: YES user_id=31435 Well, this isn't enough info to go on. For example, what program was Python running at the time? What were you doing? How could anyone else try to reproduce this? It's certainly not something Python normally does ;-) FWIW, the most likely cause is bad C coding in a Python extension (non-core) module. That the problem persists for you across Python versions points even more at non-core C code. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-07-20 17:20 Message: Logged In: YES user_id=35752 Usually this kind of error is caused by a bug in a 3rd party extension module. Try to narrow down the test case as much as possible. Can you provide a Python script that triggers the assertion failure? -- Comment By: munder12 (munder12) Date: 2005-07-20 17:15 Message: Logged In: YES user_id=1156202 This also fails in Python 2.4.1 on same system. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1112949 ] ioctl has problems on 64 bit machines
Bugs item #1112949, was opened at 2005-01-30 22:55
Message generated for change (Comment added) made by lordsutch
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&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: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephen Norris (stephennorris)
Assigned to: Nobody/Anonymous (nobody)
Summary: ioctl has problems on 64 bit machines
Initial Comment:
fcntly.ioctl takes an int as the second argument. If
the value passed is a large 32 bit quantity (0x80046601
for example - EXT2_IOC_GETFLAGS) then I get:
Traceback (most recent call last):
File "CommSecure-CVS/Operations/checkSpace.py", line
73, in ?
main(sys.argv[1:])
File "CommSecure-CVS/Operations/checkSpace.py", line
25, in main
os.path.walk(file, doDirectory, total)
File "/usr/lib64/python2.3/posixpath.py", line 282,
in walk
func(arg, top, names)
File "CommSecure-CVS/Operations/checkSpace.py", line
61, in doDirectory
flags = fcntl.ioctl(fd, EXT3_IOC_GETFLAGS, "")
OverflowError: signed integer is greater than maximum
My _guess_ here is that the code is checking against 32
bit quantities rather than 64 bit when converting to
the C data type?
Platform is Linux, Fedora Core 3 on AMD Opteron.
--
Comment By: Chris Lawrence (lordsutch)
Date: 2005-07-20 20:11
Message:
Logged In: YES
user_id=6757
The problem seems to be that Python integers are "long int,"
while the type expected by ioctl(2) is "unsigned long int"
(on AMD64, at least).
My hackish workaround is to coerce the ioctl number to a
signed quantity:
op = struct.unpack('i', struct.pack('I', op))[0]
Once it gets into the C code, the signed quantity is then
coerced back to unsigned long int by the ioctl call (after
an intermediate stop as (signed) int).
Probably, the correct course of action here is to figure out
what type ioctl(2) uses on a particular architecture and
adjust the PyArgs_ParseTuple() call and the type of "op"
accordingly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112949&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
