[Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current
SourceForge.net
noreply@sourceforge.net
Sun, 01 Jun 2003 00:47:27 -0700
Bugs item #740234, was opened at 2003-05-20 13:50
Message generated for change (Comment added) made by aimacintyre
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470
Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Till Plewe (tpx)
Assigned to: Nobody/Anonymous (nobody)
Summary: test/build-failures on FreeBSD stable/current
Initial Comment:
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
----------------------------------------------------------------------
>Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-06-01 17:47
Message:
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.
----------------------------------------------------------------------
Comment By: Till Plewe (tpx)
Date: 2003-05-27 12:37
Message:
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
----------------------------------------------------------------------
Comment By: Till Plewe (tpx)
Date: 2003-05-27 11:59
Message:
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)
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-25 09:40
Message:
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.
----------------------------------------------------------------------
Comment By: Till Plewe (tpx)
Date: 2003-05-22 15:04
Message:
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.
----------------------------------------------------------------------
Comment By: Till Plewe (tpx)
Date: 2003-05-22 14:57
Message:
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.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 08:34
Message:
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.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=740234&group_id=5470