Using snapshot: python_2003-05-19_230000.tar.gz
STABLE (FreeBSD 4.8-STABLE #14: Mon Apr  7)
CURRENT (most recent 5.1-BETA FreeBSD 5.1-BETA #24: Tue
May 20)

BUILDFAILURE
curses does not build; neither on CURRENT nor on STABLE
(compiler complaint:

/usr/include/ncurses.h:289: conflicting types for `wchar_t'
/usr/include/stdlib.h:57: previous declaration of `wchar_t'
/usr/include/ncurses.h:292: conflicting types for `wint_t'
/usr/include/wchar.h:96: previous declaration of `wint_t'

if lines /usr/include/ncurses.h:288-293 

#ifndef __wchar_t
typedef unsigned long wchar_t;
#endif /* __wchar_t */
#ifndef __wint_t
typedef long int wint_t;
#endif /* __wint_t */

are deleted then curses builds)

TESTFAILURES
test_re fails on both CURRENT and STABLE
 
test_long
test_pow 
and many more (probably related) tests 

fail on current

See attached file for details

Logged In: YES 
user_id=33168

I think many of the failures are due to the test_long
failure.  If that problem is fixed, my guess is several
other tests will start working.

What compiler are you using?  Can you try to debug the
test_long failure?  I don't think any python developers have
access to a freebsd box.

Logged In: YES 
user_id=782552

I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release).

Most of the test failures seem to be gcc-bugs.
Rebuilding world with the extra compiler flag 

   -mno-sse2

got rid of most test failures. Now only the test_re failure and
the curses build failure remain.

Logged In: YES 
user_id=782552

Most of the test failures on FreeBSD CURRENT seem to be gcc
bugs.
(I use gcc (GCC) 3.2.2 [FreeBSD] 20030205 (release))
Rebuilding world with the additional compiler flag 
  -mno-sse2
got rid of most test failures.

Now only the curses build failure and the test_re failure
remain.

Logged In: YES 
user_id=33168

Can you determine what the conflict in the header files
which prevents curses from building?

My guess is that test_bug_418626() is causing the core dump
(from test_re.py).  Can you verify the problem is in that
function?  If so, can you test each of the
re.match/re.search in the interpreter to determine which
line is failling?

My guess is that it's related to the recursion limit (likely
the last line).  Your stack size limit may be too small for
the python recursion limit.  You can try doing a ulimit -a
to see all the limits.  ulimit -s 8192 is what my stack size
is set to (but on Linux).  Doing that command may work for
you.  But this is all conjecture until you investigate further.

Logged In: YES 
user_id=782552

it seems that test_stack_overflow is the culprit

...
    def test_stack_overflow(self):
        # nasty case that overflows the straightforward
recursive
        # implementation of repeated groups.
        self.assertRaises(RuntimeError, re.match, '(x)*',
50000*'x')
        self.assertRaises(RuntimeError, re.match, '(x)*y',
50000*'x'+'y')
        self.assertRaises(RuntimeError, re.match, '(x)*?y',
50000*'x'+'y')
...

>>> A.test_stack_overflow()

Process Python bus error (core dumped)

Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*', 5000*'x')
<_sre.SRE_Match object at 0x81d2b20>
>>> re.match('(x)*', 50000*'x')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*y', 50000*'x'+'y')

Process Python bus error (core dumped)
Python 2.3b1+ (#1, May 20 2003, 11:38:20) 
[GCC 2.95.4 20020320 [FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or "license" for more
information.
>>> import re
>>> re.match('(x)*?y', 5000*'x'+'y')
<_sre.SRE_Match object at 0x81523a0>
>>> re.match('(x)*?y', 50000*'x'+'y')

Process Python bus error (core dumped)

Logged In: YES 
user_id=782552

I forgot to mention that stack size is probably not the problem
(FreeBSD 5.1 and 4.8 behave identical with respect to
test_re.py) 
====================================
FreeBSD 4.8-STABLE FreeBSD 4.8-STABLE #14: Mon Apr  7
17:43:45 JST 2003  i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  524288
stack size              (kbytes, -s)  65536
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  896
open files                      (-n)  1792
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited

================================================================
FreeBSD 5.1-BETA FreeBSD 5.1-BETA #25: Thu May 22 09:10:55
JST 2003 i386

+ ulimit -a
cpu time               (seconds, -t)  unlimited
file size           (512-blocks, -f)  unlimited
data seg size           (kbytes, -d)  1572864
stack size              (kbytes, -s)  1572864
core file size      (512-blocks, -c)  unlimited
max memory size         (kbytes, -m)  unlimited
locked memory           (kbytes, -l)  unlimited
max user processes              (-u)  5547
open files                      (-n)  11095
virtual mem size        (kbytes, -v)  unlimited
sbsize                   (bytes, -b)  unlimited

Logged In: YES 
user_id=250749

Sigh...

Stacksize is indeed the problem with the test_re failure.

In the pthreads case, on FreeBSD prior to 5.x (I have no
info about 5.x, but from what you say it looks the same),
linking to libc_r causes the "initial" thread to get a hard
coded 1MB stack.  The stack size cannot be changed
(currently) without rebuilding libc_r :-(

As all these regression tests are running on the "initial"
thread, by virtue of not having been explicitly started in a
thread.

The problem is worse with gcc 3.x than 2.95, as gcc 3.x (I
tested with 3.2.2) seems to the stack  more aggressively.

I plan to post a patch to _sre.c extending the FreeBSD/gcc
specific #ifdef'ery (which was put in just before 2.3b1, and
was broken again by _sre commits shortly after 2.3b1).

configure --without-threads doesn't have a problem.

building a threaded interpreter with the Linuxthreads port
also doesn't suffer this problem.

I will be looking into preparing a FreeBSD patch to try and
allow a way to vary the "initial" thread stack size at
compile time, rather than libc_r build time.

This problem has been giving me the irrits since it first
appeared at the beginning of April.

Logged In: YES 
user_id=250749

The _sre recursion limit was tweaked in _sre.c revision
2.98, which should deal with the bus error in test_re - at
least until thestack consumption per recursion increases again.

gcc 2.95 (FreeBSD 4.x) is set to 7500, gcc 3.x (FreeBSD 5.x)
is set to 6500 (tested on 4.8R).

The curses build problem should be addressed by revision 1.7
of Include/py_curses.h (tested on 4.8R)

Please let me know if the above fixes are satisfactory on
5.x. Is there anything else still needing attention?

Logged In: YES 
user_id=782552

The good news first: test_re works on STABLE/CURRENT and curses
builds on STABLE. 

curses still fails to build on CURRENT but this (as well as
for STABLE)  is really a FreeBSD problem (too many unrelated
guards). I am waiting for answers from various FreeBSD
mailing lists.
In the meantime I patched /usr/include/ncurses.h

Your patch for py_curses.h works for FreeBSD4 but for FreeBSD5 
you would also have to add 

#ifndef __wchar_t
#define __wchar_t
#endif
#ifndef __wint_t
#define __wint_t
#endif

All these guards should be replaced in ncurses.h by
_W{CHAR,INT}_T_DECLARED I believe (on CURRENT)

However I hope that eventually somebody from FreeBSD
will respond and that this problem will be dealt with from 
the FreeBSD side.   
 
The most recent test failure is test_signal. It boils down to
import signal

def handler(signum,frame):
    raise Exception

signal.signal(signal.SIGALRM,handler)
signal.alarm(5)
signal.pause()
signal.alarm(0)

hanging and not raising an exception on CURRENT with 
python2.3. However any of the following work: replacing
i) CURRENT by STABLE, or i) python2.3 by python2.2, or 
iii) SIGALRM by SIGVTALRM

Logged In: YES 
user_id=21627

Please, folks, one bug per bug report. I think the original
bugs reported in this bug report have been either fixed or
identified as third-party (i.e. OS) bug. So I'm closing it
as fixed.

If any issues remain, please submit a new bugreport. Feel
free to add a note here indicating the new bug report
number, and perhaps assign it right-away to aimacintyre, as
he'll most likely investigate it further (Andrew, if you
won't, feel free to unassign it).