pkg/41941: games/wesnoth - core dump from make, NetBSD 4.0

[kre%munnari.OZ.AU@localhost]

>Number:         41941
>Category:       pkg
>Synopsis:       games/wesnoth - core dump from make, NetBSD 4.0
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 26 11:20:00 +0000 2009
>Originator:     Robert Elz
>Release:        NetBSD 4.0_STABLE
>Organization:
        Prince of Songkla University
>Environment:
System: NetBSD jade.coe.psu.ac.th 4.0_STABLE NetBSD 4.0_STABLE 
(JADE-1.696-20080517) #9: Fri May 23 18:55:13 ICT 2008 
kre%jade.coe.psu.ac.th@localhost:/usr/obj/4/kernels/JADE i386
Architecture: i386
Machine: i386
>Description:
        Since the upgrade of games/wesnoth (back at the end of March,
        I have been sitting on this problem hoping to analyse further...)
        I get a core dump from make in the "making install from src"
        phase of the build on a fairly pure NetBSD 4.0 system.

>How-To-Repeat:
        I use pkg_comp with NetBSD 4.0 sets installed (except the x* sets,
        for X I use pkgsrc modular xord) and libkver to simulate a fairly
        pure NetBSD 4.0 environment.

        When building the latest games/wesnoth (or anything since the beginning
        of April, if it has been upgraded again since then), I see ...

Making install in m4
Making install in src
[1]   Segmentation fault (core dumped) (CDPATH="${ZSH_V...
*** Error code 1

Stop.

        The core dump is from make itself - from inside memmove()
        it appeared - I don't understand the x86 architecture well
        enough to tell exactly what the problem might be (the faulting
        instruction is rep movl... (or something like that) - the
        (I am guessing) instruction that implements almost all of the
        memmove loop (in the aligned addresses case it appeared).

        It did not look as if the problem related to null pointers
        (but, I might not be reading things correctly).

        One obvious possibility might have been simply overflowing
        some memory limit (most likely stack, as data should fail a
        sbrk() rather than generating trapping addresses), but
        increasing the limits made no difference (and that was
        neevr necessary for the earlier version of wesnoth in the
        same environment, and while its code might have changed a
        lot, it's a little hard to believe that there's some major
        difference in the way that src install makefile works...)

        It isn't too hard to regenerate this if obtaining more
        information would help in some way.

>Fix:
        ???