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 c
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
complemen
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
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 blowi
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 <[E
Changes by Andrew I MacIntyre <[EMAIL PROTECTED]>:
--
versions: +Python 2.6
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3864>
___
_
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: Pyth
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/librar
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 &
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
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 fr
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 u
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://
Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:
test_threading also passes on FreeBSD 7.0 i386.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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 tes
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 o
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 t
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_wait
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 t
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.pytho
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
tes
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_
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_
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
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
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_open&apro
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.o
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 FreeB
Andrew I MacIntyre <[EMAIL PROTECTED]> added the comment:
On FreeBSD 7.0 amd64, applying Mark's patch does get the test to pass.
As noted on python-dev, the response I got from the author of the new
malloc() package in FreeBSD 7.x indicates that as of 7.1 the allocator
defaults to
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 <[EMAI
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 forw
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
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:
--
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
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 ar
Andrew I MacIntyre 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 (for
editors that make use of that
Andrew I MacIntyre 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 and the
3.1a2 so
Andrew I MacIntyre 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 that FreeBSD people have indi
Andrew I MacIntyre 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 the target version is specifica
Andrew I MacIntyre 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
___
Python tracker
Changes by Andrew I MacIntyre :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue3868>
___
___
Python-bugs-list mailing list
Un
41 matches
Mail list logo
