Bug 74879
| Summary: | devel/gmake gives a segfault when $(eval ...) has a large argument | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Luigi Rizzo <rizzo> |
| Component: | Individual Port(s) | Assignee: | Ade Lovett <ade> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-ports-bugs->ale Over to maintainer. Responsible Changed From-To: ale->ade No. The maintainer is me (ade), not ale.. There are patches for fixing for a long time ago in ports/59695. Can you check them? -- Sem. State Changed From-To: open->closed This refers to the same problem as 59695, which I'm just about to deal with. |
gmake 3.80 on FreeBSD seems to have problems in handling $(eval ...) with large (~200 chars) arguments, see the test case below which is a largely reduced case from some actual makefiles I had. The same on linux works fine. I did a bit of investigation, and gdb on the core file reports bogus pointers way before the actual stack frame where the program crashes, and the strings that cause the problem are not large enough to suggest that some arbitrary limit is hit in memory allocators etc. Maybe some weird string library function does have small limits, or that gmake is actually buggy by itself and the bug is only masked on linux. Fix: unknown. Have seen this with gmake 3.80, 3.80_1 and 3.80_2 on various versions of 4.x (4.8 4.9 4.10). How-To-Repeat: create a file, say test.mk, with this content: #------------- cut here --------------------- FILES := \ aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.c \ baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.c \ caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.c \ daaaaaaaaa.c xx.c # gmake bug $(eval FOO : $(FILES)) #------------- end of file --------------------- and then run gmake -f test.mk which should give you a nice Segmentation fault (core dumped)