Bug 59695
| Summary: | [PATCH] devel/gmake: add two patches to avoid core dumps | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Sergey Matveychuk <sem> | ||||
| Component: | Individual Port(s) | Assignee: | Ade Lovett <ade> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | ade | ||||
| Priority: | Normal | ||||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Responsible Changed From-To: freebsd-ports-bugs->ade Over to maintainer. Just to make things a little clearer here. These patches are not freebsd-specific. I've sent email to the gnumake maintainers, asking for a 3.81 release, but have heard nothing back. Since the ports tree is in current semi-freeze pending 5.2-RELEASE, I'm not going to do anything with this update until at least 5.2 is out the door. I would highly recommend that people interested in this update push for it to be integrated into a new release of gmake (along with other bugfixes), at which point I'll pull in a 3.81 (or whatever) release update. -aDe State Changed From-To: open->analyzed This PR will remain on hold as a placeholder. The most appropriate solution is for the gnumake authors to generate a new release. State Changed From-To: analyzed->feedback Having had some further time to test this, it would appear that the problem appears to be fixed. With the test.mk file from ports/74879 I get: (5.4-STABLE/i386) [ade@foo:~/test] 7% gmake -f test.mk gmake: *** virtual memory exhausted. Stop. (6.0-CURRENT/amd64) [ade@nail:~/test] 23% gmake -f test.mk gmake: Nothing to be done for `FOO'. So, for the 4.x case, it appears to be more of an issue with system libraries (probably string functions in libc) than an actual problem with gmake. Given that both 5.x and 6.x appear to do the right thing, I'm really loathed to apply these patches since there does not appear to be an actual need right now. If you can confirm the behavior I've seen above, I think the best thing to do would be to close down the PR. Ade Lovett wrote:
> Having had some further time to test this, it would appear that the
> problem appears to be fixed.
>
> With the test.mk file from ports/74879 I get:
>
> (5.4-STABLE/i386)
> [ade@foo:~/test] 7% gmake -f test.mk
> gmake: *** virtual memory exhausted. Stop.
Honestly, test.mk is correct. It must work, do not infinite loop.
We stop core dumps, but the bug still stay. Bug in GNU make.
Just add in test.mk corresponding targets:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.c:
@echo "NO BUG!"
baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.c:
@echo "NO BUG!"
caaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.c:
@echo "NO BUG!"
daaaaaaaaa.c:
@echo "NO BUG!"
xx.c:
@echo "NO BUG!"
With patches you'll get:
% gmake
NO BUG!
NO BUG!
NO BUG!
NO BUG!
NO BUG!
--
Sem.
Sergey Matveychuk wrote:
> Honestly, test.mk is correct. It must work, do not infinite loop.
> We stop core dumps, but the bug still stay. Bug in GNU make.
I'm not disputing that this apparently fixes an issue in gmake.
However, it appears that the 5.x and 6.x releases are handling the issue
to the point where the problem is heavily mitigated.
My big concern remains that this does change gmake somewhat, which would
at least require a full 4-exp (or is it 5-exp now?) build run across the
entire ports tree. Even if that succeeds, it's still not entirely sure
that there would not be breakage associated with adding these patches,
which may come back to bite us later.
Rather than adding them into the tree, I believe the most correct
approach here would be to work with the GNU make folks to get the
patches incorporated and perhaps a new release rolled. That update
could then have an -exp run made against it and, in this case, we're
using vendor-supplied sources, which I'd feel a lot more comfortable with.
-aDe
Ade Lovett wrote: > My big concern remains that this does change gmake somewhat, which would > at least require a full 4-exp (or is it 5-exp now?) build run across the > entire ports tree. Even if that succeeds, it's still not entirely sure > that there would not be breakage associated with adding these patches, > which may come back to bite us later. I'm agree with you now. I'v decided to add new port gmake-devel. It will not affected on any port. So, it'll beak nothing. Just users, who interested in it, could install it instead of old gmake. > > Rather than adding them into the tree, I believe the most correct > approach here would be to work with the GNU make folks to get the > patches incorporated and perhaps a new release rolled. That update > could then have an -exp run made against it and, in this case, we're > using vendor-supplied sources, which I'd feel a lot more comfortable with. I wrote them a lot. Just like you did (I guess). And still no new release. In february they announsed 3.81 will released in March,1 2005. Even day was promised! Still no the release. But there are many patches and fixes. I think we can got it in ports. Please look at ports/82356. marcus wants your approval. -- Sem. Sergey Matveychuk wrote: > I'm agree with you now. > I'v decided to add new port gmake-devel. It will not affected on any > port. So, it'll beak nothing. > Just users, who interested in it, could install it instead of old gmake. No. Sorry, but this is absolutely NOT going to happen. The absolute last thing we need right now is to have two gmakes in the tree. This will lead to serious confusion for absolutely minimal gain. > Please look at ports/82356. marcus wants your approval. As gmake maintainer, I am not prepared to sign off on this, so the PR is going nowhere. I'm sorry, but the amount of pain likely to be caused by this does not justify the dubious benefits. For instance, out of the 13,000 odd ports we have in the tree right now, I don't see gmake falling over on any of them with this particular issue. -aDe State Changed From-To: feedback->closed These patches need to go upstream for incorporation into a new gnumake release (whenever that may be). Given that none of the 13,000+ ports we have in the tree seem to be affected by this issue, and the problem trigger does appear to be a little contrived, I'm certainly not going to add this as a local patch to the FreeBSD version of gmake, for reasons previously stated in the Audit-trail. Ade Lovett wrote: > No. Sorry, but this is absolutely NOT going to happen. The absolute > last thing we need right now is to have two gmakes in the tree. This > will lead to serious confusion for absolutely minimal gain. No confusion. If user installs -devel port, he understand he could meet problems. > going nowhere. I'm sorry, but the amount of pain likely to be caused by > this does not justify the dubious benefits. For instance, out of the > 13,000 odd ports we have in the tree right now, I don't see gmake > falling over on any of them with this particular issue. Just because I can't add a port that affected the bugs. The problem exist and it don't disappear if you say I see no problem. -- Sem. Hello, I'm not sure if someone noticed this: > gmake -f test.ml gmake: *** virtual memory exhausted. Stop. > echo $LANG LANG: Undefined variable. > setenv LANG en_US.ISO8859-1 > gmake -f test.ml NO BUG! NO BUG! NO BUG! NO BUG! NO BUG! This might help you to solve your specific problem without adding a patch to the devel/gmake port. Björn Björn König wrote:
> Hello,
>
> I'm not sure if someone noticed this:
>
> > gmake -f test.ml
> gmake: *** virtual memory exhausted. Stop.
>
> > echo $LANG
> LANG: Undefined variable.
>
> > setenv LANG en_US.ISO8859-1
>
> > gmake -f test.ml
> NO BUG!
> NO BUG!
> NO BUG!
> NO BUG!
> NO BUG!
>
> This might help you to solve your specific problem without adding a
> patch to the devel/gmake port.
>
> Björn
Yes, it's a good point, thank you. Sadly that gmake maintainer even does
not explore this situatuion for two years while the PR was open.
--
Sem.
Sergey Matveychuk wrote:
> Yes, it's a good point, thank you. Sadly that gmake maintainer even does
> not explore this situatuion for two years while the PR was open.
The gmake maintainer is more interested in keeping the port working for
the thousands of other ports that use it and the associated
infrastructure concerned with keeping a cohesive build environment working.
It is unfortunate that you feel the need to personalize the issue.
The PR is closed, there will not be a repocopy, the issue is finished.
Please try to move on and find something a little more constructive to
do with your time.
Thank you.
-aDe
Ade Lovett wrote:
>
> Please try to move on and find something a little more constructive to
> do with your time.
It's very offensive. All the time I've not stopped committing and
working on PRs.
--
Sem.
|
[DESCRIBE CHANGES] devel/gmake: * Add two patches to avoid core dumps on eval: http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1516&group_id=71 http://savannah.gnu.org/bugs/?func=detailbug&bug_id=1517&group_id=71 * Utilize INFO macro Added file(s): - files/patch-eval_conditional - files/patch-eval_crash Port maintainer (ade@FreeBSD.org) is cc'd. Generated with FreeBSD Port Tools 0.50