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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/41941; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/41941: games/wesnoth - core dump from make, NetBSD 4.0 
Date: Mon, 19 Oct 2009 18:53:46 +0700

     Date:        Mon,  7 Sep 2009 06:30:04 +0000 (UTC)
     From:        David Holland <dholland-bugs%NetBSD.org@localhost>
     Message-ID:  <20090907063004.1C43863BC1D%www.NetBSD.org@localhost>
 
 Sorry, I didn't notice this message when it was sent (and I think I
 would have been too busy back then to do much about it anyway).
 
   |  Yeah, but from that perspective, if it has a bug, it has a bug, and
   |  you're stuck.
 
 Unless I can find what it is in the Makefile that triggers the bug
 and find an alternative way to write that that doesn't cause problems.
 This is the only package in pkgsrc that is causing this problem, and
 it used to be OK (before an upgrade in late March or early April),
 so something changed then that is triggering the bug.
 
   |  Could be, but it might be difficult to find it, or having found it,
   |  fix it. Which depends on exactly where it's bombing. If it's bombing
   |  in the game's own install rules, it's probably not any of make's more
   |  abstruse features, which means it's probably some kind of overflow.
 
 Perhaps, though I don't see anything in the relevant Makefile that
 looks as if it should be doing that - and what's more, that same Makefile
 works OK to compile the code in the directory, it is when it is used as
 "make install" that make is core dumping.
 
   |  Do you have the backtrace from the core file? Just the function names
   |  may be enough to give a good idea of what's up.
 
 Sure, but I can do better than that, I recompiled (NetBSD 4.0's) make
 with -static -g (it still core dumps just the same way), and gdb
 tells me on that ...
 
 Core was generated by `make'.
 Program terminated with signal 11, Segmentation fault.
 #0  0xbbbc1f52 in memmove () from /usr/lib/libc.so.12
 (gdb) bt
 #0  0xbbbc1f52 in memmove () from /usr/lib/libc.so.12
 #1  0x08056c37 in ParseGetLine (flags=0, length=0xbfbfc9dc) at parse.c:2130
 #2  0x08057681 in Parse_File (name=0x806247b "Makefile", fd=4) at parse.c:2307
 #3  0x08053b64 in ReadMakefile (p=0x806247b, q=0x0) at main.c:1199
 #4  0x080545e6 in main (argc=2, argv=0xbfbfd8b4) at main.c:979
 
 all of which suggests to me that it is failing while reading and
 parsing the Makefile, which makes it even weirder to understand how
 it read and parsed the same Makefile earlier in the build process.
 
 Oh, I think I know - the Makefile it is reading when it crashes is
 an auto-built dependency file (.deps/game.pO) - that starts with
 one long (continued) line that is 72KB long.   I recall reading
 on the list about a bug (now fixed) where lines that grew bigger
 than 64KB caused a core dump, that's almost certainly the one.
 
 This also suggests a trivial patch - stuff built from pkgsrc has
 no real need of dependencies (the world always all gets built, then
 all thrown away, the cookie files prevent one from just doing "make"
 again without "make clean" in between - pkgsrc isn't intended to be
 used by the people deleveloping the package's software.   By simply
 deleting the .include of the big dependency file from the parent
 Makefile everything works just fine.   Now I just need to need to find
 a good way to have pkgsrc automate that.
 
   |  Well, there are two things we ought to find out. One is whether
   |  anything needs to be pulled up to 4.0_PATCH to make it work (because
   |  if so, that should be done regardless),
 
 Well, I can tell you this was fixed in a netbsd-4 make from May 22
 (and so, everything after that, and maybe sometime before it as well.)
 I just happened to have a NetBSD 4_STABLE version lying around that
 I compiled then so I just copied its /usr/bin/make (binary) to my NetBSD 4.0
 pkg_comp sandbox, and used that (which would have proved nothing if it
 failed, that's not a sane thing to expect to work necessarily, but ...)
 it didn't fail, that one worked fine.
 
 On the other hand, a NetBSD 4.0.1 version of make does fail, so the
 bug is in all released versions of NetBSD 4 (that is, 4.0, and 4.0.1)
 and given NetBSD's history, those will be the only versions of NetBSD 4
 ever released (NetBSD has never released an upgrade of an earlier
 release after the following major release, we now have NetBSD 5, so
 history says there will never be a 4.0.2 or a 4.1 release.)
 
 That means that as long as NetBSD 4 is supposed to be supported by
 pkgsrc, we should find some kind of a workaround, as we cannot really
 tell people they have to run a non-released NetBSD 4_STABLE of at
 least some particular date.
 
   |  and the other is how to work
   |  around the problem with the plain 4.0 make.
 
 yes, fortunately, that one is looking as if it might not be too hard now.
 
   |  A quick and dirty way to work around the problem is to confirm that it
   |  works with 5.0's make (because I hope it does...)
 
 It does, I took sources from NetBSD 5.0 (release) and compiled that
 make under NetBSD 4, and it had no problem.
 
   | and then put
   |  
   |  .if (${OPSYS} == "NetBSD" && !empty(OS_VERSION:M4.*))
   |  USE_TOOLS+=gmake
   |  .endif
 
 I have yet to try that one, but it will probably work.   Can we not
 have
        USE_TOOLS+=bmake
 to use devel/bmake instead of requiring gmake ?   It doesn't look as if
 the pkgsrc infrastructure supports that, other than when bmake is
 installed as a part of the bootstrap process on systems that need it.
 That's a pity.   It would be useful for this kind of problem (much
 nicer to deal with bmake than gmake...)
 
 That way might be easier than figuring out how to remove the dependency
 that is causing the problem.
 
 Thanks,
 
 kre