[Python-bugs-list] [ python-Bugs-740234 ] test/build-failures on FreeBSD stable/current
SourceForge.net
noreply@sourceforge.net
Mon, 26 May 2003 19:37:16 -0700
Bugs item #740234, was opened at 2003-05-20 03:50
Message generated for change (Comment added) made by tpx
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: Till Plewe (tpx)
Date: 2003-05-27 02: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 01: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-24 23: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 05: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 04: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-21 22: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