[ python-Bugs-416288 ] infrequent memory leak in pyexpat
Bugs item #416288, was opened at 2001-04-15 19:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&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: XML Group: None Status: Open Resolution: None Priority: 2 Submitted By: douglas orr (dougbo) >Assigned to: Nobody/Anonymous (nobody) Summary: infrequent memory leak in pyexpat Initial Comment: In pyexpat.c, the macro call for the handler dispatch (my##NAME##Handler) for CharacterHandler allocates an object implicitly by calling one of the conversion-to- unicode routines. If there is a problem in the PyBuildValue, resulting in args == NULL, that object will be leaked. Low priority, but the macros probably need some reworking to handle this. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 10:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2002-03-29 00:20 Message: Logged In: YES user_id=21627 No, currently, it can only leak: the argument being passed will have an extra ref count, which supposedly will be consumed by the tuple. If something fails, some of the N arguments will have been stored in the tuple-under-construction, and will be released when the tuple is released. 'N' arguments not yet consumed will leak. Processing should continue in case of an error, and DECREF all N arguments. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-28 23:34 Message: Logged In: YES user_id=6380 Hm, the 'N' format code looks really scary. Can't it end up DECREF'ing an object too many times if something fails? -- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 13:48 Message: Logged In: YES user_id=21627 That seems to be a bug in Py_BuildValue: It should decref its N arguments if it can't create a tuple. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-451607 ] SSL support in socket module needs tests
Bugs item #451607, was opened at 2001-08-16 18:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&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: None Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 10:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 10:51 Message: Logged In: YES user_id=21627 I don't think this is relevant here: OpenSSL uses whatever device it uses; we need not to concern ourselves with OpenSSL's choice. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 10:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 10:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. -- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 20:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 21:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. -- Comment By: paul rubin (phr) Date: 2001-10-11 20:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 20:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options: - wait for, then require OpenSSL 0.9.7. It will look for a prngd socket in default locations (/var/run/egd-pool, /dev/egd-pool, /etc/egd-pool and /etc/entropy); then require administrators to set up OpenSSL that it indeed finds a prngd in these locations when needed. - expose RAND_add. Exposing any other of the interfaces is pointless; on our installation, prngd runs on localhost:708 instead of a Unix domain socket, and none of the other interfaces could use such a configuration. On top of RAND_add, we could communicate with prngd ourselves, e.g. by using the RANDFILE environment variable. -- Comment By: Martin v. Löwis (loewis)
[ python-Bugs-719888 ] tokenize module w/ coding cookie
Bugs item #719888, was opened at 2003-04-11 21:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719888&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: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Barry A. Warsaw (bwarsaw) >Assigned to: Nobody/Anonymous (nobody) Summary: tokenize module w/ coding cookie Initial Comment: The tokenize module should honor the coding cookie in a file, probably so that it returns Unicode strings with decoded characters. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 10:02 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=719888&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i
Bugs item #864379, was opened at 2003-12-22 12:40
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&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: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.3 make test core dump on HP-UX11i
Initial Comment:
I built Python-2.3.3 on HP-UX11i in the same way that I
built Python-2.3.2.
However, this time running 'make test' core dumps on
the second pass with:
test_sax
*** Termination signal 138
Stop.
The output from test_sax.py is given below. Each test
appears to fail, but the summary gives zero failures (this
also happens with Python 2.3.2, but 'make test' doesn't
core dump on that release).
> ./python ./Lib/test/test_sax.py
Failed test_attrs_empty
Failed test_attrs_wattr
Failed test_double_quoteattr
Failed test_escape_all
Failed test_escape_basic
Failed test_escape_extra
Failed test_expat_attrs_empty
Failed test_expat_attrs_wattr
Failed test_expat_dtdhandler
Failed test_expat_entityresolver
Failed test_expat_file
Failed test_expat_incomplete
Failed test_expat_incremental
Failed test_expat_incremental_reset
Failed test_expat_inpsource_filename
Failed test_expat_inpsource_location
Failed test_expat_inpsource_stream
Failed test_expat_inpsource_sysid
Failed test_expat_locator_noinfo
Failed test_expat_locator_withinfo
Failed test_expat_nsattrs_empty
Failed test_expat_nsattrs_wattr
Failed test_filter_basic
Failed test_make_parser
Failed test_make_parser2
Failed test_nsattrs_empty
Failed test_nsattrs_wattr
Failed test_quoteattr_basic
Failed test_single_double_quoteattr
Failed test_single_quoteattr
Failed test_unescape_all
Failed test_unescape_amp_extra
Failed test_unescape_basic
Failed test_unescape_extra
Failed test_xmlgen_attr_escape
Failed test_xmlgen_basic
Failed test_xmlgen_content
Failed test_xmlgen_content_escape
Failed test_xmlgen_ignorable
Failed test_xmlgen_ns
Failed test_xmlgen_pi
41 tests, 0 failures
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 10:03
Message:
Logged In: YES
user_id=21627
I don't think I will do anything about this anytime soon, so
unassigning myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-24 14:23
Message:
Logged In: YES
user_id=33168
I think I remember hearing something about an
incompatibility. The two best people to discuss this are
probably Martin v. Loewis and Fred Drake. I'm assigning to
Martin, perhaps he can shed some more light on the issues.
--
Comment By: Richard Townsend (rptownsend)
Date: 2003-12-24 13:46
Message:
Logged In: YES
user_id=200117
I have now installed Python-2.3.3 plus PyXML-0.8.3 and the
core dump in 'make test' has returned.
So, it looks like a compatability problem with PyXML-0.8.3 ?
--
Comment By: Richard Townsend (rptownsend)
Date: 2003-12-24 10:25
Message:
Logged In: YES
user_id=200117
HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user
license
This is the configure command I used:
base_inst_dir=/opt
python_link=${base_inst_dir}/python
CC=cc \
OPT="+O2 -z +Onofltacc +ESlit +Oentrysched \
+Odataprefetch +Onolimit +DA2.0" \
INSTALL="./install-sh -c" \
./configure --with-threads --without-gcc \
--with-cxx=/opt/aCC/bin/aCC --without-libd \
--with-cycle-gc --prefix=$python_link \
--exec-prefix=$python_link
This is exactly the same command I have used on previous
Python 2.3 releases which did not core dump in 'make test'.
Note it uses the native HP compiler.
I have now just rebuilt without optimisation, using:
CC=cc \
INSTALL="./install-sh -c" \
./configure --with-threads --without-gcc \
--with-cxx=/opt/aCC/bin/aCC --without-libd \
--with-cycle-gc --prefix=$python_link \
--exec-prefix=$python_link
It still core dumps at the same point in the second pass
of 'make test'.
I have attached a stack trace from the core file. I noticed
that this has references to /opt/python/lib/python2.3/site-
packages/_xmlplus/parsers/pyexpat.sl. This is the previous
installation of Python 2.3.2 plus PyXML-0.8.3.
I wondered if I had forgotten to reset $PYTHONPATH before
running 'make test', so I did that and tried again but it still
core dumped.
So next I reset the symbolic link /opt/python to the empty
directory /opt/python-2.3.3 and ran 'make test' again. This
time it didn't core dump!
So why does the test suite access the previous installation
when PYTHONPATH doesn't include it?
[ python-Bugs-896330 ] pyconfig.h is not placed in --includedir
Bugs item #896330, was opened at 2004-02-13 09:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896330&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: Installation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Göran Uddeborg (goeran) >Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h is not placed in --includedir Initial Comment: When configuring Python with an explicit --includedir most of the header files do turn up in this directory. But the pyconfig.h is still placed in $(prefix)/include. I assume it is a bug, and this file too should be placed according to --includedir. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 10:05 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Pelle Johansson (morth) Date: 2004-10-23 15:52 Message: Logged In: YES user_id=180081 Actually, pyconfig.h is placed in $(exec-prefix)/include. This is fine as the file is architecture dependant. However the other header files use a local #include "pyconfig.h" which will not match if it's not the same dir. If you like me want a common directory for all archindependant files and then separate for each arch it causes additional headache, since there's no easy way for me to symlink from the arch include/ dir to the archindependant, as they have a common subdir (python2.3/ in my case). Currently it seems I'll have to symlink each header file individually from the archindependent dir to the arch ones. Ideally pyconfig.h would be put directly in $(exec-prefix)/include/ and be refered to as . I could then just symlink the subdir. Whether to honor includedir or not I don't know, I'll leave that problem to the project. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=896330&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-995956 ] TclError with intel's hypertheading
Bugs item #995956, was opened at 2004-07-22 16:49
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&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: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Haar (thaar)
>Assigned to: Nobody/Anonymous (nobody)
Summary: TclError with intel's hypertheading
Initial Comment:
If i use the "intel hyperthreading technologie", my
python application make a coredump with the output:
File "C:\PROGRA~2\PYTHON~2\lib\lib-tk\Tkinter.py",
line 472, in after
return self.tk.call('after', ms, name)
TclError: expected integer but got "9118984callit"
The test runs at the following system.
Microsoft windows 2000 5.00.2195 Service Pack 4
Intel Pentium 4 CPU 2.5 Ghz
522.988 KB RAM.
The error never occur, if i turn the hyperthreading in
the bios off.
I made the self test at 2 other pc with the same
hardware and configurations. The result was the same.
I made another test with a linux pc, a laptop with xp
and a laptop with win2000. All without hyperthreading.
The error has not occured.
I add the log file and the test as attachment.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 10:06
Message:
Logged In: YES
user_id=21627
I don't think I will do anything about this anytime soon, so
unassigning myself.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2004-07-30 01:38
Message:
Logged In: YES
user_id=593130
I believe TclError means that the error came from the
embedded Tcl interpreter. If so, and if the Pytyhon call
ultimately feeds appropriate data to Tcl, the problem comes
not from Python but one of Tcl, Win2000, or the chip, or the
relationship between them. If you are running current Python
with current Tcl, the best we could do is add a warning to
turn off Hyperthreading if strange errors occur, but I am not
sure where.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995956&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-969718 ] BASECFLAGS are not passed to module build line
Bugs item #969718, was opened at 2004-06-09 17:56
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&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: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Beardsley (vaxhacker)
>Assigned to: Nobody/Anonymous (nobody)
Summary: BASECFLAGS are not passed to module build line
Initial Comment:
The value of BASECFLAGS from
/prefix/lib/pythonver/config/Makefile is not present on
the compile command for modules being built by
distutils ("python setup.py build"). It seems that
only the value of OPT is passed along.
This is insufficient when BASECFLAGS contains
"-fno-static-aliasing", since recent versions of gcc
will emit incorrect (crashing) code if this flag is not
provided, when compiling certain modules (the mx
products from egenix, for example).
I did try to set CFLAGS in my environment, as directed
by documentation, but this also had zero effect on the
final build command.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 10:05
Message:
Logged In: YES
user_id=21627
I don't think I will do anything about this anytime soon, so
unassigning myself.
--
Comment By: nyogtha (nyogtha)
Date: 2006-01-13 22:19
Message:
Logged In: YES
user_id=1426882
This is still a bug in Python 2.4.2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969718&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed
Bugs item #1248997, was opened at 2005-07-31 23:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&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: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Laurie Harper (zodiac) >Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 10:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-04 07:30 Message: Logged In: YES user_id=21627 Sounds good. Can you provide a patch? -- Comment By: Jeff Epler (jepler) Date: 2005-08-04 00:14 Message: Logged In: YES user_id=2772 I'd rather see the build-requires line of the spec file have the required -devel packages listed, than fix the spec file to detect whether they're available and possibly build a python with reduced capabilities. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076515 ] shutil.move clobbers read-only files.
Bugs item #1076515, was opened at 2004-12-01 06:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&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: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move clobbers read-only files. Initial Comment: The summary states it fine. shutil.move happily overwrites read- only files. It looks like it indiscriminately catches OSError, and never bothers to check whether it's a permission error. It'd be nice if permission errors raised an exception that was a subclass of OSError, then it'd be cake to fix this (at least for *nices; I'm not sure about the Windows implications). According to tracker #810879, clobbering read-only files isn't the desired behavior for shutil.copyfile, so I doubt it's desired for shutil.move. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 10:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-12-06 23:21 Message: Logged In: YES user_id=469548 Your analysis is not correct. On Unix, you need write permission to the *directory* to rename. So the os.rename() call simply succeeds on a read-only file if you have write access to its parent directory. I think we could shield from this by always using the fallback implementation (copy2+unlink(src)), but I'm not sure what the implications of that would be (qua performance and cross-platform issues). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1468727 ] Possible Integer overflow
Bugs item #1468727, was opened at 2006-04-11 19:00
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
>Resolution: Invalid
Priority: 7
Submitted By: ekellinis (ekellinis)
>Assigned to: Michael Hudson (mwh)
Summary: Possible Integer overflow
Initial Comment:
There is possible integer overlow in the fcntlmodule.c
=
fcntl_fcntl(PyObject *self, PyObject *args)
{
int fd;
int code;
int arg;
int ret;
char *str;
Py_ssize_t len;
char buf[1024];
if (PyArg_ParseTuple(args, "O&is#:fcntl",
conv_descriptor, &fd,
&code, &str, &len)) {
if (len > sizeof buf) {
PyErr_SetString(PyExc_ValueError,
"fcntl string arg too long");
return NULL;
}
memcpy(buf, str, len);
=
Explanation :
if "len" receives very large value (>integer) there is
a possiblity that it will become negative and the value
will bypass the if statement and go directly to
memcpy(buf, str, len);
The latest revision of the module (42787) has int
replaced with Py_ssize_t which as it mentions at
http://www.python.org/dev/peps/pep-0353/
"...Py_ssize_t is introduced, which has the same size
as the compiler's size_t type, but is signed.." so the
problem seem to still be there.
-The int type is used from revision 42093 and back
Someone needs to be able to execute arbitrary python to
exploit it , possible effect : break from the Python
sandbox
--
>Comment By: Michael Hudson (mwh)
Date: 2006-04-12 09:08
Message:
Logged In: YES
user_id=6656
>From a little source staring, I am pretty sure that len can in fact never be
negative. If you have exploit code, please share in. On the optimistic
premise
that I'm not blind, closing this bug.
Also, you're letting code execute ioctl and are worried about what else it
might
be doing ... ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by splitscreen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Fleming (splitscreen)
Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 10:14
Message:
Logged In: YES
user_id=1126061
Yeah, your patch looks much better.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 08:15
Message:
Logged In: YES
user_id=849994
splitscreen: your patch was incomplete and could have
overwritten memory.
tim_one: Attaching new patch implementing what I proposed in
my comment below.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 21:59
Message:
Logged In: YES
user_id=1126061
Ok, uploading latest patch, not quite sure I've hit the mark
here.
Please review.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43
Message:
Logged In: YES
user_id=849994
Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
--
Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469163 ] SimpleXMLRPCServer doesn't work anymore on Windows
Bugs item #1469163, was opened at 2006-04-12 12:23 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=1469163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: kadeko (kadeko) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer doesn't work anymore on Windows Initial Comment: The bug resolution of [ 1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC break the compatibility with Windows system. The new "import fcntl" is not possible on non POSIX system. C:\Python25>C:\Python25\python.exe C:\Python25\server2.py Traceback (most recent call last): File "C:\Python25\server2.py", line 1, in from DocXMLRPCServer import DocXMLRPCServer File "C:\Python25\lib\DocXMLRPCServer.py", line 18, in from SimpleXMLRPCServer import (SimpleXMLRPCServer, File "C:\Python25\lib\SimpleXMLRPCServer.py", line 107, in import os, fcntl ImportError: No module named fcntl -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469163 ] SimpleXMLRPCServer doesn't work anymore on Windows
Bugs item #1469163, was opened at 2006-04-12 12:23 Message generated for change (Settings changed) made by kadeko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: kadeko (kadeko) Assigned to: Nobody/Anonymous (nobody) Summary: SimpleXMLRPCServer doesn't work anymore on Windows Initial Comment: The bug resolution of [ 1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC break the compatibility with Windows system. The new "import fcntl" is not possible on non POSIX system. C:\Python25>C:\Python25\python.exe C:\Python25\server2.py Traceback (most recent call last): File "C:\Python25\server2.py", line 1, in from DocXMLRPCServer import DocXMLRPCServer File "C:\Python25\lib\DocXMLRPCServer.py", line 18, in from SimpleXMLRPCServer import (SimpleXMLRPCServer, File "C:\Python25\lib\SimpleXMLRPCServer.py", line 107, in import os, fcntl ImportError: No module named fcntl -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469163 ] SimpleXMLRPCServer doesn't work anymore on Windows
Bugs item #1469163, was opened at 2006-04-12 20:23 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: kadeko (kadeko) >Assigned to: Anthony Baxter (anthonybaxter) Summary: SimpleXMLRPCServer doesn't work anymore on Windows Initial Comment: The bug resolution of [ 1222790 ] SimpleXMLRPCServer does not set FD_CLOEXEC break the compatibility with Windows system. The new "import fcntl" is not possible on non POSIX system. C:\Python25>C:\Python25\python.exe C:\Python25\server2.py Traceback (most recent call last): File "C:\Python25\server2.py", line 1, in from DocXMLRPCServer import DocXMLRPCServer File "C:\Python25\lib\DocXMLRPCServer.py", line 18, in from SimpleXMLRPCServer import (SimpleXMLRPCServer, File "C:\Python25\lib\SimpleXMLRPCServer.py", line 107, in import os, fcntl ImportError: No module named fcntl -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-12 22:08 Message: Logged In: YES user_id=29957 Fixed in r45305 by handling the 'no fcntl module available' case. Thanks for the bug report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469163&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i
Bugs item #864379, was opened at 2003-12-22 11:40
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&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: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.3 make test core dump on HP-UX11i
Initial Comment:
I built Python-2.3.3 on HP-UX11i in the same way that I
built Python-2.3.2.
However, this time running 'make test' core dumps on
the second pass with:
test_sax
*** Termination signal 138
Stop.
The output from test_sax.py is given below. Each test
appears to fail, but the summary gives zero failures (this
also happens with Python 2.3.2, but 'make test' doesn't
core dump on that release).
> ./python ./Lib/test/test_sax.py
Failed test_attrs_empty
Failed test_attrs_wattr
Failed test_double_quoteattr
Failed test_escape_all
Failed test_escape_basic
Failed test_escape_extra
Failed test_expat_attrs_empty
Failed test_expat_attrs_wattr
Failed test_expat_dtdhandler
Failed test_expat_entityresolver
Failed test_expat_file
Failed test_expat_incomplete
Failed test_expat_incremental
Failed test_expat_incremental_reset
Failed test_expat_inpsource_filename
Failed test_expat_inpsource_location
Failed test_expat_inpsource_stream
Failed test_expat_inpsource_sysid
Failed test_expat_locator_noinfo
Failed test_expat_locator_withinfo
Failed test_expat_nsattrs_empty
Failed test_expat_nsattrs_wattr
Failed test_filter_basic
Failed test_make_parser
Failed test_make_parser2
Failed test_nsattrs_empty
Failed test_nsattrs_wattr
Failed test_quoteattr_basic
Failed test_single_double_quoteattr
Failed test_single_quoteattr
Failed test_unescape_all
Failed test_unescape_amp_extra
Failed test_unescape_basic
Failed test_unescape_extra
Failed test_xmlgen_attr_escape
Failed test_xmlgen_basic
Failed test_xmlgen_content
Failed test_xmlgen_content_escape
Failed test_xmlgen_ignorable
Failed test_xmlgen_ns
Failed test_xmlgen_pi
41 tests, 0 failures
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 14:39
Message:
Logged In: YES
user_id=849994
As 2.3.x is not maintained anymore, should this be closed?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 08:03
Message:
Logged In: YES
user_id=21627
I don't think I will do anything about this anytime soon, so
unassigning myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-24 13:23
Message:
Logged In: YES
user_id=33168
I think I remember hearing something about an
incompatibility. The two best people to discuss this are
probably Martin v. Loewis and Fred Drake. I'm assigning to
Martin, perhaps he can shed some more light on the issues.
--
Comment By: Richard Townsend (rptownsend)
Date: 2003-12-24 12:46
Message:
Logged In: YES
user_id=200117
I have now installed Python-2.3.3 plus PyXML-0.8.3 and the
core dump in 'make test' has returned.
So, it looks like a compatability problem with PyXML-0.8.3 ?
--
Comment By: Richard Townsend (rptownsend)
Date: 2003-12-24 09:25
Message:
Logged In: YES
user_id=200117
HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user
license
This is the configure command I used:
base_inst_dir=/opt
python_link=${base_inst_dir}/python
CC=cc \
OPT="+O2 -z +Onofltacc +ESlit +Oentrysched \
+Odataprefetch +Onolimit +DA2.0" \
INSTALL="./install-sh -c" \
./configure --with-threads --without-gcc \
--with-cxx=/opt/aCC/bin/aCC --without-libd \
--with-cycle-gc --prefix=$python_link \
--exec-prefix=$python_link
This is exactly the same command I have used on previous
Python 2.3 releases which did not core dump in 'make test'.
Note it uses the native HP compiler.
I have now just rebuilt without optimisation, using:
CC=cc \
INSTALL="./install-sh -c" \
./configure --with-threads --without-gcc \
--with-cxx=/opt/aCC/bin/aCC --without-libd \
--with-cycle-gc --prefix=$python_link \
--exec-prefix=$python_link
It still core dumps at the same point in the second pass
of 'make test'.
I have attached a stack trace from the core file. I noticed
that this has references to /opt/python/lib/python2.3/site-
packages/_xmlplus/parsers/pyexpat.sl. This is the previous
installation of Python 2.3.2 plus PyXML-0.8.3.
I wondered if I had forgotten to reset $PYTHONPATH before
running 'make test', so I did that and tried again but it still
core dumped.
So next I reset the symbolic link /opt/py
[ python-Bugs-1433877 ] string parameter to ioctl not null terminated, includes fix
Bugs item #1433877, was opened at 2006-02-17 23:29 Message generated for change (Comment added) made by twouters 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: 6 Submitted By: Quentin Barnes (qbarnes) >Assigned to: Michael Hudson (mwh) 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: Thomas Wouters (twouters) Date: 2006-04-12 16:52 Message: Logged In: YES user_id=34209 Hrm. After giving this some thought, perhaps we should do memcpy(buf, str, len+1) instead of memcpy(buf, str, len) buf[len] = '\0' (And do this in the writable-buffer case as well, when we use memcpy.) Other than that, I think this is the right fix. Assigning to mwh for second (third? fourth?) opinion. -- Comment By: Thomas Wouters (twouters) Date: 2006-03-20 22:22 Message: Logged In: YES user_id=34209 Huh, I never even saw this patch, in spite of the high priority and it being assigned to me. We didn't discuss it at PyCon (at least, I wasn't party to the discussion) but I guess this patch doesn't really hurt, and does fix actual problems. I'm wary of fudging fcntl/ioctl too much; I'd _much_ rather try and come up with a decent interface for Py3k, with mutable bytestrings and all that, maybe some nice automatic argument-type-conversion or higher-level interface for common features (like advisory locks) -- and only keep 2.x's fcntl working as well as it does. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 21:52 Message: Logged In: YES user_id=6380 mwh: Sorry about the docstring gripe -- I read the fcntl() docstring which is right above the ioctl() implementation and never realized that this particular C module places the doc strings *after* the functions. (I think that's bad style but there it is.) I think the priority was set to 9 by Neal to get Thomas' attention. gbarnes: We'll decide this one at PyCon. -- Comment By: Quentin Barnes (qbarnes) Date: 2006-02-20 19:00 Message: Logged In: YES user_id=288734 I didn't write new code that causes this problem by calling ioctl with a string that needed to be null terminated. It was already in Python code itself. See Lib/pty.py for the code. I reworked the patch as discussed below and retested it. All built-in tests passed. I've attached it. I hae no idea of Python coding conventions or style. Hopefully I didn't violate them too badly. (This was weird. SF rejected the text above when I submitted it, but it took the patch file. The patch file shows up as "nobody". Resubmitting this text.) -- Comment By: Michael Hudson (mwh) Date: 2006-02-20 11:54 Message: Logged In: YES user_id=6656 Seeing as some of this is my code... Guido, the ioctl docstring *does* mention mutate_arg. I agree that the documentation should have been updated for 2.4 and 2.5... and the situation is a mess, yes, but one that I couldn't see a better way around when the feature was added (it was much discussed in the bug report at the time). It certainly never occurred to me that you might need/want to pass a NULL terminated string to ioctl. I don't think this is a priority 9 report. -- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-20 06: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
[ python-Bugs-416288 ] infrequent memory leak in pyexpat
Bugs item #416288, was opened at 2001-04-15 17:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&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: XML Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: douglas orr (dougbo) Assigned to: Nobody/Anonymous (nobody) Summary: infrequent memory leak in pyexpat Initial Comment: In pyexpat.c, the macro call for the handler dispatch (my##NAME##Handler) for CharacterHandler allocates an object implicitly by calling one of the conversion-to- unicode routines. If there is a problem in the PyBuildValue, resulting in args == NULL, that object will be leaked. Low priority, but the macros probably need some reworking to handle this. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 15:00 Message: Logged In: YES user_id=849994 This was fixed in response to bug [ 984722 ] Py_BuildValue loses reference counts on error, in rev. 36480. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 08:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2002-03-28 23:20 Message: Logged In: YES user_id=21627 No, currently, it can only leak: the argument being passed will have an extra ref count, which supposedly will be consumed by the tuple. If something fails, some of the N arguments will have been stored in the tuple-under-construction, and will be released when the tuple is released. 'N' arguments not yet consumed will leak. Processing should continue in case of an error, and DECREF all N arguments. -- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-28 22:34 Message: Logged In: YES user_id=6380 Hm, the 'N' format code looks really scary. Can't it end up DECREF'ing an object too many times if something fails? -- Comment By: Martin v. Löwis (loewis) Date: 2001-06-09 11:48 Message: Logged In: YES user_id=21627 That seems to be a bug in Py_BuildValue: It should decref its N arguments if it can't create a tuple. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1367183 ] inspect.getdoc fails on objs that use property for __doc__
Bugs item #1367183, was opened at 2005-11-26 21:42 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&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: Wont Fix Priority: 5 Submitted By: Drew Perttula (drewp) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getdoc fails on objs that use property for __doc__ Initial Comment: inspect.getdoc has these lines: if not isinstance(doc, types.StringTypes): return None which interfere with the case where __doc__ is some other thing that has a good __str__. I wanted to make a lazy __doc__ that did an expensive lookup of some external documentation only when it was str()'d, but since doc displayers often (correctly) use inspect.getdoc, they were getting None. I think the intention of the test in getdoc() is to avoid trying string operations on a __doc__ that is None. I think that a more lenient version would allow me to do my fancy docstrings but still solve the '__doc__ is None' problem. Please consider the following patch: if doc is None: return None doc = str(doc) -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 15:19 Message: Logged In: YES user_id=849994 Closing as Won't Fix. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-20 08:04 Message: Logged In: YES user_id=33168 That code doesn't work if doc is unicode. I'm not sure how to achieve what you want. -- Comment By: Georg Brandl (birkenfeld) Date: 2006-02-20 08:21 Message: Logged In: YES user_id=1188172 I don't know. Neal, do you have an opinion about property docstrings? -- Comment By: Collin Winter (collinwinter) Date: 2006-02-01 11:35 Message: Logged In: YES user_id=1344176 It's not a good idea to use properties for __doc__: """ >>> class Foo(object): ...def _get(self): ...return 'the docstring' ...__doc__ = property(_get) ... >>> print Foo().__doc__ the docstring >>> print Foo.__doc__ >>> """ In this light, I don't view inspect.getdoc's lack of support for __doc__-as-property as a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1367183&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1248997 ] 2.3.5 SRPM fails to build without tkinter installed
Bugs item #1248997, was opened at 2005-07-31 21:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&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: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Laurie Harper (zodiac) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.5 SRPM fails to build without tkinter installed Initial Comment: If tkinter isn't available, rpmbuild fails due to the presence of unpackages files in usr/lib/python-2.3/lib-tk. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 15:21 Message: Logged In: YES user_id=849994 This is a duplicate of #1403221. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 08:06 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-04 05:30 Message: Logged In: YES user_id=21627 Sounds good. Can you provide a patch? -- Comment By: Jeff Epler (jepler) Date: 2005-08-03 22:14 Message: Logged In: YES user_id=2772 I'd rather see the build-requires line of the spec file have the required -devel packages listed, than fix the spec file to detect whether they're available and possibly build a python with reduced capabilities. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1248997&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-864379 ] Python 2.3.3 make test core dump on HP-UX11i
Bugs item #864379, was opened at 2003-12-22 12:40
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864379&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: Build
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.3 make test core dump on HP-UX11i
Initial Comment:
I built Python-2.3.3 on HP-UX11i in the same way that I
built Python-2.3.2.
However, this time running 'make test' core dumps on
the second pass with:
test_sax
*** Termination signal 138
Stop.
The output from test_sax.py is given below. Each test
appears to fail, but the summary gives zero failures (this
also happens with Python 2.3.2, but 'make test' doesn't
core dump on that release).
> ./python ./Lib/test/test_sax.py
Failed test_attrs_empty
Failed test_attrs_wattr
Failed test_double_quoteattr
Failed test_escape_all
Failed test_escape_basic
Failed test_escape_extra
Failed test_expat_attrs_empty
Failed test_expat_attrs_wattr
Failed test_expat_dtdhandler
Failed test_expat_entityresolver
Failed test_expat_file
Failed test_expat_incomplete
Failed test_expat_incremental
Failed test_expat_incremental_reset
Failed test_expat_inpsource_filename
Failed test_expat_inpsource_location
Failed test_expat_inpsource_stream
Failed test_expat_inpsource_sysid
Failed test_expat_locator_noinfo
Failed test_expat_locator_withinfo
Failed test_expat_nsattrs_empty
Failed test_expat_nsattrs_wattr
Failed test_filter_basic
Failed test_make_parser
Failed test_make_parser2
Failed test_nsattrs_empty
Failed test_nsattrs_wattr
Failed test_quoteattr_basic
Failed test_single_double_quoteattr
Failed test_single_quoteattr
Failed test_unescape_all
Failed test_unescape_amp_extra
Failed test_unescape_basic
Failed test_unescape_extra
Failed test_xmlgen_attr_escape
Failed test_xmlgen_basic
Failed test_xmlgen_content
Failed test_xmlgen_content_escape
Failed test_xmlgen_ignorable
Failed test_xmlgen_ns
Failed test_xmlgen_pi
41 tests, 0 failures
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 19:01
Message:
Logged In: YES
user_id=21627
Sure. Closing it as "won't fix". If the problem persists for
2.5, please re-report.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-12 16:39
Message:
Logged In: YES
user_id=849994
As 2.3.x is not maintained anymore, should this be closed?
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-04-12 10:03
Message:
Logged In: YES
user_id=21627
I don't think I will do anything about this anytime soon, so
unassigning myself.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-12-24 14:23
Message:
Logged In: YES
user_id=33168
I think I remember hearing something about an
incompatibility. The two best people to discuss this are
probably Martin v. Loewis and Fred Drake. I'm assigning to
Martin, perhaps he can shed some more light on the issues.
--
Comment By: Richard Townsend (rptownsend)
Date: 2003-12-24 13:46
Message:
Logged In: YES
user_id=200117
I have now installed Python-2.3.3 plus PyXML-0.8.3 and the
core dump in 'make test' has returned.
So, it looks like a compatability problem with PyXML-0.8.3 ?
--
Comment By: Richard Townsend (rptownsend)
Date: 2003-12-24 10:25
Message:
Logged In: YES
user_id=200117
HP-UX capulet B.11.11 U 9000/785 2002932658 unlimited-user
license
This is the configure command I used:
base_inst_dir=/opt
python_link=${base_inst_dir}/python
CC=cc \
OPT="+O2 -z +Onofltacc +ESlit +Oentrysched \
+Odataprefetch +Onolimit +DA2.0" \
INSTALL="./install-sh -c" \
./configure --with-threads --without-gcc \
--with-cxx=/opt/aCC/bin/aCC --without-libd \
--with-cycle-gc --prefix=$python_link \
--exec-prefix=$python_link
This is exactly the same command I have used on previous
Python 2.3 releases which did not core dump in 'make test'.
Note it uses the native HP compiler.
I have now just rebuilt without optimisation, using:
CC=cc \
INSTALL="./install-sh -c" \
./configure --with-threads --without-gcc \
--with-cxx=/opt/aCC/bin/aCC --without-libd \
--with-cycle-gc --prefix=$python_link \
--exec-prefix=$python_link
It still core dumps at the same point in the second pass
of 'make test'.
I have attached a stack trace from the core file. I noticed
that this has references to /opt/python/lib/python2.3/site-
packages/_xmlplus/parser
[ python-Feature Requests-960454 ] old/new class documentation
Feature Requests item #960454, was opened at 2004-05-25 18:33 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&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: Documentation Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: old/new class documentation Initial Comment: The distributed documentation refers to old and new-style classes, but they do not appear in the index, and the difference is not explained. (Users who ask are referred to documentation on www.python.org, which is not currently shipped with the default distrubution.) As best I understand it, the only differences are: (1) New-style classes inherit from object. Because of this inheritance, new-style classes have a few extra capabilities, such as descriptors and super. (2) Method Resolution Order can be different in cases of multiple inheritance. (3) New style classes take precedence over old-style classes when doing rich comparison. (4) If rich comparison fails, numeric coercion will be attempted if -- and only if -- at least one of the objects is an old-style class. -- >Comment By: Jim Jewett (jimjjewett) Date: 2006-04-12 14:07 Message: Logged In: YES user_id=764593 -- Comment By: iga Seilnacht (zseil) Date: 2006-04-10 10:07 Message: Logged In: YES user_id=1326842 This seems like a duplicate of bug #960340, which was closed when section New-style and classic classes was added to the Python Reference Manual (see http://docs.python.org/dev/ref/node33.html). -- Comment By: Edward Diener (eldiener) Date: 2004-08-01 19:53 Message: Logged In: YES user_id=490593 New style classes, with all their new attributes, member functions, static methods, and class methods, need to be documented in the official Python distribution. Included in this is the explanation of metaclasses and how to use them. Essentially Guido's paper on new style classes, reworked to fit within the existing documentation framework, should be added to the official documantation.. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 11:21 Message: Logged In: YES user_id=764593 Found a new difference -- you can't assign to the __bases__ or __name__ of a new-style class, and you can't usually assign to it's __class__. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-05-26 10:05 Message: Logged In: YES user_id=764593 Given that the differences are almost -- but not entirely -- extra options for new-style classes, the language lawyer section on classes (ref/7.6) might be a good location. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=960454&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332852 ] BSD DB test failures for BSD DB 3.2
Bugs item #1332852, was opened at 2005-10-19 21:41
Message generated for change (Comment added) made by greg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&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: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gregory P. Smith (greg)
Summary: BSD DB test failures for BSD DB 3.2
Initial Comment:
After a bunch of modifications to build and get bsddb
mostly running, I still get 4 test failures with Python
2.4 and CVS head.
FAIL: test_previous_last_looping
(test.test_bsddb.TestBTree)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('q', 'Guido'), ('w', 'van'), ('t',
'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
==
FAIL: test_previous_last_looping
(test.test_bsddb.TestHashTable)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
==
FAIL: test_previous_last_looping
(test.test_bsddb.TestBTree_InMemory)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('q', 'Guido'), ('w', 'van'), ('t',
'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
==
FAIL: test_previous_last_looping
(test.test_bsddb.TestHashTable_InMemory)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
--
>Comment By: Gregory P. Smith (greg)
Date: 2006-04-12 12:21
Message:
Logged In: YES
user_id=413
i'd prefer to just not support 3.2 anymore.
mind if i just change setup.py to not accept 3.2?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-19 22:20
Message:
Logged In: YES
user_id=33168
Oops, that last comment got cut off. I've got db-3.2 and
db-4.1 on my system at least. Not sure why the older one is
picked up rather than the newer one.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-19 22:17
Message:
Logged In: YES
user_id=33168
test_bsddb3 core dumps for me. backtrace attached.
Do we really support 3.2 anymore? Maybe we shouldn't? I'm
on a gentoo system. I don't know wha
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.c
[ python-Bugs-764839 ] Old bsddb version picked by setup.py
Bugs item #764839, was opened at 2003-07-02 12:39
Message generated for change (Comment added) made by greg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&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: Distutils
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Josh Hoyt (joshhoyt)
Assigned to: Martin v. Löwis (loewis)
Summary: Old bsddb version picked by setup.py
Initial Comment:
I have two versions of Berkeley DB in the standard
include path. The code in setup.py finds the newer
version first (db4) and then finds the older version
(db3) later in scanning standard includes. This means
that the bsddb module is built against the older rather
than the newer version.
The attached patch to setup.py records all standard
headers that are found and lets the db_search_order
list choose which version of the library to link against.
--
>Comment By: Gregory P. Smith (greg)
Date: 2006-04-12 12:24
Message:
Logged In: YES
user_id=413
the rewrite of the BerkeleyDB version selection code in
setup.py i did a while back (last year) should have taken
care of this.
prior to that it could indeed pick non-matching include and
library files.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-10-18 02:51
Message:
Logged In: YES
user_id=21627
I see. Please notice that setting CFLAGS prior to
compilation is not really supported, so I recommend that you
don't set CFLAGS - BerkeleyDB 4.1 should still be found in
/usr/local, or (preferred) /usr/local/BerkeleyDB.4.1
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2003-07-07 09:29
Message:
Logged In: YES
user_id=693077
I am running Debian GNU/Linux, unstable, with GCC 3.3.1.
I added the following to my environment prior to building
Python:
LDFLAGS=-L${HOME}/local/lib
CFLAGS-I${HOME}/local/include
My local build of Berkeley DB is version 4.1.25, and the
system version is 3.2.9.
I hope that makes the situation clear.
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-06 22:00
Message:
Logged In: YES
user_id=21627
Can you please be more explicit? What operating system are
you using, what compiler, how did you add something to the
include path, what was the version of BerkeleyDB that was
installed, what was the version that you installed yourself,
and where did you install it?
In short, you shouldn't add something to the include path.
For gcc, I don't even see how you *could* add something to
the include path.
--
Comment By: Josh Hoyt (joshhoyt)
Date: 2003-07-06 19:29
Message:
Logged In: YES
user_id=693077
There is a system Berkeley DB library and I have a locally
built newer Berkeley DB library. When building Python, I
added my local build to the include path and to the library
path.
Am I missing a more explicit way of selecting the library
short of editing Setup in the Modules directory?
--
Comment By: Martin v. Löwis (loewis)
Date: 2003-07-06 02:46
Message:
Logged In: YES
user_id=21627
I'm not quite sure how this could ever happen. Are you
saying that you have two different versions of db.h, both on
your standard search path? In what specific locations?
This is asking for trouble, and it might be better if
setup.py would actively reject that scenario, refusing to
build _bsddb.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&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: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Paul Moore (pmoore) >Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. -- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1
Bugs item #1465834, was opened at 2006-04-06 18:40 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Paul Moore (pmoore) Assigned to: Thomas Heller (theller) Summary: bdist_wininst preinstall script support is broken in 2.5a1 Initial Comment: The attached zip file contains a trivial module. Run "run_setup.bat" to create a bdist_wininst installer (you'll need to edit it to make the preinstall script path match where you unzipped the file). The resulting installer fails with an error "Running the pre-installation script failed". -- >Comment By: Thomas Heller (theller) Date: 2006-04-12 22:12 Message: Logged In: YES user_id=11105 Attached a patch which should fix this issue. Paul, if you want do further tests *now* I can upload a python25.dll, compiled from current SVN + patch, somewhere. Hopefully this will be compatible with a 2.5a1 installation. -- Comment By: Thomas Heller (theller) Date: 2006-04-11 19:19 Message: Logged In: YES user_id=11105 These apis are now macros, they were exported functions in Python 2.4: PyParser_SimpleParseFile PyParser_SimpleParseString PyRun_AnyFile PyRun_AnyFileEx PyRun_AnyFileFlags PyRun_File PyRun_FileEx PyRun_FileFlags PyRun_InteractiveLoop PyRun_InteractiveOne PyRun_SimpleFile PyRun_SimpleFileEx PyRun_SimpleString PyRun_String Py_CompileString All of them, to be safe, should probably exposed as exported functions again. See also this thread on python-dev: http://mail.python.org/pipermail/python-dev/2006-January/059374.html Raising the priority to 7 because this must be fixed before release. -- Comment By: Paul Moore (pmoore) Date: 2006-04-06 22:01 Message: Logged In: YES user_id=113328 Seems to be limited to installers with preinstall scripts, as far as I can tell. The main example is pywin32, which is irritatingly significant :-) (One oddness I couldn't check is that scripts don't seem to get compiled any more - don't know if this is related to the same issue. It's not a big deal either way, though). The fix sounds reasonable. -- Comment By: Thomas Heller (theller) Date: 2006-04-06 20:22 Message: Logged In: YES user_id=11105 bdist_wininst7.1.exe uses runtime dynamic linking to the python dll. Python25.dll doesn't export a PyRun_SimpleString function anymore, it has been replaced by a macro: #define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL) bdist_wininst *could* be changed to use PyRun_SimpleStringFlags instead, however, installers built with previous versions of Python will then refuse to install pure distributions to Python 2.5. I have not checked if installers that do *not* have a pre-install script will work or not. I suggest to make PyRun_SimpleString an exported function again - this should be cheap. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1149413 ] bsddb: bug with 'n' flag
Bugs item #1149413, was opened at 2005-02-22 14:14 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&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.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Gregory P. Smith (greg) Summary: bsddb: bug with 'n' flag Initial Comment: Where: http://docs.python.org/lib/module-bsddb.html You say there: btopen( filename[, flag[, mode[, btflags[, cachesize[, maxkeypage[, minkeypage[, psize[, lorder) the word psize should be replaced with pgsize. An example would help: >>> d = bsddb.btopen(None, "c", cachesize=768000, pgsize=65536) >>> d = bsddb.btopen(None, "n", cachesize=768000, pgsize=65536) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 201, in btopen flags = _checkflag(flag, file) File "/usr/lib/python2.3/bsddb/__init__.py", line 249, in _checkflag if os.path.isfile(file): File "/usr/lib/python2.3/posixpath.py", line 200, in isfile st = os.stat(path) TypeError: coercing to Unicode: need string or buffer, NoneType found >>> The latter is I believe possibly a bug in the python wrapper not handling 'n' properly. -- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:17 Message: Logged In: YES user_id=413 fix for the 'n' flag not working with a filename of None committed (with a test case). svn rev 45318. -- Comment By: A.M. Kuchling (akuchling) Date: 2005-06-08 14:57 Message: Logged In: YES user_id=11375 I've fixed the documentation to use the right parameter name; thanks for reporting this! The example you give doesn't work for me: it reports 'bsddb._db.DBInvalidArgError: (22, 'Invalid argument -- set_cachesize: method meaningless in shared environment')' with the current CVS head. Removing the cachesize argument makes it work. The 'n' problem does seem to be a bug; the code should check that file is not None before doing os.file.exists(). Reassigning and reclassifying the bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1149413&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1117761 ] BSDDB openhash
Bugs item #1117761, was opened at 2005-02-07 01:24
Message generated for change (Comment added) made by greg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&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: Closed
Resolution: None
Priority: 5
Submitted By: Andrea Bolzonella (bolzonella)
>Assigned to: Gregory P. Smith (greg)
Summary: BSDDB openhash
Initial Comment:
Python 2.4 (#1, Dec 8 2004, 18:57:30)
[GCC 3.3.3 (SuSE Linux)] on linux2
>>> import bsddb
>>> h = bsddb.hashopen('test','c',cachesize=100)
Traceback (most recent call last):
File "", line 1, in ?
File "/home/alex/DLD/lib/python2.4/bsddb/__init__.py", line
288, in hashopen
bsddb._db.DBInvalidArgError: (22, 'Invalid argument --
DB->set_cachesize: method not permitted in shared
environment')
I replace bsddb.hashopen with a 2.3.3 version and it works.
--
>Comment By: Gregory P. Smith (greg)
Date: 2006-04-12 13:39
Message:
Logged In: YES
user_id=413
fixed in python repository. commits 45319 and 45320 for 2.5
and 2.4.
set_cachesize needed to be called on the DBEnv object prior
to opening now instead of the DB object.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-02-09 16:33
Message:
Logged In: YES
user_id=21627
Apparently, this is caused by hashopen now allocated a
DBEnv. This, in turn, is necessary to allow multiple threads
to access the same database simultaneously.
I'm unsure why bsddb does not support shared access and
having a cache size simultaneously; it might be best to
disallow the cachesize argument, and require users who want
to specify it to use DB.open explicitly (with no environment).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117761&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1215023 ] bsddb dbobj.DB.associate doesn't accept dbobj.DB param
Bugs item #1215023, was opened at 2005-06-04 19:18
Message generated for change (Settings changed) made by greg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215023&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: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Gregory P. Smith (greg)
>Assigned to: Gregory P. Smith (greg)
Summary: bsddb dbobj.DB.associate doesn't accept dbobj.DB param
Initial Comment:
To: Michael C Urban <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Date: Sat, 4 Jun 2005 18:21:34 -0700
On Sat, Jun 04, 2005 at 06:16:37PM -0500, Michael C
Urban wrote:
> Hi all,
>
> I'm running into a TypeError when I try to associate
a secondary db with a
> primary one. But the error only occurs when I use an
object oriented
> style, so I am wondering it it might be a bug.
>
> Basically, the following works fine:
>
> db = DB(None, 0)
> db.open("testDb.db", None, DB_BTREE, DB_CREATE, 0660)
> dbs = DB(None, 0)
> dbs.open("testDbS.db", None, DB_BTREE, DB_CREATE, 0660)
> db.associate(dbs, makeAddressKey, 0)
>
> However, the following similar code does not:
>
> def __dbInitialize(self, dbDir, fileName):
>self.__dbEnv = dbobj.DBEnv(0)
>self.__dbEnv.open(dbDir, db.DB_INIT_TXN |
db.DB_CREATE |
> db.DB_INIT_MPOOL)
>
>self.__dbMain = dbobj.DB(self.__dbEnv, 0)
>self.__nameIdx = dbobj.DB(self.__dbEnv, 0)
>
>self.__dbMain.open(fileName, None, db.DB_BTREE,
db.DB_CREATE, 0660)
>self.__nameIdx.open("nameDb.idx", None, db.DB_BTREE,
> db.DB_CREATE, 0660)
>
>self.__dbMain.associate(self.__nameIdx,
self.__makeNameKey, 0)
>
> ...
> The last line causes the following error:
>
> TypeError: Expected DB argument, instance found.
>
> Am I doing something wrong here? The only difference
I can see between the
> first example and the second one is that one uses a
private variable from
> the class, and the other does not use object oriented
style. The databases
> all get created fine, as to the log files. It's only
when I try to
> associate that I have the problem.
>
> Thanks for any help in advance.
This is happening because the C wrapper requires that
the secondaryDB
parameter to associate() is a C wrapper DB object.
My first suggestion is based on the code above, use
db.DB not
dbobj.DB. dbobj is only a wrapper around the C db.DB
to allow people
to subclass it.
If you do need to use a dbobj derived class for the
secondary DB,
realize that BerkeleyDB doesn't call back to python for
DB access so
it won't use any overridden methods. If thats ok, then
add the
following overridden method to your dbobj derived class
and associate
should work:
def associate(self, *args, **kwargs):
# if we're given a dbobj derived secondaryDB we
need to pass
# the actual C db.DB object to BerkeleyDB. do it.
argDB = kwargs.get('secondaryDB')
if not argDB:
argDB = args.pop(0)
if isinstance(argDB, DB):
kwargs['secondaryDB'] = argDB._cobj
return apply(self._cobj.associate, args, kwargs)
This passes the internal C db.DB object to the
BerkeleyDB associate method.
I'm pasting this email as a pybsddb bug report. the
above method should probably be used as the base
dbobj.associate.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1215023&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1010645 ] bsddb3 testsuite failure when running more than one time
Bugs item #1010645, was opened at 2004-08-17 03:39 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010645&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Gregory P. Smith (greg) Summary: bsddb3 testsuite failure when running more than one time Initial Comment: running the testsuite with TESTOPTS="-l -unetwork,bsddb" leaves (sometimes?) an directory Lib/test/db_home, which lets two of the bsddb tests fail in further test runs. Removing this directory before the next test run, lets the tests complete sucessfully. -- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:44 Message: Logged In: YES user_id=413 yes there appear to be several messy turds (db_home/ and even a db created outside of db_home) in the existing full bsddb test suite. its on my list to find and clean up. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1010645&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469498 ] Exception when handling http response
Bugs item #1469498, was opened at 2006-04-12 20:49 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=1469498&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: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-781614 ] Windows _bsddb link warnings
Bugs item #781614, was opened at 2003-08-01 10:04 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&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: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. -- >Comment By: Gregory P. Smith (greg) Date: 2006-04-12 13:50 Message: Logged In: YES user_id=413 I believe BerkeleyDB 4.4 when compiled on windows uses the multithreaded DLL C RTL by default even for its static library now so this error should go away? i think this problem is gone for the latest BerkeleyDB and is just a PCbuild readme.txt documentation problem for older BerkeleyDB versions. in the past for stand alone pybsddb bsddb3 packages i always had to change the static build settings of BerkeleyDB to use multi-threaded DLL code generation (/MD flag on cl.exe). With 4.4 i didn't need to do that. (note we weren't linking with the berkeleydb DLL; its the berkeleydb static library, its just that a python extension module is a DLL so the static library code needed to use the same memory model) -- Comment By: Thomas Heller (theller) Date: 2004-02-18 12:18 Message: Logged In: YES user_id=11105 Potentially dangerous - of course. The question is whether this is responsible for some bugs or not. If we cannot link to the DLL then we have to change the build settings for the static builds of libdb41s.lib. -- Comment By: Martin v. Löwis (loewis) Date: 2004-02-18 11:58 Message: Logged In: YES user_id=21627 I think we should avoid linking with the DLL if possible; in some application context, it may be impossible to find the DLL dynamically, or there might be confusion which DLL to load. The linker warning means that there is a conflict between the static (libc.a) and dynamic (msvcr71.dll) version of _free, etc, which potentially means that we are linking conflicting copies of the CRT, which is potentially dangerous. -- Comment By: Thomas Heller (theller) Date: 2004-02-18 09:41 Message: Logged In: YES user_id=11105 It looks to me like we could link to the import library build_win32\Release\libdb41.lib instead of the static library build_win32\Release_static\libdb41s.lib. The former is built with 'multithreaded dll' flags. The downside is that libdb41.dll plus MSVCP60.DLL would have to be distributed. Are the linker warnings a real problem, or only cosmetical? Of course we have to update the build procedure for 2.4 anyway... -- Comment By: Tim Peters (tim_one) Date: 2004-02-16 15:54 Message: Logged In: YES user_id=31435 Thomas, you have any insight into this one? -- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 12:50 Message: Logged In: YES user_id=21627 Can you propose a specific patch? Also, it would be preferable if changing the source code of the Sleepycat distribution would not be necessary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&group_id=5470 ___ Python-bugs-list mailing
[ python-Bugs-1469498 ] Exception when handling http response
Bugs item #1469498, was opened at 2006-04-12 20:49 Message generated for change (Comment added) made by rkasperski You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&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: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None -- >Comment By: Richard Kasperski (rkasperski) Date: 2006-04-12 21:43 Message: Logged In: YES user_id=520350 Here is the version header from running python at the command line. Python 2.4 (#1, Feb 3 2005, 08:52:54 In my httplib.py length is initialized to _UNKNOWN which has the value "UNKNOWN" -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:31 Message: Logged In: YES user_id=849994 On which version of Python does this occur? In HEAD, all code paths in begin() lead to self.length being set to some value or None. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469498 ] Exception when handling http response
Bugs item #1469498, was opened at 2006-04-12 20:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&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: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:31 Message: Logged In: YES user_id=849994 On which version of Python does this occur? In HEAD, all code paths in begin() lead to self.length being set to some value or None. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469498 ] Exception when handling http response
Bugs item #1469498, was opened at 2006-04-12 20:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&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: Richard Kasperski (rkasperski) Assigned to: Nobody/Anonymous (nobody) Summary: Exception when handling http response Initial Comment: When handling the return from a web server that dooes not return the content length(one I wrote) httplib takes an exception at line 478. The line of code in question is if self.length is not None: and should probably read if self.length is not None and self.length != _UNKNOWN: The problem is that self.length is no longer initialized to None -- >Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:50 Message: Logged In: YES user_id=849994 It looks like you're getting a HTTP 0.9 response. In Python 2.4.0, self.length wasn't set in this case, but this bug was fixed in version 2.4.2. Closing this as Fixed, if the problem persists with Python 2.4.3 please reopen. -- Comment By: Richard Kasperski (rkasperski) Date: 2006-04-12 21:43 Message: Logged In: YES user_id=520350 Here is the version header from running python at the command line. Python 2.4 (#1, Feb 3 2005, 08:52:54 In my httplib.py length is initialized to _UNKNOWN which has the value "UNKNOWN" -- Comment By: Georg Brandl (gbrandl) Date: 2006-04-12 21:31 Message: Logged In: YES user_id=849994 On which version of Python does this occur? In HEAD, all code paths in begin() lead to self.length being set to some value or None. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469498&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464571 ] Changes to generator object's gi_frame attr
Bugs item #1464571, was opened at 2006-04-05 01:44 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: A.M. Kuchling (akuchling) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. -- Comment By: iga Seilnacht (zseil) Date: 2006-04-13 01:35 Message: Logged In: YES user_id=1326842 This was changed again in revision 45316. The current comment in genobject.h says: Note: gi_frame can be NULL if the generator is "finished" -- Comment By: Collin Winter (collinwinter) Date: 2006-04-05 01:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469548 ] Build requires already built Python
Bugs item #1469548, was opened at 2006-04-12 19:54 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=1469548&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: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: Build requires already built Python Initial Comment: On RedHat 7.1 I ran into the following interesting build bug: $ ./configure (works fine) $ make ./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl File "./Parser.asdl_c.py", line 56 j += 2 # account or the brase and space after it ^ SyntaxError: invalid syntax This is because Python 1.5.2 is the default there -- OK, no problem working around that 'cause I've got other versions there but it seems mighty strange that the very first thing done in a build of Python requires an already-built Python. What happens on an OS where Python isn't there yet at all? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469548&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1436428 ] urllib has trouble with Windows filenames
Bugs item #1436428, was opened at 2006-02-22 07:03 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436428&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: Donovan Eastman (dpeastman) Assigned to: Nobody/Anonymous (nobody) Summary: urllib has trouble with Windows filenames Initial Comment: When you pass urllib the name of a local file including a Windows drive letter (e.g. 'C:\dir\My File.txt') URLopener.open() incorrectly interprets the drive letter as the scheme of a URL. Of course, given that there is no scheme 'C', this fails. I have solved this in my own code by putting the following test before calling urllib.urlopen(): if url[1] == ':' and url[0].isalpha(): url = 'file:' + url Although this works fine in my particular case, it seems like urllib should just simply "do the right thing" without having to worry about it. Therefore I propose that urllib should automatically assume that any URL that begins with a single alpha followed by a colon is a local file. The only potential downside would be that it would preclude the use of single letter scheme names. I did a little research on this. RFC 3986 suggests, but does not explicitly state that scheme names must be more than one character. (http://www.gbiv.com/protocols/uri/rfc/rfc3986.html#scheme) . That said, there are no currently recognized single letter scheme names (http://www.iana.org/assignments/uri-schemes.html) and it seems very unlikely that there every would be. I would gladly write the code for this myself -- but I suspect that it would take someone longer to review and integrate my changes than it would to just write the code. Thanks, Donovan -- Comment By: iga Seilnacht (zseil) Date: 2006-04-13 02:12 Message: Logged In: YES user_id=1326842 There are already two platform specific functions in urllib module just for this purpose: pathname2url and url2pathname. See http://docs.python.org/lib/module-urllib.html#l2h-3193. I agree that this should be closed as invalid. -- Comment By: Andrew Clover (bobince) Date: 2006-03-20 18:41 Message: Logged In: YES user_id=311085 Filepaths aren't URIs and attempting to hide the difference in the backend is doomed to fail (as it did for SAX). Throw filenames with colons in, network paths, Mac paths and RISC OS paths into the mix, and you've got a situation where it is all but impossible to handle correctly. In any case, the docs *don't* say you can pass in a filepath: If the URL does not have a scheme identifier, or if it has file: as its scheme identifier, this opens a local file This means the string you pass in is unequivocally a URL *not* a pathname... just that you can leave the scheme prefix off for file: URLs. Effectively this is a relative URL. r'C:\spam' is *not* a valid way to refer to a local file using a relative URL. Pass it through pathname2url and you'll get '///C|/spam', which is okay; 'C|/spam' and '/C|span' will also work. Even on Unix, a filepath won't always work when passed to urlopen. Filenames can have percent signs in, which have to be encoded in URLs, for example. Always use pathname2url or you're going to trip up. (Suggest setting status INVALID, possible clarification to docs to warn against passing a filepath to urlopen?) -- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-14 03:32 Message: Logged In: YES user_id=757799 OK - Here's my suggested fix: This can be fixed with a single if statement (and a comment to explain it to confused unix programmers). In splittype(), right after the line that reads: scheme = match.group(1) add the following: #ignore single char schemes to avoid confusion with win32 drive letters if len(scheme) > 1: ...and indent the next line. Alternatively, the if statement could read: if len(scheme) > 1 or sys.platform != 'win32': ...which would allow single letter scheme names on non-Windows systems. I would argue that it is better to be consistent and have it work the same way on all OS's. -- Comment By: Donovan Eastman (dpeastman) Date: 2006-03-14 02:56 Message: Logged In: YES user_id=757799 Reasons why urllib should open local files: 1) This allows you to write code that handles local files and Internet files equally well -- without having to do any special magic of your own. 2) The docs all say that it should. I believe this would work just fine under Unix. In URLopener.open() it looks for the protocol p
[ python-Bugs-1469557 ] FTP modue functions are not re-entrant, give odd exceptions
Bugs item #1469557, was opened at 2006-04-12 17:13
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=1469557&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: Bruce (brucepeterson)
Assigned to: Nobody/Anonymous (nobody)
Summary: FTP modue functions are not re-entrant,give odd exceptions
Initial Comment:
If I define a class using the Thread and FTP moudles,
start a process which gathers FTP responses,
additional calls to the class may have the responses
of the thread instead of the main loop (or vice versa)
This causes weird and unexpected exceptions from the
ftplib.
For instance I get the following error when the
thread process does a pwd() function
error_reply: 213 34603008
The "213" reply is a response from the main process
size() function
-
Code
-
from time import sleep
from threading import Thread
class ftpMachine(Thread, ftplib.FTP):
def __init__(self, svr, user, passwd):
Thread.__init__(self)
ftplib.FTP.__init__(self, svr, user, passwd)
def run(self):
for x in xrange(20):
output="Thread -"+str(self.nlst())[:30]
print output
sleep (0.0100)
def main():
aCon = ftpMachine("LocalFTP", "user", "")
aCon.start()
for x in xrange(20):
output = "Main -- " + str(aCon.size("File"))
print output
sleep (0.010)
Workround:
Rewrite code to create a third worker thread for
response isolation? Don't know that this would solve
the problem.
---
Exception example
---
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python24\lib\threading.py", line 442, in
__bootstrap
self.run()
File "dualFTPIssue.py", line 17, in run
output = "Thread output " + str(self.nlst())[:30]
+" ..."
File "C:\Python24\lib\ftplib.py", line 448, in nlst
self.retrlines(cmd, files.append)
File "C:\Python24\lib\ftplib.py", line 396, in
retrlines
conn = self.transfercmd(cmd)
File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "C:\Python24\lib\ftplib.py", line 321, in
ntransfercmd
host, port = self.makepasv()
File "C:\Python24\lib\ftplib.py", line 299, in
makepasv
host, port = parse227(self.sendcmd('PASV'))
File "C:\Python24\lib\ftplib.py", line 566, in
parse227
raise error_reply, resp
error_reply: 213 34603008
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469557&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1469548 ] Build requires already built Python
Bugs item #1469548, was opened at 2006-04-13 09:54 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469548&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: Build Group: Python 2.5 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: Build requires already built Python Initial Comment: On RedHat 7.1 I ran into the following interesting build bug: $ ./configure (works fine) $ make ./Parser/asdl_c.py -h ./Include -c ./Python ./Parser/Python.asdl File "./Parser.asdl_c.py", line 56 j += 2 # account or the brase and space after it ^ SyntaxError: invalid syntax This is because Python 1.5.2 is the default there -- OK, no problem working around that 'cause I've got other versions there but it seems mighty strange that the very first thing done in a build of Python requires an already-built Python. What happens on an OS where Python isn't there yet at all? -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-13 12:18 Message: Logged In: YES user_id=29957 This is a packaging bug. You can workaround it with 'touch Python/Python-ast.c Python/Python-ast.h' before running make. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469548&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1332852 ] BSD DB test failures for BSD DB 3.2
Bugs item #1332852, was opened at 2005-10-19 21:41
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1332852&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: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Gregory P. Smith (greg)
Summary: BSD DB test failures for BSD DB 3.2
Initial Comment:
After a bunch of modifications to build and get bsddb
mostly running, I still get 4 test failures with Python
2.4 and CVS head.
FAIL: test_previous_last_looping
(test.test_bsddb.TestBTree)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('q', 'Guido'), ('w', 'van'), ('t',
'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
==
FAIL: test_previous_last_looping
(test.test_bsddb.TestHashTable)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
==
FAIL: test_previous_last_looping
(test.test_bsddb.TestBTree_InMemory)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('q', 'Guido'), ('w', 'van'), ('t',
'Python'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
==
FAIL: test_previous_last_looping
(test.test_bsddb.TestHashTable_InMemory)
--
Traceback (most recent call last):
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 128, in test_previous_last_looping
self.assertSetEquals(items, self.d.items())
File
"/home/neal/build/python/dist/clean/Lib/test/test_bsddb.py",
line 55, in assertSetEquals
self.assertEqual(Set(seqn1), Set(seqn2))
AssertionError: Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', None)]) != Set([('e', 'Rossum'), ('r',
'invented'), ('t', 'Python'), ('w', 'van'), ('q',
'Guido'), ('y', '')])
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-12 20:20
Message:
Logged In: YES
user_id=33168
I don't mind and think it's reasonable to set whatever
minimum version for 2.5. I don't think 3.2 support should
be removed from 2.4 though. In 2.4, you can print a message
in setup.py if the version is too old.
I think that's conservative enough and reasonble.
--
Comment By: Gregory P. Smith (greg)
Date: 2006-04-12 12:21
Message:
Logged In: YES
user_id=413
i'd prefer to just not support 3.2 anymore.
mind if i just change setup.py to not accept 3.2?
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-19 22:20
Message:
Logged In: YES
user_id=33168
Oops, that last comment got cut off. I've got db-3.2 and
db-4.1 on my system at least. Not sure why the older one is
picked up rather than the newer one.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-19 22:17
Message:
Logged In: YES
user_id=33168
test_bsddb3 core dumps for me. backtrace attached.
Do we really sup
[ python-Bugs-1469629 ] __dict__ = self in subclass of dict causes a memory leak?
Bugs item #1469629, was opened at 2006-04-13 05:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&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.4 Status: Open Resolution: None Priority: 5 Submitted By: Dobes V (dobesv) Assigned to: Nobody/Anonymous (nobody) Summary: __dict__ = self in subclass of dict causes a memory leak? Initial Comment: Using: ActivePython 2.4.2 Build 10 (ActiveState Corp.) based on Python 2.4.2 (#67, Jan 17 2006, 15:36:03) [MSC v.1310 32 bit (Intel)] on win32 For reasons I do not understand, the following class leaks itself continuously: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) self.__dict__ = self Whereas this version does not: class AttrDict(dict): def __init__(self, *args, **kw): dict.__init__(self, *args, **kw) def __getattr__(self, key): return self[key] def __setattr__(self, key, value): self[key] = value My test looks like this: for n in xrange(100): import gc gc.collect() ad = AttrDict() ad['x'] = n ad.y = ad.x print n, ad.x, ad.y And I sit and watch in the windows task manager while the process grows and grows. With the __getattr__ version, it doesn't grow. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1469629&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-781614 ] Windows _bsddb link warnings
Bugs item #781614, was opened at 2003-08-01 19:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781614&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: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: Windows _bsddb link warnings Initial Comment: Hi, The PCbuild/readme.txt says this: ''' XXX We're actually linking against Release_static\libdb41s.lib. XXX This yields the following warnings: """ Compiling... _bsddb.c Linking... Creating library ./_bsddb.lib and object ./_bsddb.exp LINK : warning LNK4049: locally defined symbol "_malloc" imported LINK : warning LNK4049: locally defined symbol "_free" imported LINK : warning LNK4049: locally defined symbol "_fclose" imported LINK : warning LNK4049: locally defined symbol "_fopen" imported _bsddb.pyd - 0 error(s), 4 warning(s) """ XXX This isn't encouraging, but I don't know what to do about it. ''' The cause of this is the fact that libdb41s.lib is built with the flags for using the "Multithreaded" C RTL but Python uses the "MUltithreaded DLL" C RTL. In other words, libdb is specifying that the C RTL should be linked statically but Python wants to link to it statically. To avoid these warnings the instructions can be changed to specify that the builder should change the flags in the Berkeley_DB project. Also you should probably link with the Debug_static\libdb41sd.lib when building the debug version of Python. -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-13 07:11 Message: Logged In: YES user_id=21627 Right. This problem was fixed with r43002. -- Comment By: Gregory P. Smith (greg) Date: 2006-04-12 22:50 Message: Logged In: YES user_id=413 I believe BerkeleyDB 4.4 when compiled on windows uses the multithreaded DLL C RTL by default even for its static library now so this error should go away? i think this problem is gone for the latest BerkeleyDB and is just a PCbuild readme.txt documentation problem for older BerkeleyDB versions. in the past for stand alone pybsddb bsddb3 packages i always had to change the static build settings of BerkeleyDB to use multi-threaded DLL code generation (/MD flag on cl.exe). With 4.4 i didn't need to do that. (note we weren't linking with the berkeleydb DLL; its the berkeleydb static library, its just that a python extension module is a DLL so the static library code needed to use the same memory model) -- Comment By: Thomas Heller (theller) Date: 2004-02-18 21:18 Message: Logged In: YES user_id=11105 Potentially dangerous - of course. The question is whether this is responsible for some bugs or not. If we cannot link to the DLL then we have to change the build settings for the static builds of libdb41s.lib. -- Comment By: Martin v. Löwis (loewis) Date: 2004-02-18 20:58 Message: Logged In: YES user_id=21627 I think we should avoid linking with the DLL if possible; in some application context, it may be impossible to find the DLL dynamically, or there might be confusion which DLL to load. The linker warning means that there is a conflict between the static (libc.a) and dynamic (msvcr71.dll) version of _free, etc, which potentially means that we are linking conflicting copies of the CRT, which is potentially dangerous. -- Comment By: Thomas Heller (theller) Date: 2004-02-18 18:41 Message: Logged In: YES user_id=11105 It looks to me like we could link to the import library build_win32\Release\libdb41.lib instead of the static library build_win32\Release_static\libdb41s.lib. The former is built with 'multithreaded dll' flags. The downside is that libdb41.dll plus MSVCP60.DLL would have to be distributed. Are the linker warnings a real problem, or only cosmetical? Of course we have to update the build procedure for 2.4 anyway... -- Comment By: Tim Peters (tim_one) Date: 2004-02-17 00:54 Message: Logged In: YES user_id=31435 Thomas, you have any insight into this one? -- Comment By: Martin v. Löwis (loewis) Date: 2003-08-01 21:50 Message: Logged In: YES user_id=21627 Can you propose a specific patch? Also, it would be preferable if changing the source code of the Sleepycat distribution would not be necessary. ---
[ python-Bugs-1467450 ] test_ctypes fails on OSX 10.3
Bugs item #1467450, was opened at 2006-04-10 03:21 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Thomas Heller (theller) Summary: test_ctypes fails on OSX 10.3 Initial Comment: test test_ctypes failed -- Traceback (most recent call last): File "/Users/anthonybaxter/python/Lib/ctypes/test/test_loading.py", line 30, in test_load cdll.load(libc_name) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 112, in load return self._load(libname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 153, in _load return self.load_library(pathname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/_loader.py", line 124, in load_library return self._dlltype(libname, mode) File "/Users/anthonybaxter/python/Lib/ctypes/__init__.py", line 288, in __init__ self._handle = _dlopen(self._name, mode) OSError: dlcompat: unable to open this file with RTLD_LOCAL This happens both with and without the patch in r43748. Darwin sam.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh powerpc GCC version: Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1640) -- >Comment By: Thomas Heller (theller) Date: 2006-04-13 08:59 Message: Logged In: YES user_id=11105 I'm trying to get a copy of OS X 10.3, then will try to install it and look after this problem. OTOH, the ctypes loading code is currently rewritten in the upstream version - this will probably prevent this failure. In the meantime, can you try to find out the cause of this failure? Would RTLD_GLOBAL instead of RTLD_LOCAL work? Is the library file missing? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467450&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
