[ python-Bugs-1351707 ] zipimport produces incomplete IOError instances
Bugs item #1351707, was opened at 2005-11-08 22:43 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&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: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport produces incomplete IOError instances Initial Comment: The get_data() method on the zipimport.zipimporter object produces IOError exceptions that only have an error message. It should use PyErr_SetFromErrnoWithFilename() instead of PyErr_Format() for IOError exceptions. This should be fixed for both Python 2.4.3 and 2.5. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 10:39 Message: Logged In: YES user_id=1188172 Fixed in rev. 42487, 42488. -- Comment By: Thomas Lee (krumms) Date: 2005-11-10 01:46 Message: Logged In: YES user_id=315535 Patch against HEAD here: http://sourceforge.net/tracker/index.php?func=detail&aid=1352711&group_id=5470&atid=305470 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1351707&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-563141 ] fileinput/gzip modules should play well
Feature Requests item #563141, was opened at 2002-06-01 02:27 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&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: Closed >Resolution: Accepted Priority: 5 Submitted By: Greg White (groggygreggy) Assigned to: Nobody/Anonymous (nobody) Summary: fileinput/gzip modules should play well Initial Comment: It seems to be nearly impossible to use the fileinput module to read gzip files, even though gzip support is available in the gzip module. As a first step, it would be nice if the fileinput.FileInput class provided an overridable method that let outsiders glue the gzip module in place. It would also be nice if there was a way to make fileinput just automatically support gzip files (if, for instance, it saw a .gz extension). -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 15:58 Message: Logged In: YES user_id=1188172 Accepted by committing patch #1215184. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-05 16:52 Message: Logged In: YES user_id=1188172 See patch #1215184. -- Comment By: Brett Cannon (bcannon) Date: 2003-05-13 04:25 Message: Logged In: YES user_id=357491 The hook is reasonable, the automatic opening of gzip is not. No need to have magic done based purely on extension. Any chance you could write a patch to expose the hook? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=563141&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-764493 ] test test_nis crashed -- nis.error: no such key in map
Bugs item #764493, was opened at 2003-07-02 12:09 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&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: Demos and Tools Group: Python 2.3 >Status: Pending Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test test_nis crashed -- nis.error: no such key in map Initial Comment: I always ignored this test error, but maybe you want to fix this: test test_nis crashed -- nis.error: no such key in map $ ./python Lib/test/test_nis.py nis.maps() group.bygid.tmp mail.aliases n.strack strack Traceback (most recent call last): File "Lib/test/test_nis.py", line 24, in ? if nis.match(k, nismap) != v: nis.error: no such key in map $ I believe this might be some misconfiguration of NIS on thsi host(we use it on other machines, but it should not be enabled on this particular machine). But, when I do "ypcat mail.aliases", I do not see a line with "n.strack strack". Maybe more debug trace would help to find what's going on. -- >Comment By: Georg Brandl (birkenfeld) Date: 2006-02-19 16:10 Message: Logged In: YES user_id=1188172 Does this error persist in Python 2.4? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 17:29
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&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.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix
Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.
When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris.
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL
There was garbage on the end of the string when it
would fail.
I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c. The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.
I checked the source for 2.4.2 and noticed the same
problem. Patch to fix the problem is attached.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 15:03
Message:
Logged In: YES
user_id=6380
One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way. Whether null-terminating it makes
sense or not depends on the particular operation code.
I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied. A quick code review reveals a
few more issues:
- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)
- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense! Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.
- In the first branch of the function, this line:
if (mutate_arg && (len < sizeof buf)) {
ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use
if (mutate_arg && arg == buf) {
- If it's important to null-terminate the data in the buffer
when a string is passed in, shouldn't we null-terminate it
also when a writable buffer-interface object is passed in?
If not in the latter case, why if a string is passed? One
could argue that a string with an explicit \0 (visible to
Python code) at the end ought to be passed in if the
semantics of the op code requires a null-terminated argument
(which most ioctl op codes don't -- the typical argument is
a C struct).
- The proposed patch reduces the maximum buffer size to
1023, which violates the docs. (Yes the docs explicitly
mention 1024.)
- The best we can do seems to be: increase the buffer size
to 1025; null-pad it in all cases; change the code for
mutable buffers to test for sizeof buf - 1. This still
leaves the case where the buffer isn't used because a
mutable buffer is passed that's longer than 1024. Which
suggests that we can't completely fix this -- it will always
be possible to crash Python using this function by passing
an op code that encodes a buffer length > 1024 while passing
a shorter argument, so the internal buffer is used. I guess
we could do the null-padding as long as we document it and
document that when a mutable buffer is passed we don't
guarantee it.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 02:14
Message:
Logged In: YES
user_id=33168
Thomas, could this have caused the flakiness that you just
fixed with test_pty? This patch seems correct to me and I
think it should be applied. (If you want I can do that, but
I wanted you to see this first.)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1431253 ] Logging hangs thread after detaching a StreamHandler's termi
Bugs item #1431253, was opened at 2006-02-14 06:07
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1431253&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: Works For Me
Priority: 5
Submitted By: Yang Zhang (yangzhang)
Assigned to: Vinay Sajip (vsajip)
Summary: Logging hangs thread after detaching a StreamHandler's termi
Initial Comment:
Hi all,
After many hours, I think I've found a bug in the
logging module!
If you add a (stdout) StreamHandler to a logger, then
detach the terminal for that stdout, subsequent calls
to log() will hang the calling thread.
To reproduce this, write the following scripts (this
was a small test case I came up with - maybe there's
something simpler):
$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ;
done'
$ cat hup.bash
#!/usr/bin/env bash
./hup.py &
$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
logging.basicConfig( filename = '/tmp/lup.out',
filemode = 'w' )
# XXX PROBLEM LINE BELOW
logging.getLogger('').addHandler( logging.
StreamHandler() )
while True:
f.write( '---\n' )
f.flush()
logging.critical( '==' )
time.sleep(1)
finally:
f.close()
Run ./tryhup.bash. It will sit in an idle spin. Monitor
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on
tryhup to kill it. The python process is still running,
but is stalled (the .out files are no longer changing).
If you remove the above labeled line, however, this
doesn't happen.
Can anybody please acknowledge this bug? Any temporary
workarounds to this problem? Thanks in advance for
looking into this and for hearing me in!
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-02-19 21:34
Message:
Logged In: YES
user_id=308438
I can't tell from the info you've given what the problem
might be (e.g. state of redirections), but as it doesn't
appear to be a logging bug, I'm closing this.
By default, raiseExceptions is set to 1 in the logging
package, so a handler's handleError should be called when an
exception is raised in a handler.
You catch an exception with a try/except clause, like so:
try:
# code which raises some exception
except Exception, e:
open('/tmp/exc.txt', 'w').write(str(e))
--
Comment By: Yang Zhang (yangzhang)
Date: 2006-02-17 07:17
Message:
Logged In: YES
user_id=1207658
Hi, yes, after I submitted this bug I actually looked into
logging.StreamHandler, and found that its code was not too
complicated (as with everything Python :).
I tried some more experiments, and found that the problem is
in stderr, which throws an exception. The problem was that I
couldn't see the exception (and didn't suspect that's what
was happening), so the fact that the next line never came
out led me to believe that the thread froze.
Is stderr supposed to raise an exception like this? Is this
a bug?
Unfortunately, it's hard for me to tell what's going on
(what the exception is that's being thrown). How do I tell
what it's raising? (stderr is no longer avail. after all) I
don't know how to catch an exception of any type and (say)
print its str or repr value to a file so that I can tell
what's going on.
--
Comment By: Yang Zhang (yangzhang)
Date: 2006-02-17 07:16
Message:
Logged In: YES
user_id=1207658
Hi, yes, after I submitted this bug I actually looked into
logging.StreamHandler, and found that its code was not too
complicated (as with everything Python :).
I tried some more experiments, and found that the problem is
in stderr, which throws an exception. The problem was that I
couldn't see the exception (and didn't suspect that's what
was happening), so the fact that the next line never came
out led me to believe that the thread froze.
Is stderr supposed to raise an exception like this? Is this
a bug?
Unfortunately, it's hard for me to tell what's going on
(what the exception is that's being thrown). How do I tell
what it's raising? (stderr is no longer avail. after all) I
don't know how to catch an exception of any type and (say)
print its str or repr value to a file so that I can tell
what's going on.
--
Comment By: Vinay Sajip (vsajip)
Date: 2006-02-17 01:04
Message:
Logged In: YES
user_id=308438
Please provide more information about your OS - I ran these
scripts on Ubuntu 5.1
[ python-Bugs-1430436 ] recursive __getattr__ in thread crashes BSDs
Bugs item #1430436, was opened at 2006-02-13 07:35 Message generated for change (Comment added) made by aix-d You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430436&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: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Nobody/Anonymous (nobody) Summary: recursive __getattr__ in thread crashes BSDs Initial Comment: The following code consistently crashes Python 2.4 on Mac OS X: import threading class foo: def __getattr__(self, x): self.foo def j(): foo().bar t = threading.Thread(target=j, args=()) t.start() -- Comment By: aix-d (aix-d) Date: 2006-02-20 01:40 Message: Logged In: YES user_id=1449422 Hello. I have the same segfault :-( Python version: from SVN Python 2.5a0 (trunk, Feb 19 2006, 22:22:12) [GCC 3.4.4 [FreeBSD] 20050518] on freebsd6 Best regards, Alexander. -- Comment By: Aaron Swartz (aaronsw) Date: 2006-02-13 07:44 Message: Logged In: YES user_id=122141 Since the indenting was off above, I've attached the code. -- Comment By: Aaron Swartz (aaronsw) Date: 2006-02-13 07:41 Message: Logged In: YES user_id=122141 I've also tested it on FreeBSD and it has the same problem (Segmentation fault (core dumped)). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1430436&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 16:29
Message generated for change (Comment added) made by qbarnes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&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.4
Status: Open
Resolution: None
Priority: 9
Submitted By: Quentin Barnes (qbarnes)
Assigned to: Thomas Wouters (twouters)
Summary: string parameter to ioctl not null terminated, includes fix
Initial Comment:
I ran across this problem in Python 2.3.3 and see it is
still there in 2.4.2.
When running the test_pty.py test case, I would get
intermittant failures depending on how the test was
invoked or the compiler flags used on Solaris.
Trussing the interpreter while running the test revealed:
ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL
There was garbage on the end of the string when it
would fail.
I tracked the problem back to fcntl_ioctl() in
fcntlmodule.c. The string was not being NULL
terminated, but relied on having zeroed gargage on the
stack to work.
I checked the source for 2.4.2 and noticed the same
problem. Patch to fix the problem is attached.
--
>Comment By: Quentin Barnes (qbarnes)
Date: 2006-02-19 18:31
Message:
Logged In: YES
user_id=288734
I've practically never used python. I just found
this bug in the interpreter while porting the
tool to the current Solaris compiler release, so please
keep that in mind about my lack of python knowledge.
I also have no idea who's who as well in the python
world so forgive me if I've stepped on anyone's
toes.
I don't follow the remark about "making ioctl
'safe'". I never said anything about making it
"safe". It's about a bug.
I also never said anything about the interpreter
crashing. The interpreter never crashed. The
pty test just simply failed since the module
name passed to the OS's ioctl was corrupted.
Are you sure you responded to the right bug
report with these remarks?
Anyways...
This problem should be reduced to a classic
data marshaling problem between python data
space and C data space which should have already
been addressed in many contexts many times before
in the interpreter. How are python strings
converted for use by C in similar situations?
This problem I encountered is either a bug in
the code that passed the string to the ioctl
service by not putting an explicit '\0' on the
end of the "ptem" string, or it is a bug in the
fcntlmodule.c which should have done it for it.
Which is it?
If a python code isn't expected to put a literal
null at the end of their string when passing to
a C service, then ioctl needs to be fixed similar
to the way in my patch.
As for null-terminating other raw data, I don't
see the point other than a defensive programming
practice.
The problem I ran across is limited to just
a data marshaling problem. The patch only
touched the case when the type of data passed
to ioctl is known to be a string.
As for the buffer vs. documentation, the
buffer could be changed to 1025 for the string
case, or the documentation could be updated
to clarify that, unlike raw data, strings are
limited to 1023 to leave room for the
requisite null that conversion to a C string
requires. I don't think anyone would care
either way as long as it is qualified.
Since python strings serve dual roles of being
both raw data and being just textual containers,
one can't assume that a string passed to ioctl
is always meant to be just a textual string. Going
the 1025 route is probably a 'better' approach due to
python string's duality.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2006-02-19 14:03
Message:
Logged In: YES
user_id=6380
One problem with ioctl() is that the required length of the
buffer is unknown unless you parse the operation code
argument in a very platform- (and probably even kernel- and
driver-) dependent way. Whether null-terminating it makes
sense or not depends on the particular operation code.
I don't think the patch makes ioctl "safe", and I'm not sure
it even ought to be applied. A quick code review reveals a
few more issues:
- the docstring doesn't explain the optional "mutate_flag"
argument (which BTW is a mess -- read the online docs -- why
are we changing the default to true?)
- the online docs ought to be updated for 2.4 and again for
2.5 -- they still speak of 2.4 in the future tense! Also,
it's a bit strong to say this function is "identical" to
fcntl() -- "similar" sounds more like it.
- In the first branch of the function, this line:
if (mutate_arg && (len < sizeof buf)) {
ought to test (len <= sizeof buf) to match the test earlier;
but probably better is to use
if (mutate_arg && arg == buf) {
- If
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 17:29 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433877&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.4 Status: Open Resolution: None Priority: 9 Submitted By: Quentin Barnes (qbarnes) Assigned to: Thomas Wouters (twouters) Summary: string parameter to ioctl not null terminated, includes fix Initial Comment: I ran across this problem in Python 2.3.3 and see it is still there in 2.4.2. When running the test_pty.py test case, I would get intermittant failures depending on how the test was invoked or the compiler flags used on Solaris. Trussing the interpreter while running the test revealed: ioctl(4, I_PUSH, "ptem\xff^T^F^H") Err#22 EINVAL There was garbage on the end of the string when it would fail. I tracked the problem back to fcntl_ioctl() in fcntlmodule.c. The string was not being NULL terminated, but relied on having zeroed gargage on the stack to work. I checked the source for 2.4.2 and noticed the same problem. Patch to fix the problem is attached. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 00:04 Message: Logged In: YES user_id=6380 Sorry for the confusion. I was in part responding to an off-line discussion I had with Neal Norwitz, to which you weren't a party. You can ignore my comments about safety and crashing. The difference in marshalling Python data to C data for ioctl(), compared to the many other places where (indeed) this problem has been solved before, is that almost everywhere else, we *know* what the data is supposed to mean. C has many more data types than Python, and the choice of how to convert a string, or an int, to C data depends on what is expected by the receiver of the C data. Unfortunately for ioctl we don't know the required C data type because it's defined by the kernel module that handles the particular ioctl opcode. Some of these (like the one you apparently ran into when porting the pty code to Solaris) require a null-terminated string; others (like the classic tty ioctls) require a C structure, which in Python can be created by using the struct module. Both return Python strings. I tend to agree with your conclusion that we should extend the buffer to 1025 bytes and not bother null-terminating non-string data. Would you like to attempt another patch? -- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-19 19:31 Message: Logged In: YES user_id=288734 I've practically never used python. I just found this bug in the interpreter while porting the tool to the current Solaris compiler release, so please keep that in mind about my lack of python knowledge. I also have no idea who's who as well in the python world so forgive me if I've stepped on anyone's toes. I don't follow the remark about "making ioctl 'safe'". I never said anything about making it "safe". It's about a bug. I also never said anything about the interpreter crashing. The interpreter never crashed. The pty test just simply failed since the module name passed to the OS's ioctl was corrupted. Are you sure you responded to the right bug report with these remarks? Anyways... This problem should be reduced to a classic data marshaling problem between python data space and C data space which should have already been addressed in many contexts many times before in the interpreter. How are python strings converted for use by C in similar situations? This problem I encountered is either a bug in the code that passed the string to the ioctl service by not putting an explicit '\0' on the end of the "ptem" string, or it is a bug in the fcntlmodule.c which should have done it for it. Which is it? If a python code isn't expected to put a literal null at the end of their string when passing to a C service, then ioctl needs to be fixed similar to the way in my patch. As for null-terminating other raw data, I don't see the point other than a defensive programming practice. The problem I ran across is limited to just a data marshaling problem. The patch only touched the case when the type of data passed to ioctl is known to be a string. As for the buffer vs. documentation, the buffer could be changed to 1025 for the string case, or the documentation could be updated to clarify that, unlike raw data, strings are limited to 1023 to leave room for the requisite null that conversion to a C string requires. I don't think anyone would care either way as long as it is qualified. Since python strings serve dual roles of being both raw data and being just textual containers, one can't assume that a string passe
