[ python-Bugs-1075703 ] PyGILState_Ensure() deadlocks (ver 2.4)
Bugs item #1075703, was opened at 2004-11-29 17:54
Message generated for change (Comment added) made by andivajda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470
Category: Threads
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Andi Vajda (andivajda)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyGILState_Ensure() deadlocks (ver 2.4)
Initial Comment:
PyLucene (http://pylucene.osafoundation.org) wraps
libgcj with python. Python objects are also wrapped by
java objects. The ref count of the python is
incremented in the wrapping java object constructor and
is decremented in the wrapping java object's finalize()
method. Yes, finalize() is not a reliable means of
cleaning memory up but, so far, I wasn't able to figure
out a better way to do this. The finalize() method runs
in its own libgcj finalizer thread.
It has to acquire the GIL before it can call
Py_DECREF() is my understanding. The java finalize()
calls this code in PyLucene:
void finalizeObject(PyObject *object)
{
#if PY_VERSION_HEX >= 0x0204
PyGILState_STATE state = PyGILState_Ensure();
Py_DECREF(object);
PyGILState_Release(state);
#endif
}
When compiled with python 2.4c1, this mostly works.
Except that it deadlocks, every now and then. If I
comment this code out, no deadlock. I also verified
that the finalizer is called at most once per such
object. I realize that reproducing this bug maybe hard,
building PyLucene is not particularly easy, unless you
have gcj ready.
If you contact me, I'm more than willing to help in
providing all that's needed to reproduce this. I've
seen the deadlock on Mac OS X 10.3.6, my main
development OS.
For what it's worth, I also tried this with python
2.3.4 (including threadmodule.c patch made in
September, related to GIL function usage).
--
>Comment By: Andi Vajda (andivajda)
Date: 2004-12-04 20:15
Message:
Logged In: YES
user_id=1139346
I finally tracked down this bug to gcj bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16478";>16478
which is fixed in gcj version >= 3.4.2.
I am hence closing this python bug as invalid.
--
Comment By: Andi Vajda (andivajda)
Date: 2004-12-03 19:42
Message:
Logged In: YES
user_id=1139346
I've been running the same test loop on Gentoo/2.6/python
2.4 and was not able to get it to deadlock so far. This bug
could be limited to Mac OS X.
--
Comment By: Andi Vajda (andivajda)
Date: 2004-12-03 19:10
Message:
Logged In: YES
user_id=1139346
I verified this now with python 2.4 final. It still happens
as tested on Mac OS X.
I was also able to narrow it down to a unit test, that when
run repeatedly will eventually lock up. It is attached.
If you need assistance building PyLucene from sources, or
want me to provide a binary, let me know. At the moment, to
reproduce this bug, it is best to build PyLucene from
subversion.
See http://pylucene.osafoundation.org for more information.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1075703&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076485 ] Another message that croaks email.FeedParser
Bugs item #1076485, was opened at 2004-11-30 23:00 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076485&group_id=5470 Category: Python Library >Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Another message that croaks email.FeedParser Initial Comment: The attached message causes a TypeError exception with the email.FeedParser class that comes with Python 2.4. The traceback I get is: Traceback (most recent call last): File "", line 1, in ? File "/Users/skip/local/lib/python2.4/mailbox.py", line 35, in next return self.factory(_Subfile(self.fp, start, stop)) File "/Users/skip/local/lib/python2.4/site-packages/spambayes/mboxutils.py", line 129, in get_message msg = email.message_from_string(obj) File "/Users/skip/local/lib/python2.4/email/__init__.py", line 43, in message_from_string return Parser(*args, **kws).parsestr(s) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 79, in parsestr return self.parse(StringIO(text), headersonly=headersonly) File "/Users/skip/local/lib/python2.4/email/Parser.py", line 68, in parse feedparser.feed(data) File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 146, in feed self._call_parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 150, in _call_parse self._parse() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 331, in _parsegen for retval in self._parsegen(): File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 228, in _parsegen for retval in self._parsegen(): File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 190, in _parsegen for line in self._input: File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 119, in next line = self.readline() File "/Users/skip/local/lib/python2.4/email/FeedParser.py", line 79, in readline if ateof(line): TypeError: expected string or buffer -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-12-04 22:30 Message: Logged In: YES user_id=12800 I have a fix for this which I'll commit to the CVS head and release24-maint. The problem is caused by a place where readline() could have returned NeedsMoreData, but that case wasn't being checked. If you use email.message_from_*, that uses the Parser interface, which reads the text in 8192 byte chunks. The test message just happens to have the first 8192 chunk fall inside a line in the message/delivery-status, which was the block that had the readline() that failed to check for NeedsMoreData. BTW, you can work around this by using the FeedParser interface directly, since that doesn't chunk the input. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4"
Bugs item #1079134, was opened at 2004-12-04 18:29 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) Assigned to: Nobody/Anonymous (nobody) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. -- >Comment By: Tim Peters (tim_one) Date: 2004-12-04 21:45 Message: Logged In: YES user_id=31435 The truth (which is more involved than your characterization) is in the NEWS file: """ SF bug #1028306: Trying to compare a ``datetime.date`` to a ``datetime.datetime`` mistakenly compared only the year, month and day. Now it acts like a mixed-type comparison: ``False`` for ``==``, ``True`` for ``!=``, and raises ``TypeError`` for other comparison operators. Because datetime is a subclass of date, comparing only the base class (date) members can still be done, if that's desired, by forcing using of the approprate date method; e.g., ``a_date.__eq__(a_datetime)`` is true if and only if the year, month and day members of ``a_date`` and ``a_datetime`` are equal. """ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1071516 ] test_subprocess fails on cygwin
Bugs item #1071516, was opened at 2004-11-23 03:34 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Peter Åstrand (astrand) Summary: test_subprocess fails on cygwin Initial Comment: [10:29] $python -V Python 2.4c1 [10:30] $ [10:31] $ [10:31] $python -c 'from test.test_subprocess import test_main; test_main()' -v test_args_string (test.test_subprocess.ProcessTestCase) ... ok test_call_kwargs (test.test_subprocess.ProcessTestCase) ... ok test_call_seq (test.test_subprocess.ProcessTestCase) ... ok test_call_string (test.test_subprocess.ProcessTestCase) ... ok test_communicate (test.test_subprocess.ProcessTestCase) ... ok test_communicate_pipe_buf (test.test_subprocess.ProcessTestCase) ... ok test_communicate_returns (test.test_subprocess.ProcessTestCase) ... ok test_cwd (test.test_subprocess.ProcessTestCase) ... ok test_env (test.test_subprocess.ProcessTestCase) ... ok test_exceptions (test.test_subprocess.ProcessTestCase) ... ok test_executable (test.test_subprocess.ProcessTestCase) ... ok test_invalid_args (test.test_subprocess.ProcessTestCase) ... ok test_list2cmdline (test.test_subprocess.ProcessTestCase) ... ok test_no_leaking (test.test_subprocess.ProcessTestCase) ... ok test_poll (test.test_subprocess.ProcessTestCase) ... ok test_preexec (test.test_subprocess.ProcessTestCase) ... ok test_run_abort (test.test_subprocess.ProcessTestCase) ... ok test_shell_sequence (test.test_subprocess.ProcessTestCase) ... ok test_shell_string (test.test_subprocess.ProcessTestCase) ... ok test_stderr_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stderr_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stderr_none (test.test_subprocess.ProcessTestCase) ... ok test_stderr_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdin_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdin_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdin_none (test.test_subprocess.ProcessTestCase) ... ok test_stdin_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_filedes (test.test_subprocess.ProcessTestCase) ... ok test_stdout_fileobj (test.test_subprocess.ProcessTestCase) ... ok test_stdout_none (test.test_subprocess.ProcessTestCase) ... this bit of output is from a test of stdout in a different process ... ok test_stdout_pipe (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_file (test.test_subprocess.ProcessTestCase) ... ok test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines (test.test_subprocess.ProcessTestCase) ... FAIL test_universal_newlines_communicate (test.test_subprocess.ProcessTestCase) ... ok test_wait (test.test_subprocess.ProcessTestCase) ... ok test_writes_before_communicate (test.test_subprocess.ProcessTestCase) ... ok == FAIL: test_stdout_stderr_pipe (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 191, in test_stdout_stderr_pipe self.assertEqual(stripped, "appleorange") AssertionError: 'apple' != 'appleorange' == FAIL: test_universal_newlines (test.test_subprocess.ProcessTestCase) -- Traceback (most recent call last): File "/usr/lib/python2.4/test/test_subprocess.py", line 312, in test_universal_newlines "line1\nline2\nline3\nline4\nline5\nline6") AssertionError: 'line1\n' != 'line1\nline2\nline3\nline4\nline5\nline6' -- Ran 37 tests in 109.478s FAILED (failures=2) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/test/test_subprocess.py", line 548, in test_main test_support.run_unittest(ProcessTestCase) File "/usr/lib/python2.4/test/test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "/usr/lib/python2.4/test/test_support.py", line 274, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred in test.test_subprocess.ProcessTestCase -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071516&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 19:39 Message: Logged In: YES user_id=80475 No, I simply tried the OP's example and reported its behavior on my system. If you don't want to create a new test file, try adding this on to test_subprocess. Yes, I read the patch. Yes, I forgot you added the assertion already. So are you going commit or wait for an engraved invitation? -- Comment By: Michael Hudson (mwh) Date: 2004-12-04 16:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 15:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). -- Comment By: Michael Hudson (mwh) Date: 2004-12-04 15:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. -- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 15:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 06:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-03 23:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I
[ python-Bugs-1079134 ] datetime changes missing from "Porting from 2.3 to 2.4"
Bugs item #1079134, was opened at 2004-12-04 23:29 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=1079134&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sadruddin Rejeb (sadrejeb) Assigned to: Nobody/Anonymous (nobody) Summary: datetime changes missing from "Porting from 2.3 to 2.4" Initial Comment: Since Python2.4, it's impossible to compare date and datetime when it was possible to do so in previous versions. I think this changed behaviour is missing from the "What's new in Python 2.4" documentation and should figure in the "porting from 2.3 to 2.4" section. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079134&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1078905 ] Docs for unittest run() methods are misleading
Bugs item #1078905, was opened at 2004-12-04 09:42 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 >Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for unittest run() methods are misleading Initial Comment: In the unittest module, the methods TestCase.run() and TestSuite.run() are not very useful and the documentation for them is misleading. I'm not sure whether to call this a problem with the docs or the code, but I think the easiest fix is to change the docs. >From the documentation, you would think that to specialize the way a TestCase or TestSuite is run, you should override the run() methods. For example, you might try this: The output from this program is just My test The problem is that the run() methods are never used by the rest of the framework. In both cases, run() is equivalent to __call__(), and it is __call__() that is actually used by the rest of the framework. To get the expected output, change 'run' to '__call__' in four places, then you will see this: Suite start MyTests run My test Suite end I suggest that, at a minimum, the documentation should be changed to refer to __call__() instead of run for these two classes. Possibly the code should be changed to either get rid of run() or actually use it, but I'm not so sure this can be done without breaking existing usage. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 16:24 Message: Logged In: YES user_id=80475 Fixed. See Lib/unittest.py 1.37 and 1.36.2.1 Thanks for the bug report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- >Comment By: Michael Hudson (mwh) Date: 2004-12-04 21:11 Message: Logged In: YES user_id=6656 Hmm. Did you try a debug build and/or a range of arguments? Is os.read actually tested anywhere? I can't find any... > Also, you could prevent/detect future errors by adding an > assertion (checking for negative arguments) to > PyString_FromStringAndSize(). Did you read the patch? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 20:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). -- Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. -- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 04:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument -- Comment By: James Y Knight (foom) Date: 2004-12-01 23:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PySt
[ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1
Bugs item #1076467, was opened at 2004-12-01 03:45 Message generated for change (Comment added) made by nijel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached -- Comment By: Michal Čihař (nijel) Date: 2004-12-04 22:05 Message: Logged In: YES user_id=192186 I meant, that as root you can do anything regardless actual file permissions: as root: # mkdir test # touch test/file # chmod 400 test # ll -d test dr 2 root root 4096 2004-12-04 22:00 test # rm -rf test # as user: $ mkdir test $ touch test/file $ chmod 400 test $ ll -d test dr 2 michal michal 4096 2004-12-04 22:05 test $ rm -rf test rm: cannot chdir from `.' to `test': Permission denied $ -- Comment By: Edward C. Jones (edcjones) Date: 2004-12-04 18:47 Message: Logged In: YES user_id=58796 I am having the same problem with Mandrake 10.1. I have an AMD chip with at least a i686 architecture. My Mandrake 10.1 is set at security level 3. In the past (RedHat, Gentoo), I have installed programs from source as follows: 1. su to root. 2. Copy the tar ball (.tgz, .tar.gz, or .tar.bz2) into /usr/local/src. 3. Expand the tar ball. 4. cd to the top directory of the new source tree. 5. Follow the directions given there. For Mandrake 10.1, this process failed when installing Python 2.4. The failure occured during "make test" in test_shutil.py with the same error message as above in this thread. Nigel said above that "This failure happens only when testing as root, because then permissions don't have usual meaning". Have the meaning of the root permissions changed? What do the root permissions now mean? Is this documented somewhere? -- Comment By: Michal Čihař (nijel) Date: 2004-12-02 12:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. -- Comment By: Pierre (pierre42) Date: 2004-12-01 22:35 Message: Logged In: YES user_id=512388 Same here. -- Comment By: Michal Čihař (nijel) Date: 2004-12-01 16:11 Message: Logged In: YES user_id=192186 Same happends on i386 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-01 16:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) >Assigned to: Michael Hudson (mwh) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 15:58 Message: Logged In: YES user_id=80475 No doubt it is a clear bug. My note was just a data point. Had I been able to reproduce the error on my machine, I would have been able to make a test_case and checkin a fix. So, please, if you can demonstrate the error, go ahead and check-in a fix with a testcase. The OSError is probably fine though there is an alternative of having a ValueError raised immediately after the args are parsed in the read() method. Also, you could prevent/detect future errors by adding an assertion (checking for negative arguments) to PyString_FromStringAndSize(). -- Comment By: Michael Hudson (mwh) Date: 2004-12-04 15:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. -- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 15:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 06:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-03 23:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument -- Comment By: James Y Knight (foom) Date: 2004-12-01 18:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. -- You can respond by visiting: https:/
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-01 21:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- >Comment By: Michael Hudson (mwh) Date: 2004-12-04 20:38 Message: Logged In: YES user_id=6656 I'm surprised at all this discussion. It's a clear bug. The only question is what the error message should be. The attached makes it OSError: [Errno 22] Invalid argument which seems most faithful to what the read() syscall does. -- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 20:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 11:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 04:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument -- Comment By: James Y Knight (foom) Date: 2004-12-01 23:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-01 22:40 Message generated for change (Comment added) made by gerrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- Comment By: Gerrit Holl (gerrit) Date: 2004-12-04 21:13 Message: Logged In: YES user_id=13298 FWIW, another data point, Python 2.4., Linux 2.6.9, Fedora Core 3: $ python2.4 t.py < /usr/src/linux/README Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 22] Invalid argument $ python2.4 t.py < /dev/zero Traceback (most recent call last): File "t.py", line 3, in ? os.read(0, -1) OSError: [Errno 14] Bad address $ python2.4 t.py < /dev/urandom Segmentation fault Interesting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 12:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 05:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument -- Comment By: James Y Knight (foom) Date: 2004-12-02 00:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077302 ] test_macostools failure on OS X
Bugs item #1077302, was opened at 2004-12-01 20:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath -- >Comment By: Brett Cannon (bcannon) Date: 2004-12-04 12:04 Message: Logged In: YES user_id=357491 Aha! That missing directory is the problem. If you read the docs on what macostools.mkalias does is it creates a Finder shortcut for a location. Well, it fails because it can't make a shortcut to a non-existent location. OK, I have uploaded a patch that basically just checks for sys.prefix's existence; if it is missing the test just returns without running. I figured creating the directory would be the improper thing to do since ``make install`` will handle that and use specific permissions I didn't want to override by having the test create it. If you can, Ian, apply the patch and let me know if it fixes the issue. -- Comment By: Ian Holsman (webperf) Date: 2004-12-04 01:37 Message: Logged In: YES user_id=5209 Python 2.4 (#1, Dec 2 2004, 11:53:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.prefix /Library/Frameworks/Python.framework/Versions/2.4 This directory doesn't exist. the make test uses DYLD_FRAMEWORK_PATH -- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 14:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? -- Comment By: Ian Holsman (webperf) Date: 2004-12-03 02:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal -- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 02:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? -- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 02:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeo
[ python-Bugs-1079011 ] Incorrect error message (somewhat)
Bugs item #1079011, was opened at 2004-12-04 20:44 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=1079011&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect error message (somewhat) Initial Comment: Comparing complex numbers with cmp yields: >>> cmp(1+3j, 1+3j) 0 >>> cmp(1+3j, 3+4j) Traceback (most recent call last): File "", line 1, in ? TypeError: cannot compare complex numbers using <, <=, >, >= Well, I didn't use <, <=, > or >=. It's not a major bug, but it doesn't look too nice... would it be possible to return NotImplemented? Or would that be semantically incorrect? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1079011&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076467 ] test_shutil fails on x86-64 // Suse 9.1
Bugs item #1076467, was opened at 2004-12-01 02:45 Message generated for change (Comment added) made by edcjones You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ross G Baker Jr (rossgbaker2) Assigned to: Nobody/Anonymous (nobody) Summary: test_shutil fails on x86-64 // Suse 9.1 Initial Comment: Here is the log of the single failing test: attached -- Comment By: Edward C. Jones (edcjones) Date: 2004-12-04 17:47 Message: Logged In: YES user_id=58796 I am having the same problem with Mandrake 10.1. I have an AMD chip with at least a i686 architecture. My Mandrake 10.1 is set at security level 3. In the past (RedHat, Gentoo), I have installed programs from source as follows: 1. su to root. 2. Copy the tar ball (.tgz, .tar.gz, or .tar.bz2) into /usr/local/src. 3. Expand the tar ball. 4. cd to the top directory of the new source tree. 5. Follow the directions given there. For Mandrake 10.1, this process failed when installing Python 2.4. The failure occured during "make test" in test_shutil.py with the same error message as above in this thread. Nigel said above that "This failure happens only when testing as root, because then permissions don't have usual meaning". Have the meaning of the root permissions changed? What do the root permissions now mean? Is this documented somewhere? -- Comment By: Michal Čihař (nijel) Date: 2004-12-02 11:57 Message: Logged In: YES user_id=192186 This failure happens only when testing as root, because then permissions don't have usual meaning, when testing as user, it works fine. -- Comment By: Pierre (pierre42) Date: 2004-12-01 21:35 Message: Logged In: YES user_id=512388 Same here. -- Comment By: Michal Čihař (nijel) Date: 2004-12-01 15:11 Message: Logged In: YES user_id=192186 Same happends on i386 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1076467&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1078919 ] Email.Header encodes non-ASCII content incorrectly
Bugs item #1078919, was opened at 2004-12-04 07:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: Email.Header encodes non-ASCII content incorrectly
Initial Comment:
I'm generating a MIME message with an attachment whose
filename includes non-ASCII characters. I create the
MIME header as follows:
msg.add_header('Content-Disposition', 'attachment',
filename=u'Fu\xdfballer_sind_klug.ppt')
The Python-generated header looks like this:
Content-disposition:
=?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9IkZ1w59iYWxsZXJf?=
=?utf-8?q?sind=5Fklug=2Eppt=22?=
I sent messages with this header to Gmail, evolution,
and thunderbird, and none of them correctly decode that
header to suggest the correct default filename.
However, I've found that those three mailers do behave
correctly when the header looks like this instead:
Content-disposition: attachment;
filename="=?iso-8859-1?q?Fu=DFballer=5Fsind=5Fklug=2Eppt?="
Is there a way to make Python's email module generate a
Content-disposition header that works with common MUAs?
I know I can manually encode the filename before
passing it to add_header(), but it seems that Python
should be doing this for me.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078919&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1078905 ] Docs for unittest run() methods are misleading
Bugs item #1078905, was opened at 2004-12-04 14:42 Message generated for change (Settings changed) made by kjohnson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) >Summary: Docs for unittest run() methods are misleading Initial Comment: In the unittest module, the methods TestCase.run() and TestSuite.run() are not very useful and the documentation for them is misleading. I'm not sure whether to call this a problem with the docs or the code, but I think the easiest fix is to change the docs. >From the documentation, you would think that to specialize the way a TestCase or TestSuite is run, you should override the run() methods. For example, you might try this: The output from this program is just My test The problem is that the run() methods are never used by the rest of the framework. In both cases, run() is equivalent to __call__(), and it is __call__() that is actually used by the rest of the framework. To get the expected output, change 'run' to '__call__' in four places, then you will see this: Suite start MyTests run My test Suite end I suggest that, at a minimum, the documentation should be changed to refer to __call__() instead of run for these two classes. Possibly the code should be changed to either get rid of run() or actually use it, but I'm not so sure this can be done without breaking existing usage. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1078905 ] Docs for run() methods are misleading
Bugs item #1078905, was opened at 2004-12-04 14:42 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=1078905&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: Docs for run() methods are misleading Initial Comment: In the unittest module, the methods TestCase.run() and TestSuite.run() are not very useful and the documentation for them is misleading. I'm not sure whether to call this a problem with the docs or the code, but I think the easiest fix is to change the docs. >From the documentation, you would think that to specialize the way a TestCase or TestSuite is run, you should override the run() methods. For example, you might try this: The output from this program is just My test The problem is that the run() methods are never used by the rest of the framework. In both cases, run() is equivalent to __call__(), and it is __call__() that is actually used by the rest of the framework. To get the expected output, change 'run' to '__call__' in four places, then you will see this: Suite start MyTests run My test Suite end I suggest that, at a minimum, the documentation should be changed to refer to __call__() instead of run for these two classes. Possibly the code should be changed to either get rid of run() or actually use it, but I'm not so sure this can be done without breaking existing usage. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1078905&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1061968 ] threads: segfault or Py_FatalError at exit
Bugs item #1061968, was opened at 2004-11-07 16:30 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1061968&group_id=5470 Category: Threads Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Mark Hammond (mhammond) Summary: threads: segfault or Py_FatalError at exit Initial Comment: I couldn't reproduce this bug on any machine but mine, but after investigation it looks like a real locking bug in pystate.c which triggers under a certain timing. Attached is a small example which triggers the problem repeatedly on my machine, together with the output I get with a Python interpreter where I inserted debug prints in pystate.c:zapthreads() and pystate.c:PyThreadState_Delete(). My problem is that zapthreads() gets called before the last C thread finishes to call PyGILState_Release(). The very final call that PyGILState_Release() makes to PyThreadState_Delete() -- *after* it releases all locks -- then occurs after zapthreads() has cleared everything. Crash. Can't fix it myself because I don't know anything about PyGILState_*() and the intent of the various locks... Boosted to priority 9 because it looks like it should be fixed before 2.4b3. -- >Comment By: Armin Rigo (arigo) Date: 2004-12-04 11:46 Message: Logged In: YES user_id=4771 Yes, I double-checked again and I can confirm that the patch of pystate.c rev 2.38 was back-ported to 2.3. Closing the bug report... -- Comment By: Tim Peters (tim_one) Date: 2004-12-02 16:04 Message: Logged In: YES user_id=31435 I may be wrong, but I'm pretty sure Armin already backported all the thread fixes that went into 2.4 (including this one). -- Comment By: Mark Hammond (mhammond) Date: 2004-12-02 07:34 Message: Logged In: YES user_id=14198 OK, I'll take it on for 2.3, but it might be worth reminding me next you get the smell of a new 2.3 release. -- Comment By: Brett Cannon (bcannon) Date: 2004-12-02 06:30 Message: Logged In: YES user_id=357491 Any chance this can get backported to 2.3? -- Comment By: Armin Rigo (arigo) Date: 2004-11-08 14:12 Message: Logged In: YES user_id=4771 It looks fine and I can't reproduce the problem any more. Thanks for the fix! -- Comment By: Tim Peters (tim_one) Date: 2004-11-08 04:32 Message: Logged In: YES user_id=31435 I may not be able to do anything here on Monday, so I checked in the patch, but will leave the report open until Armin can add more info: Misc/NEWS 1.1186 Python/pystate.c 2.38 -- Comment By: Tim Peters (tim_one) Date: 2004-11-08 01:12 Message: Logged In: YES user_id=31435 Thanks, Mark! It's great to get another set of "been there, done that" eyeballs on thread nasties. The symptoms look the same as the ones Guido reported 4 years ago, and there seems to be a clear reason for why they reappeared, so I'm optimistic that fixing it the same way again will work. -- Comment By: Mark Hammond (mhammond) Date: 2004-11-07 22:51 Message: Logged In: YES user_id=14198 Damn - Tim beat me - I missed his comment and came up with an almost identical patch. I could not provoke the error on my RH8 box, so can't offer any more assurance this fixes the underlying bug -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 22:26 Message: Logged In: YES user_id=31435 Back to Armin -- would you please try the attached patch (gilrelease.txt)? I've never been able to provoke this bug, so I can only verify that other tests don't break. -- Comment By: Tim Peters (tim_one) Date: 2004-11-07 19:48 Message: Logged In: YES user_id=31435 Nasty, nasty, nasty. This is a reappearance of this miserable old bug: http://www.python.org/sf/225673 BTW, the comments there explain why I'm unlikely to see it on Windows. That bug got fixed in rev 2.41 of threadmodule.c, by introducing the new PyThreadState_DeleteCurrent() function, which deletes the current tstate *while* holding the GIL. Guido should have inserted a large block of screaming comments at the same time, explaining how horridly subtle the need for that was. 3 years and 7 months later, Mark reintroduced the problem, in rev 2.59 of threadmodule.c. That replaced the PyThreadState_DeleteCurr
[ python-Bugs-1077106 ] Negative numbers to os.read() cause segfault
Bugs item #1077106, was opened at 2004-12-02 06:40 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Negative numbers to os.read() cause segfault Initial Comment: Python 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3.3.4 (Debian 1:3.3.4-12)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys, os >>> stdin = sys.stdin.fileno() >>> os.read(stdin, 0) '' >>> os.read(stdin, 0) '' >>> os.read(stdin, -1) asdkljasd 'asdk\x01\x00\x00\x00\x00\x00' >>> os.read(stdin, 100) Segmentation fault [EMAIL PROTECTED]:~$ This problem persists in Python 2.4, although the resulting incorrect behavior differs slightly (at least on my build), as is to be expected of a memory corrupting bug. Note that the value returned from os.read(stdin, -1) is incorrect in addition to the subsequent read segfaulting. -- Comment By: George Yoshida (quiver) Date: 2004-12-04 20:43 Message: Logged In: YES user_id=671362 On Win2k(Python 2.3.4 & 2.4), I get: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 12] Not enough space On Linux(SUSE 9.2 & kernel 2.6.5-7.108-smp & gcc 3.3.3) in Python 2.4 debug built, I get: >>>os.read(si, -1) asd Debug memory block at address p=0x4024d6b8: 31 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x4024d6d7 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x0a *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb The block was made by call #10310 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff 00 00 00 00 61 73 64 Fatal Python error: bad trailing pad byte Aborted In a normal built, same as Jp. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-04 13:29 Message: Logged In: YES user_id=80475 In both Py2.3.4 and Py2.4, I get the following correct behavior on WinME: >>> os.read(si, -1) Traceback (most recent call last): File "", line 1, in ? OSError: [Errno 22] Invalid argument -- Comment By: James Y Knight (foom) Date: 2004-12-02 08:11 Message: Logged In: YES user_id=1104715 This appears to be because PyString_FromStringAndSize takes a signed int for size, doesn't verify that it is > 0, and then adds it to sizeof(PyStringObject): op = (PyStringObject *)PyObject_MALLOC(sizeof(PyStringObject) + size); PyObject_MALLOC will fail if given a < 0 size, but, if size is > -sizeof(PyStringObject), the object will be allocated, but too small. Then, memory gets clobbered. If it returned NULL like it should, posix_read's error handling would be fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1077302 ] test_macostools failure on OS X
Bugs item #1077302, was opened at 2004-12-02 15:24 Message generated for change (Comment added) made by webperf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1077302&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Ian Holsman (webperf) Assigned to: Nobody/Anonymous (nobody) Summary: test_macostools failure on OS X Initial Comment: hi.. I'm a newbie on this stuff.. just trying to install the latest & greatest and have come up with this issue $ uname -a Darwin dyn-130-194-244-92.its.monash.edu.au 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc ^^10.3.6 Powerbook G4 1.5ghz box $ ./configure --prefix=/ex --enable-toolbox-glue --enable-framework $ make ... $ make test ... test test__locale failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test__locale.py", line 43, in test_lc_numeric "%s != %s (%s); " AssertionError: , != . (decimal_point); supposed to be fr_FR, set to fr_FR test_aepack ... test_locale test_locale skipped -- Locale support on MacOSX is minimal and cannot be tested test_logging test_long test_long_future test_longexp test_macfs test_macostools test test_macostools failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/python/Python-2.4/Lib/plat-mac/macostools.py", line 39, in mkalias relativefsr = File.FSRef(relative) Error: (-43, 'File not found') test_macpath -- >Comment By: Ian Holsman (webperf) Date: 2004-12-04 20:37 Message: Logged In: YES user_id=5209 Python 2.4 (#1, Dec 2 2004, 11:53:05) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.prefix /Library/Frameworks/Python.framework/Versions/2.4 This directory doesn't exist. the make test uses DYLD_FRAMEWORK_PATH -- Comment By: Brett Cannon (bcannon) Date: 2004-12-04 09:23 Message: Logged In: YES user_id=357491 The test_shutil failure has already been reported; bug #1076467 and it seems to have to do with running as root. As for the test_macostools failure, lets take this one step at a time. What is the value for sys.prefix? Does that directory exist on your machine when you run the test? -- Comment By: Ian Holsman (webperf) Date: 2004-12-03 21:46 Message: Logged In: YES user_id=5209 when running the tests as root it fails 3 tests ;( 3 tests failed: test__locale test_macostools test_shutil 32 tests skipped: test_al test_bsddb test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_nis test_normalization test_ossaudiodev test_pep277 test_poll test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 1 skip unexpected on darwin: test_tcl test_shutil test test_shutil failed -- Traceback (most recent call last): File "/python/Python-2.4/Lib/test/test_shutil.py", line 34, in test_on_error self.assertEqual(self.errorState, 2) AssertionError: 0 != 2 test_signal -- Comment By: M.-A. Lemburg (lemburg) Date: 2004-12-03 21:30 Message: Logged In: YES user_id=38388 Jurjen, can you put some more context with that ? What does test_locale have to do with Unicode ? -- Comment By: Jurjen N.E. Bos (jneb) Date: 2004-12-03 21:21 Message: Logged In: YES user_id=446428 Yep, I have met this too. It has to do with the uniccodeobject.py, that does not want HAVE_USABLE_WCHAR_T without HAVE_WCHAR_H (sorry if I got the names slightly wrong). This is the case on the Mac, where WCHAR_T is defined in another file, and WCHAR_H does not exist. Who can fix unicodeobject.h? Thanks, Jurjen -- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:45 Message: Logged In: YES user_id=357491 OK, I have no problem with the test failing. What happens if you execute using sudo; ``sudo make test``? -- Comment By: Brett Cannon (bcannon) Date: 2004-12-03 15:23 Message: Logged In: YES user_id=357491 The test__locale failure is known about (OS X does some funky stuff with C's locale library). As
