[ python-Bugs-1093173 ] distutils/tests not installed
Bugs item #1093173, was opened at 2004-12-30 09:43 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=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093173 ] distutils/tests not installed
Bugs item #1093173, was opened at 2004-12-30 10:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 15:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&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-1092962 ] Make Generators Pickle-able
Feature Requests item #1092962, was opened at 2004-12-29 22:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayson Vantuyl (jaysonvantuyl) Assigned to: Nobody/Anonymous (nobody) Summary: Make Generators Pickle-able Initial Comment: Would it be possible to make generators pickle-able? I mean, currently the internal state is saved in some way. Would it be possible to make pickle handle them? Put another way, if generators had a __getnewargs__ function that returned some data (say a tuple of module name, function name, locals/globals dicts and some code dependent location data) and then allow: generator.__new__(statedata) to reconstruct it (or something more elegant). -- >Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 15:16 Message: Logged In: YES user_id=21627 Moving into the feature requests tracker. I don't think this is possible (or should be done if it were possible). Pickle has traditionally abstained from pickling functions, so IMO it should not picke generators, either. If this was enabled by default, it would open up yet another security hole. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_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 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_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: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. -- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_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 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_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: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. -- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined. So I put the #define statement from the addrinfo.h file directly in the socketmodule.c file and the compilation with _socket worked. However this seems to be a clunky way to deal with the situation. Plus I don't know if there's anything else like this biting me in the butt (for instance '_locale' doesn't compile either.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_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 11:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086642&group_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: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08: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 defined(__sgi) && defined(__GNUC__) && !defined (NI_NUMERICHOST) +# define NI_NUMERICHOST 0x0002 +#endif + #ifndef HAVE_INET_PTON int inet_pton(int af, const char *src, void *dst); const char *inet_ntop(int af, const void *src, char *dst, socklen_t size); This test works OK: ./python Lib/test/test_socket.py But this one doesn't: ./python Lib/test/test_socketserver.py -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 08:38 Message: Logged In: YES user_id=71407 FWIW: socketmodule.c included in Python 2.3.4 also fails to compile with gcc. Platform: IRIX 6.5.21, gcc 3.3 from SGI's freeware distribution. -- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2004-12-30 07:28 Message: Logged In: YES user_id=71407 Martin v. Loewis asked me to take a look (because of my involvement in http://python.org/sf/728330). I never use gcc under IRIX. Python 2.4 works just fine with the native IRIX compilers. Suggestion to A. Stocker: try to modify the ifdef's in socketmodule.c to do the right thing for gcc 3.3. I can test your patch on our machines to make sure compilation with the native compilers is still OK. -- Comment By: A. Stocker (akosprime) Date: 2004-12-22 06:19 Message: Logged In: YES user_id=1179755 All, I decided to force the issue a bit. Looking through socketmodule.c I noticed that there was an SGI specific check that basically disabled loading the addrinfo.h file, which is where NI_NUMERICHOST is defined.
[ python-Bugs-1093389 ] mapitags.PROP_TAG() doesn't account for new longs
Bugs item #1093389, was opened at 2004-12-30 11:36 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=1093389&group_id=5470 Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Joe Hildebrand (hildjj) Assigned to: Nobody/Anonymous (nobody) Summary: mapitags.PROP_TAG() doesn't account for new longs Initial Comment: Test case: >>> from win32com.mapi.mapitags import * >>> PROP_TAG(PT_LONG, 0x8041) 2151743491L Should be: -2143223805L or, alternately, the rest of the mapi interfaces should know about unsigned ints. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093389&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-1092962 ] Make Generators Pickle-able
Feature Requests item #1092962, was opened at 2004-12-29 21:52 Message generated for change (Comment added) made by jaysonvantuyl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1092962&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jayson Vantuyl (jaysonvantuyl) Assigned to: Nobody/Anonymous (nobody) Summary: Make Generators Pickle-able Initial Comment: Would it be possible to make generators pickle-able? I mean, currently the internal state is saved in some way. Would it be possible to make pickle handle them? Put another way, if generators had a __getnewargs__ function that returned some data (say a tuple of module name, function name, locals/globals dicts and some code dependent location data) and then allow: generator.__new__(statedata) to reconstruct it (or something more elegant). -- >Comment By: Jayson Vantuyl (jaysonvantuyl) Date: 2004-12-30 18:37 Message: Logged In: YES user_id=626872 I'm not talking about pickling functions. Which, by the way, is not entirely accurate. See the following: >>> from pickle import dumps,loads >>> loads(dumps(dumps)) >>> As you see, we don't pickle the function code, just a reference to it. I propose doing the same with generators, but including the function namespace and frame info in the pickle to allow it to continue execution after unpickling. Furthermore, this is nothing more than what the interpreter already does internally. When a generator yields, all of its state is neatly stashed away. I just would like pickle to be able to get at it, store it, and then later recover it--without dealing with any actual code objects, just the state. As for security, what I am talking about is nothing more or less secure than pickling classes. When we pickle a class, we don't pickle the methods on it. Rather, we pickle the information to reconstruct the class (__getstate__, __getnewargs__, __reduce__). There is a security concern in that modified pickles could be used to put bogus data into the unpickled classes (i.e. a password stored as an attribute on a class could be replaced). What I'm asking for is nothing more than pickling a form of the frozen frame object (or something akin to it) for the generator. Put another way, when the generator isn't running, something stores the entire state of its execution. I'm not sure what it is, but I'd be willing to be it consists of little more than a few dicts (namespaces), some scoping info, and some sort of instruction pointer. By pickling the generator, I propose nothing more radical than pickling a class. The generator is still instantiated from the some code as before (just as a class or function reference is) and it still can/will act on that information (just as a class does). No actual code is pickled. What this does allow is the use of generators for efficent handling of a class. Specifically, I'm writing an application that uses a seeded pseudo-random number generator. The idea is to transmit the state of the generator over the network so that the client/server can deterministically make the same random choices without communicating the complex state that results from that. I have a choice of the following: def randfunc(seed,num,otherstate): # Costly Setup # Iteration to appropriate number otherside.sendPickle( (seed,num,otherstate,) ) l = [ randfunc(123,i,...) for i in range(5) ] Versus def randGen(seed): # Costly Setup # yield in a simple loop r = randGen(123) otherside.sendPickle(r) l = [ r() for i in range(5) ] I think you can see which one is more efficient in terms of both simplicity of expression and ease of coding. Of course, the standard answer to this is to implement a randgen class that contains all of the state. This complicates the code a great deal, since a generator can't be used. What is problematic is that generators are like black holes. Once information goes into them, it won't come back out. There's not a good way to use them for anything more than runtime. This rules out things like process migration, pickling of any structure involving generator data, and generally using them like any other language component. Using them for counters, prngs, prime number generators, OGR sieves, and anything that needs to be used to durably generate a sequence is impossible if that data needs to be persisted. No one would think about implementing a new pickle without the ability to represent classes and function references, generators shouldn't be second class control structures. FYI, Stackless Python already does this, but it may be easier for them due to the way they've modified frame handling. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 14:16 Message: Logged In: YES user_id=21627 Moving into the feature
[ python-Bugs-1090139 ] presentation typo in lib: 6.21.4.2 How callbacks are called
Bugs item #1090139, was opened at 2004-12-22 20:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jesse Weinstein (weinsteinj) Assigned to: Raymond Hettinger (rhettinger) Summary: presentation typo in lib: 6.21.4.2 How callbacks are called Initial Comment: On the page: http://docs.python.org/lib/optparse-how-callbacks-called.html the text: args should be changed to: args to match the rest of the items on the page. This may require changing the LaTeX. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-30 20:08 Message: Logged In: YES user_id=80475 Fixed. Thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1090139&group_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 13:02
Message generated for change (Comment added) made by dsm001
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1086603&group_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: DSM (dsm001)
Date: 2004-12-30 21: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 05: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 11: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 05: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 09: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=detail&atid=105470&aid=1086603&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
