Re: make test segfaults with "--enable-shared" on Python 2.3.3

From: Berthold Höllmann (bhoel_at_web.de)
Date: 12/29/03


Date: Mon, 29 Dec 2003 20:47:06 +0100

Andrew MacIntyre <andymac@bullseye.apana.org.au> writes:

> On Sun, 28 Dec 2003, Berthold Hoellmann wrote:
>
>> > When I use
>> >
>> > ./configure --with-thread --with-fpectl --with-signal-module \
>> > --with-pymalloc --enable-shared --with-cxx=g++
>> >
>> > make test
>> >
>> > on 2.3.3 I get
>> >
>> > ...
>> > test_queue
>> > test_quopri
>> > test_random
>> > test_re
>> > make: *** [test] Speicherzugriffsfehler (Speicherauszug erstellt)

     make: *** [test] Segmentation fault (core dumped)

>>
>> Everything works fine if I remove the "--enable-shared" flag from
>> configure.
>
> You don't mention what platform you are seeing this on. The output of a
> verbose test run (python Lib/test/regrtest.py -v test_re), preferably with
> error messages translated to English, may help diagnose the issue.

env LANG=C LD_LIBRARY_PATH=/home/devel/compile/Python-2.3.3:/usr/local/v/lib:/usr/lib/qt3/lib:/usr/local/pgsql/lib:/usr/teTeX/lib./python Lib/test/regrtest.py -v test_re

(LD_LIBRARY_PATH is taken from the "make test" output) gives:

test_re
test_anyall (test.test_re.ReTests) ... ok
test_basic_re_sub (test.test_re.ReTests) ... ok
test_bigcharset (test.test_re.ReTests) ... ok
test_bug_113254 (test.test_re.ReTests) ... ok
test_bug_114660 (test.test_re.ReTests) ... ok
test_bug_117612 (test.test_re.ReTests) ... ok
test_bug_418626 (test.test_re.ReTests) ... ok
test_bug_448951 (test.test_re.ReTests) ... ok
test_bug_449000 (test.test_re.ReTests) ... ok
test_bug_449964 (test.test_re.ReTests) ... ok
test_bug_462270 (test.test_re.ReTests) ... ok
test_bug_527371 (test.test_re.ReTests) ... ok
test_bug_545855 (test.test_re.ReTests) ... ok
test_bug_612074 (test.test_re.ReTests) ... ok
test_bug_725106 (test.test_re.ReTests) ... ok
test_bug_725149 (test.test_re.ReTests) ... ok
test_bug_764548 (test.test_re.ReTests) ... ok
test_category (test.test_re.ReTests) ... ok
test_constants (test.test_re.ReTests) ... ok
test_expand (test.test_re.ReTests) ... ok
test_finditer (test.test_re.ReTests) ... ok
test_flags (test.test_re.ReTests) ... ok
test_getattr (test.test_re.ReTests) ... ok
test_getlower (test.test_re.ReTests) ... ok
test_groupdict (test.test_re.ReTests) ... ok
test_ignore_case (test.test_re.ReTests) ... ok
test_non_consuming (test.test_re.ReTests) ... ok
test_not_literal (test.test_re.ReTests) ... ok
test_pickling (test.test_re.ReTests) ... ok
test_qualified_re_split (test.test_re.ReTests) ... ok
test_qualified_re_sub (test.test_re.ReTests) ... ok
test_re_escape (test.test_re.ReTests) ... ok
test_re_findall (test.test_re.ReTests) ... ok
test_re_groupref (test.test_re.ReTests) ... ok
test_re_groupref_exists (test.test_re.ReTests) ... ok
test_re_match (test.test_re.ReTests) ... ok
test_re_split (test.test_re.ReTests) ... ok
test_re_subn (test.test_re.ReTests) ... ok
test_repeat_minmax (test.test_re.ReTests) ... ok
test_scanner (test.test_re.ReTests) ... ok
test_search_coverage (test.test_re.ReTests) ... ok
test_search_star_plus (test.test_re.ReTests) ... ok
test_special_escapes (test.test_re.ReTests) ... ok
test_sre_character_literals (test.test_re.ReTests) ... ok
test_stack_overflow (test.test_re.ReTests) ... ok
test_symbolic_refs (test.test_re.ReTests) ... ok

----------------------------------------------------------------------
Ran 46 tests in 0.401s

OK
Running re_tests test suite
1 test OK.
CAUTION: stdout isn't compared in verbose mode:
a test that passes in verbose mode may fail without it.

so it seems that the other modules loaded in the "make test" run
decrease the avaliable stack so that the test does not succeed but
calling the test alone finds enough stack space avaliable?

> I know that there are platforms where the amount of stack space available
> to a threaded process is not easily controlled, and recent versions of gcc
> are creating much larger stack frames than earlier versions. The sre
> module in 2.3.x (and earlier) is recursive and thus sensitive to stack
> space availability. A core dump is a likely indicator of this. Read the
> Modules/_sre.c source file for more info. sre in 2.4 will be
> significantly improved in this regard.
>
> FYI, since 2.3 PyMalloc is a default option so you don't need
> --with-pymalloc, and most recent Linux and BSD systems will default to
> building with --with-thread and --with-signal-module.

I really should know, but I usually keep "good" configure settings for
reuse and normally don't think much about the settings when everything
works.

Regards

Berthold

-- 
bhoel@web.de / http://starship.python.net/crew/bhoel/
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.


Relevant Pages

  • Re: setting ulimit -s within /etc/system
    ... -s' reports the default of 8192 regardless of the settings of the two ... Those two parameters are for kernel threads; ... You are interested in the per-process stack; ... We did make note of the fact that both parameters set the kernel ...
    (comp.unix.solaris)
  • Re: Maybe something to vote for...
    ... result is returned in stack and part in var parameter. ... In that regard C# as most other languages does nothing. ...
    (borland.public.delphi.non-technical)
  • Re: Detemining the correct reserve size for each thread stack.
    ... The thread size is typically set to 64K by the linker. ... settings. ... For Pocket PC, you can give a specific stack size for each ... This is outlined in the Pocket PC SDK Help for CreateThread. ...
    (microsoft.public.pocketpc.developer)
  • Re: Stack Allocations: Reserve/Commit...
    ... I've never changed either of those two settings. ... > I did a post a few days ago inquiring about some odd behavior ... How might I know if I'm close to running out of stack space? ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: why does this work ?
    ... >>I'd prefer to call it a stack. ... To clarify my understanding of this: the Standard sets forth a ... limited only by the amount of RAM available. ... all C compilers are non-conforming in this regard. ...
    (comp.lang.c)