[ python-Bugs-666700 ] os.popen+() can take string list and bypass shell.
Bugs item #666700, was opened at 2003-01-12 13:45 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=666700group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 12:19 Message: Logged In: YES user_id=752496 Jeremy, could you please provide a patch for the docs? Thanks! -- Comment By: Jeremy Fincher (jemfinch) Date: 2005-01-11 12:08 Message: Logged In: YES user_id=99508 Yes, I believe it should. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Should this be fixed in 2.4? Now we have the subprocess module. -- Comment By: Facundo Batista (facundobatista) Date: 2005-01-11 00:34 Message: Logged In: YES user_id=752496 Please, could you verify if this problem persists in Python 2.3.4 or 2.4? If yes, in which version? Can you provide a test case? If the problem is solved, from which version? Note that if you fail to answer in one month, I'll close this bug as Won't fix. Thank you! .Facundo -- Comment By: Jeremy Fincher (jemfinch) Date: 2003-09-23 19:34 Message: Logged In: YES user_id=99508 Can I second that the documentation should definitely be updated to reflect this possibility, even if it's only available on *nix-like systems? This is something that many other languages in the same realm as Python (Perl, PHP, etc.) support and document, and I can't see any good reason why we *shouldn't* document a more secure way to give data to external programs. -- Comment By: Bernhard Herzog (bernhard) Date: 2003-08-05 13:04 Message: Logged In: YES user_id=2369 Given that the command as list of strings feature only works on Unix-like systems, ISTM it should perhaps only be documented for the PopenN classes. Maybe the documentation for the functions should state that on unix they accept lists of strings, though. -- Comment By: Dani (asqui) Date: 2003-01-12 13:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=666700group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1099516 ] tempfile files not types.FileType
Bugs item #1099516, was opened at 2005-01-10 10:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1099516group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Frans van Nieuwenhoven (vannieuwenhoven) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile files not types.FileType Initial Comment: a temporary file created with the tempfile module is not recognized as a types.FileType testcase: import types import tempfile # this will return False (I think it should return True) isinstance(tempfile.TemporaryFile(), types.FileType) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-11 10:36 Message: Logged In: YES user_id=80475 Clarified the doc strings, noting that a file-like object is returned rather than an actual file. Instead of type checking the object, it is a better practice to use duck typing where you check for required methods (the interface) instead of an actual type or subtype. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1099516group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Bugs item #1086642, was opened at 2004-12-16 19:21 Message generated for change (Comment added) made by akosprime You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1086642group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: _SS_ALIGNSIZE redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension -- Comment By: A. Stocker (akosprime) Date: 2005-01-11 15:48 Message: Logged In: YES user_id=1179755 Okay, I tried compiling using the Irix Mips compilers. To do this I did a ./configure --without-gcc. However when attempting to make it errored out. Here is the last section of the make output: ar cr libpython2.4.a Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o ar cr libpython2.4.a Modules/threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/zipimport.o Modules/symtablemodule.o Modules/xxsubtype.o : libpython2.4.a c++ -o python Modules/python.o libpython2.4.a -lsocket -lnsl -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libsocket.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libnsl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: FATAL 9 : I/O error (-lmpc): No such file or directory collect2: ld returned 32 exit status *** Error code 1 (bu21) The patch is relatively the same as the hack I tried earlier, and noted in a follow-up. But as pointed out test_socketserver doesn't work (Use of the `network' resource not enabled) and _locale doesn't work (*** WARNING: renaming _locale since importing it failed: 1774654:./python: rld: Fatal Error: unresolvable symbol in build/lib.irix64-6.5-2.4/_locale.so: libintl_dcgettext) I'm not sure what else to try in order to get this working. -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 16:44 Message: Logged In: YES user_id=71407 Some additional observations: socketmodule.c compiles with gcc 3.3 under IRIX 6.5.21 after applying this simple-minded patch (relative to Python 2.4): --- socketmodule.c.orig 2004-11-07 06:24:25.0 - 0800 +++ socketmodule.c 2004-12-30 08:06:01.896160200 - 0800 @@ -280,6 +280,10 @@ # include addrinfo.h #endif +#if
[ python-Bugs-1095802 ] Macintosh references in the docs need to be checked.
Bugs item #1095802, was opened at 2005-01-04 16:14 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1095802group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Brett Cannon (bcannon) Summary: Macintosh references in the docs need to be checked. Initial Comment: As of 2.4 Python no longer runs on MacOS9 or earlier. We need to go through all the documentation loooking for references to macintosh, mac, apple, macos and such to check whether these references are still valid. -- Comment By: Jack Jansen (jackjansen) Date: 2005-01-11 16:54 Message: Logged In: YES user_id=45365 Brett, can I coerce you into reviewing this patch? If not assign back to me and I'll find another victim... -- Comment By: Jack Jansen (jackjansen) Date: 2005-01-06 10:59 Message: Logged In: YES user_id=45365 Macintosh is fine as a reference, but we need to check that the tekst is actually relevant to OSX. There may be lots of things that can go, referring to non-virtual memory or :-separated filenames, or resource forks, or whatever. Or, at the very least, it may need rewording. As to darwin: I wouldn't cater for that. Technically it's nice to support it, but I'd be surprised if there were a 1000 people out there actually running it. -- Comment By: Brett Cannon (bcannon) Date: 2005-01-06 08:21 Message: Logged In: YES user_id=357491 Should we change the mentions to OS X or darwin? It would help remove any possible misunderstanding of OS 9 support and make sure we caught all doc mentions. Could also help specify and difference between Darwin and OS X explicitly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1095802group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100235 ] Scripts started with CGIHTTPServer: missing cgi environment
Bugs item #1100235, was opened at 2005-01-11 11:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1100235group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: pacote (pacote)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scripts started with CGIHTTPServer: missing cgi environment
Initial Comment:
With Python 2.4 only (2.3 works fine). Tested on
Windows 2000.
In run_cgi, sys.environ is updated with cgi variables
(QUERY_STRING, etc.)
but it seems that this environment is not passed to the
child process.
On Windows os.popen3 is used but something must have
changed in that function that is causing this regression.
The attached patch fixes this using the subprocess module.
It fixes also (I think) bug 1088039
(directories/scripts with spaces in their name).
Supports too Python installed in a directory with a
space (e.g. Program Files).
Patch note: the subprocess test (have_subprocess) is
kind of awkward: is there a better way to do this?
Diff follows, complete script attached.
-
--- C:\apps\Python24\Lib\CGIHTTPServer-old.py Mon Aug
30 09:38:16 2004
+++ C:\apps\Python24\Lib\CGIHTTPServer.py Tue Jan 10
19:45:09 2005
@@ -234,18 +234,16 @@
elif self.have_popen2 or self.have_popen3:
# Windows -- use popen2 or popen3 to
create a subprocess
+import subprocess
import shutil
-if self.have_popen3:
-popenx = os.popen3
-else:
-popenx = os.popen2
-cmdline = scriptfile
+
+cmdline = '%s' % scriptfile
if self.is_python(scriptfile):
interp = sys.executable
if interp.lower().endswith(w.exe):
# On Windows, use python.exe, not
pythonw.exe
interp = interp[:-5] + interp[-4:]
-cmdline = %s -u %s % (interp, cmdline)
+cmdline = '%s -u %s' % (interp, cmdline)
if '=' not in query and '' not in query:
cmdline = '%s %s' % (cmdline, query)
self.log_message(command: %s, cmdline)
@@ -253,11 +251,11 @@
nbytes = int(length)
except (TypeError, ValueError):
nbytes = 0
-files = popenx(cmdline, 'b')
-fi = files[0]
-fo = files[1]
-if self.have_popen3:
-fe = files[2]
+
+p = subprocess.Popen(cmdline,
stdin=subprocess.PIPE, stdout=subprocess.PIPE,
+
stderr=subprocess.PIPE, env=os.environ)
+(fi, fo, fe) = (p.stdin, p.stdout, p.stderr)
+
if self.command.lower() == post and
nbytes 0:
data = self.rfile.read(nbytes)
fi.write(data)
@@ -267,16 +265,16 @@
break
fi.close()
shutil.copyfileobj(fo, self.wfile)
-if self.have_popen3:
-errors = fe.read()
-fe.close()
-if errors:
-self.log_error('%s', errors)
+errors = fe.read()
+fe.close()
+if errors:
+self.log_error('%s', errors)
sts = fo.close()
if sts:
self.log_error(CGI script exit status
%#x, sts)
else:
self.log_message(CGI script exited OK)
+del p
else:
# Other O.S. -- execute script in this process
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1100235group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1095822 ] Apple-installed Python fails to build extensions
Bugs item #1095822, was opened at 2005-01-04 16:43 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1095822group_id=5470 Category: Macintosh Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Apple-installed Python fails to build extensions Initial Comment: Apple-installed Python 2.3 (on Mac OS X 10.3) can no longer build extension modules after a newer framework build has been installed. This happens because it will build extensions with -framework Python, which will actually link against the newer framework (be it 2.3.X or 2.4 or later) that is in /Library in stead of against it's own framework in /System/Library. After over a year of debating multiple solutions the Pythonmac-SIG consensus is that linking extensions with -undefined dynamic_lookup in stead of against the framework is the best solution. All of 2.5a0, 2.4.1 and 2.3.5 will detect the fact that they are being run on a machine that has an Apple-installed python that needs to be patched, and apply that patch. A standalone patch installer will also be made available. In addition, 2.5a0, 2.4.1 and 2.3.5 themselves will also use the -undefined dynamic_lookup method of linking when running on 10.3 or later (unless the user has specifically set MACOSX_DEPLOYMENT_TARGET to 10.2 or earlier). -- Comment By: Jack Jansen (jackjansen) Date: 2005-01-11 17:08 Message: Logged In: YES user_id=45365 All three of 2.3.X, 2.4.X and 2.5a0 now link extensions in a way that makes them either portable between Pythons (10.3 or later) or at least work in the face of other installed Pythons (10.2 or earlier). In addition, doing a frameworkinstall of either 2.3.X, 2.4.X or 2.5a0 will test whether an unpatched Apple-installed Python sits on the machine, and if there is it will warn the user to apply a patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1095822group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1098985group_id=5470 Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-11 13:12 Message: Logged In: YES user_id=11365 Thanks for the quick work Raymond! I see you have added a test case too. I am attaching a patch which implements this change in a different style, based on setobject.h publicly advertising that v-data is a dictionary for any set object v. It passes the new test code (and the rest of the test suite). -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. -- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so would be nice is as strong as it gets. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1098985group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100366 ] Frame does not receive configure event on move
Bugs item #1100366, was opened at 2005-01-11 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1100366group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Anand Kameswaran (akameswaran) Assigned to: Martin v. Löwis (loewis) Summary: Frame does not receive configure event on move Initial Comment: Python : 2.4 OS: WInXP sp2. I have created a frame attached to a Tk(). The frame is bound to the configure sequence. However, the frame does not get a configure on a move, but does get a configure event on a resize. This seems odd as the root does get an event for both resize and move, but only forwards one of them. I have included a sample of the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1100366group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100368 ] Wrong type() syntax in docs
Bugs item #1100368, was opened at 2005-01-11 16:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1100368group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Facundo Batista (facundobatista) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong type() syntax in docs Initial Comment: From the current docs: type(object): Return the type of an object. The return value is a type object. From the interpreter: help(type) Help on class type in module __builtin__: class type(object) | type(object) - the object's type | type(name, bases, dict) - a new type In the documentation is missing the second syntax form. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1100368group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1098985group_id=5470 Category: Python Library Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 4 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-11 15:39 Message: Logged In: YES user_id=80475 I prefer the existing code though it is slightly inefficient (creating an intermediate tuple whose size is known in advance and whose elements are known to be unique). IMO, this beats breaking the encapsulation of the set object structure (knowledge of the v-data field and knowledge that the dict values are set to True). I want to preserve the option for sets to be possibly re-implemented without an underlying dictionary. Someday, I'll craft a C API for sets. It will include an ability to build-up the values element by element. P.S. The code in the attachment needs error checking for the call to PyDict_SetItem(). -- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-11 13:12 Message: Logged In: YES user_id=11365 Thanks for the quick work Raymond! I see you have added a test case too. I am attaching a patch which implements this change in a different style, based on setobject.h publicly advertising that v-data is a dictionary for any set object v. It passes the new test code (and the rest of the test suite). -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 22:03 Message: Logged In: YES user_id=80475 Then let things be nice for all. See Python marshal.c 1.81. -- Comment By: Tim Peters (tim_one) Date: 2005-01-10 20:51 Message: Logged In: YES user_id=31435 Just noting that some people prefer to use marshal instead of pickle because unmarshaling can't end up executing arbitrary user-defined code (but unpickling can, via arbitrary module importing and arbitrary construction of objects of user- defined classes). That's really not one of marshal's goals, though, so would be nice is as strong as it gets. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-01-10 19:25 Message: Logged In: YES user_id=6380 As the OP says, it would be nice. Let's see if he or someone else wants it bad enough to submit a patch. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-10 19:17 Message: Logged In: YES user_id=80475 Guido, what to you think about the OP's request? The need does not arise for pyc files and pickling takes care of general persistance needs. Is there something to be gained? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1098985group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100429 ] TarFile iteration can break (on Windows) if file has links
Bugs item #1100429, was opened at 2005-01-11 11:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1100429group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: TarFile iteration can break (on Windows) if file has links Initial Comment: I ran into this with a simple loop trying to detar Pyrex-0.9.3: for info in tarfile: tarfile.extract(info) I called the above immediately after calling tarfile.open, so the returned iterator was an instance of TarIter. The problem is that Pyrex includes some symbolic links. When TarFile.makelink finds that os.symlink is missing (on Windows) it then does getmember to find the info for the referenced file. The getmember method results in a call to getmembers, which loads all the infos into the members list. However, this breaks the TarIter, since it assumes the members have not yet been loaded. Not sure what the best fix for this is; in my script, I switched over to using getmembers rather than the iterator. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1100429group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1019882 ] hotshot start / stop stats bug
Bugs item #1019882, was opened at 2004-08-31 18:06 Message generated for change (Comment added) made by alecf You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1019882group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: hotshot start / stop stats bug Initial Comment: Hotshot has a bug that manifests when using start/stop instead of run(), however it appears to only occur in the interactive interpreter or in an embedded application. If you run the attached program like python hotshotbug.py it works just fine. However, if you start an interactive session and paste each line one by one into the shell, you get the following exception: Traceback (most recent call last): File stdin, line 1, in ? File /usr/local/lib/python2.3/hotshot/stats.py, line 12, in load return StatsLoader(filename).load() File /usr/local/lib/python2.3/hotshot/stats.py, line 29, in load for event in log: File /usr/local/lib/python2.3/hotshot/log.py, line 110, in next return what, self._pop(), tdelta IndexError: pop from empty list We discovered this when trying to profile an embedded application which doesn't have a single entrypoint suitable for run(). Unfortunately, I can't provide that application, but it shouldn't matter, since the interpreter crash is the same. -- Comment By: Alec Flett (alecf) Date: 2005-01-11 23:05 Message: Logged In: YES user_id=21804 So does this mean there is no decent way to use start() or stop() if they are not called within the same stackframe? I've noticed this by trying to analyze prof files with external python scripts - i.e. I generate the profile in one program, and try to open it in another for analysis. Its the 2nd program that tries to open it that gets the crash. -- Comment By: Greg Chapman (glchapman) Date: 2004-11-09 03:26 Message: Logged In: YES user_id=86307 Not sure about the embedded application, but I believe the problem with the interactive interpreter is that you're executing a code snippet (p.start()) which calls the function to enable the profiler, and then does a return from PyEval_EvalFrame. This means the first event the profiler sees will be the return, without having previosly seen a call (since when PyEval_EvalFrame was entered, profiling was not yet started). The LogReader class assumes that a return event must have been preceeded by a corresponding call event so that it can pop the previously pushed information. You can get the same crash with a simple: p.start() p.stop() and then try to load the stats. By the way, with Python2.4b1, the example does not crash when executed non-interactively from the command line (at least on my Windows XP system). -- Comment By: Robert Brewer (aminusfu) Date: 2004-10-05 17:45 Message: Logged In: YES user_id=967320 I get the same traceback even when not running interactively. I can provide .prof files if needed. [EMAIL PROTECTED] -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-09-27 14:42 Message: Logged In: YES user_id=12800 Could this be related to 900092? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1019882group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086603 ] segfault in readline
Bugs item #1086603, was opened at 2004-12-16 19:02
Message generated for change (Comment added) made by sonderblade
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1086603group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: DSM (dsm001)
Assigned to: Nobody/Anonymous (nobody)
Summary: segfault in readline
Initial Comment:
It's possible to produce segfaults using two functions
from the
readline module by giving them negative values (GNU
readline 4.3-10),
at least in some circumstances.
Python 2.5a0 (#10, Dec 15 2004, 19:53:33)
[GCC 3.3.3 (Debian 20040401)] on linux2
Type help, copyright, credits or license for
more information.
import readline
[25290 refs]
readline.remove_history_item(-1)
Segmentation fault
readline.replace_history_item(-1,'abc')
Segmentation fault
gdb reveals it happens because the (external)
remove_history and replace_history_entry don't return
NULL in these cases. I'm not sure whether we're
responsible for checking the sanity of inputs or the
GNU code should be returning NULL and isn't, but at
least sometimes it doesn't.
--
Comment By: Björn Lindqvist (sonderblade)
Date: 2005-01-12 00:07
Message:
Logged In: YES
user_id=51702
I can confirm the bug with readline 4.3 and Python 2.5a0
(#1, Jan 11 2005, 23:22:16). dsm001's patch fixes it.
--
Comment By: DSM (dsm001)
Date: 2004-12-31 03:32
Message:
Logged In: YES
user_id=1175690
This one being simple enough for the likes of me to patch, I
did so -- 1093585. Let the school of hard knocks begin!
--
Comment By: George Yoshida (quiver)
Date: 2004-12-20 11:57
Message:
Logged In: YES
user_id=671362
I'm +1 for sanity checking rather than waiting for the GNU
readline to return NULL in these functions.
It's just adding a few lines of code right after
PyArg_ParseTuple :
if (entry_number 0) {
PyErr_SetString(PyExc_ValueError,
index cannot be a negative value);
return NULL;
}
Then you can work around the problem without worrying
about the return value of remove_history nor
replace_history_entry.
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-19 17:41
Message:
Logged In: YES
user_id=6656
Do you want to fix it then? :) I can't imagine it's that hard, but it would
be easier for someone who can test that their fix helps...
--
Comment By: George Yoshida (quiver)
Date: 2004-12-18 11:45
Message:
Logged In: YES
user_id=671362
FYI, I can reproduce this with :
- Python 2.4 readline 4.3 under SuSE 9.1
- Python 2.5(snapshot as of 2004-12-17) readline 4.3 under
SuSE 9.1
- Python 2.4 readline 4.3.5(?) under Cygwin
--
Comment By: Michael Hudson (mwh)
Date: 2004-12-17 15:18
Message:
Logged In: YES
user_id=6656
Hmm. I can't reproduce this (also with readline 4.3). Odd.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1086603group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin
Bugs item #1084766, was opened at 2004-12-14 00:41 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1084766group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File string, line 1, in ? IOError: [Errno 21] Is a directory -- Comment By: Björn Lindqvist (sonderblade) Date: 2005-01-12 03:16 Message: Logged In: YES user_id=51702 A trivial solution is to move the lines _PyExc_Init(); _PyImport_FixupExtensions(exceptions, exceptions); above the block that begins with sysmod = _PySys_Init(); Then when the interpreter is run with python . it outputs: Fatal Python error: Py_Initialize: can't initialize sys Avbruten (SIGABRT) I don't know if that is a good solution. -- Comment By: Jeff Epler (jepler) Date: 2004-12-19 04:25 Message: Logged In: YES user_id=2772 Duplicated here on a stale CVS version of 2.4. Here's some information from gdb: Starting program: /usr/src/cvs/python/dist/src/python -S -c '' / [Thread debugging using libthread_db enabled] [New Thread -151074304 (LWP 6154)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074304 (LWP 6154)] 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 549 Py_INCREF(value); (gdb) where #0 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 #1 0x08075e13 in PyDict_SetItemString (v=0xf6fae79c, key=0x8109d60 stdin, item=0x0) at Objects/dictobject.c:1988 #2 0x080d6988 in _PySys_Init () at Python/sysmodule.c:961 #3 0x080d3e17 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:190 #4 0x080d5815 in Py_Initialize () at Python/pythonrun.c:283 #5 0x08055159 in Py_Main (argc=4, argv=0xfefac1b4) at Modules/main.c:418 #6 0x08054e0f in main (argc=4, argv=0xfefac1b4) at Modules/python.c:23 The problem seems to be that PyFile_FromFile() returns NULL without tripping the PyErr_Occurred() test on my line 946 of sysmodule.c, because the call to fill_file_fields() returns NULL too. It looks like fill_file_fields is supposed to return NULL with an error set, but when dircheck() is called that early, PyExc_IOError is NULL, so no error is set. Maybe _PyExc_Init() must be moved earlier in startup. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1084766group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1100673 ] Python Interpreter shell is crashed
Bugs item #1100673, was opened at 2005-01-12 11:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1100673group_id=5470
Category: Python Interpreter Core
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: abhishek (abhishekkabra)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python Interpreter shell is crashed
Initial Comment:
I faced this problem about 50 % of time when I hit
follwing commands on python shell.
But I think Crash of interpreter is not a expected
behaviour. It should throw some error even if I am
wrong/ hitting wrong commands
1. on shell of linux start python
2 On python shell hit _doc__
( underscore doc underscore
underscore )
So Python shell is crashed with following crash dump
darwin{akabra}6: python
Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type help, copyright, credits or license for
more information.
_doc__Segmentation fault (core dumped)
darwin{akabra}7:
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1100673group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
