Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment:
The offending code appears to have been introduced in r33090 and tweaked
in r37025, which both originated from Mark Hammond.
From the comments, there seems to be no reason why the build_lib
override should apply when
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment:
Pretty much all the test structure in the patch has made it through the
re-write to unittest, so closed as out of date.
--
resolution: - out of date
status: pending - closed
Changes by Andrew I MacIntyre aimacint...@users.sourceforge.net:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3868
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment:
I've just built (using ./configure; make) 3.1a on FreeBSD 6.4 amd64.
libpthread is used by the resulting binary, not libc_r, according to ldd.
I would expect then that explicit action is required to use libc_r, and
given
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment:
Antoine, in my testing the loss of the HAS_ARG() optimisation in my
patch appears to have negligible cost on i386, but starts to look
significant on amd64.
On an Intel E8200 cpu running FreeBSD 7.1 amd64, with gcc 7.2.1
Andrew I MacIntyre aimacint...@users.sourceforge.net added the comment:
Out of interest, the attached patch against the py3k branch at r70516
cleans up the threaded code changes a little:
- gets rid of TARGET_WITH_IMPL macro;
- TARGET(op) is followed by a colon, so that it looks like a label
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I believe this issue ties into the underlying problem FreeBSD 6.x upto
and including 6.3R have with fork() in a threaded application - see the
6.3R errata notice referenced in issue3864.
The issue should be fixed in FreeBSD 6.4 (currently
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
The checked in change has the planned effect on FreeBSD 6.3 i386. I
can't check on my 7.0 amd64 box as I can't quickly put a current source
tree on it.
___
Python tracker [EMAIL PROTECTED]
http
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Yes, the bleeding obvious became so after some sleep.
Committed to trunk as r66708 with the extra fix and a more abbreviated
failure message, which I hope is still semantically the same as Mark's
suggested text.
Will forward port
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
The tests are passing on FreeBSD 7.0 (only checked amd64 at this point).
I came across a reference to an errata notice for FreeBSD 6.x which
appears pertinent:
http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc
As I
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I've done some more digging into this for the FreeBSD case.
FreeBSD 6.3 and 7.0 both have sem_open, and the man pages suggest it
should be fully functional. (see
http://www.freebsd.org/cgi/man.cgi?query=sem_openapropos=0sektion=0manpath
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Oops - meant to add that the actual reported cause of the core dump is
Bad system call.
Also, the OpenBSD man pages make clear that shared semaphores aren't
supported and sem_open() doesn't exist:
http://www.openbsd.org/cgi-bin/man.cgi
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I've had a chance to do some testing and it _is_ related to the itimer
tests (in test_wait4).
This is with r66550:
$ ./python -E -tt ./Lib/test/regrtest.py -l -v test_wait4 test_signal
test_wait4
test_wait (test.test_wait4.Wait4Test
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Oops - the itimer tests are in test_signal, not test_wait4.
test_wait4 just triggers the problems in test_signal (both the itimer
problems and the interprocess signal test failure).
___
Python tracker
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
After perusing test_wait4, I tried substituting test_fork1 for
test_wait4 and got the same behaviour from test_signal.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3864
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I compiled the C test case from issue 2240:
$ gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -o test_2240
test_2240.c
{lifted as many gcc options off the standard Python compile as possible}
$ ldd test_2240
test_2240
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Spelunking with test_fork1, it seems that the interprocess signal test
failure is due to the HUP signal not being delivered from the subprocess
to the parent (line 99 of test_signal.py: self.assertTrue(self.a_called
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
From the problematic test run log:
...
test_main (test.test_signal.InterProcessSignalTests) ... FAIL
...
I should be using the full name, sorry.
This failure seems unrelated to the itimer problem though (which is in
itimer_test_prof
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I should be more specific:
itimer_test_prof (test.test_signal.ItimerTest) appears to go into an
infinite loop when run after test_fork1 or test_wait4 have been run.
___
Python tracker [EMAIL PROTECTED
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Committed in revs 66552, 66553 and 66554.
I've blocked r66554 from py3k as other changes are needed for OS/2 (r66555)
I've merged r66552 and r66553 into py3k as they apply cleanly (r66556).
Thanks for the review Amaury
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Mark, your patch will probably get the test to pass, but the underlying
reason the test is failing appears to be unexpected behaviour of the
platform malloc().
FreeBSD 7.0 introduced a new malloc() implementation that relies on
mmap
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
It doesn't appear to me to be related to issue 2240, as my build linked
against libpthread:
$ ldd ./python
./python:
libutil.so.5 = /lib/libutil.so.5 (0x28187000)
libm.so.4 = /lib/libm.so.4 (0x28193000
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I've briefly got a FreeBSD 7.0 amd64 setup available, and test_threading
passes in this environment.
Short term fix I'd suggest is to only disable this part of the test for
FreeBSD 6.x and earlier (ie platforms freebsd4, freebsd5, freebsd6
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I've temporarily got a 7.0 amd64 system running and can confirm what you
see. I checked out the 2.5.2 port patches you mentioned, but all the
ones that seemed related are already in the 2.6rc1 sources.
On a hunch, I used ulimit -v is used
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
On FreeBSD 7.0 i386, test_array passes without ulimit -v needing to be
set (ie its still the default unlimited.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3862
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
test_threading also passes on FreeBSD 7.0 i386.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3863
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I've attached a simple patch which deactivates
test_3_join_in_forked_from_thread on FreeBSD 6.x and earlier, and also
OS/2 EMX. With this patch, test_threading completes but...
$ ./python -E -tt Lib/test/regrtest.py test_threading
Changes by Andrew I MacIntyre [EMAIL PROTECTED]:
--
components: Build, Interpreter Core, Library (Lib), Tests
files: build_os2emx.patch
keywords: patch, patch
nosy: aimacintyre
severity: normal
status: open
title: patch for review: OS/2 EMX port fixes for 2.6
versions: Python 2.6
Added
New submission from Andrew I MacIntyre [EMAIL PROTECTED]:
The 2 attached patch files are patches required for the OS/2 EMX port to
build and function:
- build_os2emx.patch - updates to the Makefile and config files in
PC/os2emx;
- source_os2emx.patch - updates to various core/library/test files
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
2.6rc1 shows the same failure traceback on FreeBSD 6.3, which is covered
by a section of setup.py the same as Damien added for OpenBSD.
--
nosy: +aimacintyre
___
Python tracker [EMAIL PROTECTED
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
2.6rc1 test_array passes on FreeBSD 6.3 i386. I don't have a 7.0 box
(either i386 or amd64) accessible at the moment to cross check.
Can you run the test on its own in verbose mode to get a bit more of an
idea where its blowing up? - ie
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
I should add that this is a regression of the trunk, as I built and
tested the trunk from an SVN checkout (r63892) in early June and didn't
encounter this issue.
___
Python tracker [EMAIL PROTECTED]
http
Changes by Andrew I MacIntyre [EMAIL PROTECTED]:
--
versions: +Python 2.6
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3864
___
___
Python-bugs-list
Andrew I MacIntyre [EMAIL PROTECTED] added the comment:
Freelist clearing functions for int and float were added by Christian,
and made available to Python code via a function in the sys module. I
don't know who added the freelist clearing functions for the class,
frame, method, tuple
New submission from Andrew I MacIntyre [EMAIL PROTECTED]:
The attached patch adds free list clearing routines for the list, dict
set objects. These objects are the only ones with free lists that don't
already have some form of free list management API. This patch
complements the patch
New submission from Andrew I MacIntyre [EMAIL PROTECTED]:
In r60567, support for compacting the int float freelists was added
with a function in the sys module to call the compaction routines.
Since then, other freelist clearing routines have been added to other
types and are called from
Andrew I MacIntyre added the comment:
As noted in a posting to python-dev, I've re-evaluated my test methodology.
The results are as follows, with details of the PyBench runs in the
pybench_summary.txt attachment:
--
test
Andrew I MacIntyre added the comment:
My conclusions from the testing I've just reported:
- there are some contradictory results which make little (obvious)
sense, but the testing has been repeated a number of times and nearly
all tests repeat to with 1%;
- leave the int freelist as is, but move
Andrew I MacIntyre added the comment:
I've realised I could have included tests for a build with the int
freelist but without the float freelist, to justify my conclusions. The
short version: the script tests are almost identical to the baseline
result most of the other results are between
Andrew I MacIntyre added the comment:
As indicated in a python-dev posting, I'm adding my experimental grade
patches removing the freelists from ints and floats.
Subject to testing on other platforms (I've only tested on FreeBSD 6.1
and OS/2), I suggest that the float case should be seriously
40 matches
Mail list logo
