Attempting to `make' in /usr/ports/mail/nmh causes an attempt to be made to build the /usr/ports/devel/autoconf213 port. Unfortunately, doing `make' in /usr/ports/devel/autoconf213 fails, for the reasons previously explained in PR ports/29392. (NOTE: A copy of the log file from the make of nhm has been mailed to the port maintainer for autoconf.) Fix: Please see PR ports/29392. In the Makefile for autoconf213, you simply have to re-arrange the command line arguments for each of the three invocations of $(MAKEINFO) so that the input filename is the last and final command line argument in each case. Doing that at least gets you past the build problems, however you are still left with a semi-brain-dead `makeinfo' command that will segfault on you (if you don't give it command line arguments in the exact order it seems to want). A *real* fix would be to find out why the makeinfo command is crashing/segfaulting when the name of its input file is not the last and final command line argument, and then hack it so that it won't segfault anymore. (Sorry, this more proper and complete solution is left as an exercise for the reader.) How-To-Repeat: cd /usr/ports/mail/nmh make
On Fri, Nov 22, 2002 at 12:11:58PM -0800, Ronald F.Guilmette wrote: > >>Number: 45598 >>Category: ports >>Synopsis: /usr/ports/devel/autoconf213 fails to build (affecting nmh) Problem is not reproducible. Autoconf213 builds correctly. I'm not going to patch the GNU make mess if the problem only affects one person. Ron, the problem lies in your machine, not in the port or in makeinfo. This port will be put in feedback state for 1 week, during which time submittor can provide evidence of failure on a different system. If no such evidence is forthcoming, the PR will be closed, as was its predecessor. I'm sorry, Ron, but that decision is final. Why don't you just build the autoconf213 port by itself using portupgrade and then portinstall nmh? I have too many things to worry about than to add patches to a port that only fails on one guy's system. -- AlanE (Alan Eldridge), who likes fixing weird distributed systems bugs. Unix/C(++) IT Pro for 20 yrs, desperately seeking employment in NYC. (http://wwweasel.geeksrus.net/~alane/resume.rtf) KDE, KDE-FreeBSD Teams (http://www.kde.org, http://freebsd.kde.org/)
State Changed From-To: open->feedback Need demonstration of reproducibility on another system.
Class Changed From-To: sw-bug->change-request Problem only appears to affect this user's system.
Responsible Changed From-To: freebsd-ports->alane I'm the damn maintainer of the auto**** portgs, that's bloody why.
---Reply to mail from Ronald F. Guilmette about ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh) > > In message <20021122223805.GA77179@wwweasel.geeksrus.net>, you wrote: > >>On Fri, Nov 22, 2002 at 12:11:58PM -0800, Ronald F.Guilmette wrote: >>> >>>>Number: 45598 >>>>Category: ports >>>>Synopsis: /usr/ports/devel/autoconf213 fails to build (affecting nmh) >> >>Problem is not reproducible. Autoconf213 builds correctly. I'm not going >>to patch the GNU make mess if the problem only affects one person. >> >>Ron, the problem lies in your machine, not in the port or in makeinfo. >>This port will be put in feedback state for 1 week, during which time >>submittor can provide evidence of failure on a different system. If no >>such evidence is forthcoming, the PR will be closed, as was its >>predecessor. >> >>I'm sorry, Ron, but that decision is final. Why don't you just build the >>autoconf213 port by itself using portupgrade and then portinstall nmh? >>I have too many things to worry about than to add patches to a port that >>only fails on one guy's system. > > > OK, allow me to make a few comments... > > First, I don't really mind at all if you want to close out this bugreport, > because in retrospect, it was rather badly done (on my part) anyway. It > doesn't state what the _real_ problem(s) is/are. > > I have investigated a bit more deeply now, and now I can say definitively > that the _real_ problems are as follows: > > #1) /usr/bin/makeinfo segfaults. (It shouldn't do that, even when given > command line arguments in a screwy order.) > > (Note that this problem is probably out of your jurisdiction, so > don't worry about it.) > > #2) The Makefile used within /usr/ports/devel/autoconf213 attempts to > supply various option arguments to `makeinfo' _after_ the filename > command line arguments. > > That's just not right, and it won't fly, even after the fundamental > (segfault-causing) bug in `makeinfo' is fixed. > > (Basically, `makeinfo', like all UNIX commands that conform to POSIX > IEEE Std. 1003.2-1992, Section 2.10.2, Guideline #9, expects and > requires all of the option command line arguments to appear on the > invocation line _before_ all of the other, non-option command line > arguments. But the Makefile for autoconf213 attempts, incorrectly > and unworkably, to put the options _after_ the filename arguments > when invoking `makeinfo'. That clearly is a mistake, and it clearly > cannot possibly work, because these days at least, `makeinfo' uses > GNU getopt_long to parse all command line options and arguments, > and that library routine, in turn, itself imposes the disipline that > the options must preceed all of the non-option command line arguments.) > > I have already filed a separate bug report (with fix included) for problem > #1 above (i.e. gnu/45744) and I have sent my fix also to the GNU Project > people. I will file and new and different bug report for problem #2, > listed above, soon. Probably today. > > I cannot account for the fact that you were unable to reproduce the bug(s) > which are clearly present, both in the GNU `makeinfo' source code (causing > the segfault, and documented in some detail in my gnu/45744 bugreport) and > also in the Makefile(s) associated with /usr/ports/devel/autoconf213. My > only theory is that you may perhaps being using some sort of non-ordinary > hardware. > > Did you ask any other people... preferably people with ordinary x86 hardware... > to verify your negative results? If so, what sorts of processors do those > folks use? (I have only AMD-K6 processors here, but those are failr `normal' > as far as i know.) > > It does seem to me that if you had asked a couple of other people with > ordinary x86 machines to try reproducing what I reported, then _somebody_ > should be able to do so without too much effort. > > (If you are reluctant to ask for help, I could ask around and see if I > can find some volunteers.) > > Certainly, you can clearly see from my patch included in my gnu/45744 > bugreport (on `makinfo') that there *is* quite clearly a case there > where a NULL pointer may be dereferenced, resulting is the segfault > and coredump that I have reported, more than a year ago, and also again, > recently. > > I don't believe that there is any basis for controversy about this. The > code speaks for itself, and the existing code is clearly wrong, and clearly > subject to dereferencing of NULL pointers. > > Similarly, the code within the `main' function of `makeinfo' speaks for > itself. It clearly uses the GNU getopt_long library function to parse > all command line arguments, and that function is documented to have > behaviour which expects all options arguments to preceed all non-option > arguments (consistant with POSIX guidelines). Thus, it cannot be at all > controversial that the invocations of `makeinfo' contained within the > Makefiles of /usr/src/devel/autoconf213 in which option arguments are > given *following* non-option arguments are clearly wrong, and that they > clearly should be fixed. > > To summarize, these two bugs _are_ quite clearly and incontrovertably real, > i.e. (1) the segfault bug in `makeinfo' and (2) the option ordering bug > in the Makefiles for /usr/ports/devel/autoconf213. There can be no doubt > that both bugs are real and that both should be fixed, regardless of any > one person's ability of inability to reproduce the exact negative symptoms > of each of these bugs on some specific (single) platform. As I say, the > code speaks for itself, and the code is quite clearly busted. > > With regards to your comment that you aren't going to fix these bugs as > long as only one person is reporting them as bugs, I can only say that > I find that attitude odd. > > I do freely admit that I may perhaps be the last person on the planet > who is still using `nmh' as my mail client, but I do like it, and I do > continue to use it. And it _is_ still present in the FreeBSD ports tree. > If it is not going to be maintained, at least to the point where it can > be built from sources, then perhaps it should be removed from the ports > tree so that people will know that it's just not supported on FreeBSD > anymore. > > I will also stipulate that perhaps the `nmh' port is the one and only > piece of FreeBSD that still requires or has any use for the (otherwise > obsolete) autoconf-2.13 package/port. I'm frankly as surprised as any- > one to see that there are _two_ versions of autoconf being distributed > with FreeBSD (and maintained with it, for certain values of ``maintained''), > one apparently obsolete and the other one apparently not. I think that > maybe we should both ask the current `nmh' port maintainer why the `nmh' > port continues to be reliant on this now-obsolete version of GNU autoconf, > when clearly there is a much fresher version available, and ported, right > there in the ports tree, right next to /devel/autoconf213. I confess > that it is an enigma to me, and I'd love to know what some things in > the ports tree are dependent on obsolete versions of other tools, just > to get themselves built. > > Not that any of that is terribly important, mind you. > > The bottom line is that I have now submitted workable fixes for both of > the two bugs I have noted above. (You already have my trivial set of > suggested patches for the Makefile in /usr/ports/devel/autoconf213 from > my original bugreport over a year ago.) If you elect not to fix the > clearly evident bug in the Makefile for autoconf213, then that's OK > with me. I would only ask that in that case, please also notify whoever > is the master person in charge of the entire ports tree to remove these > packages entirely: > > mail/nhm > devel/autoconf213 > > Those should be removed entirely from the ports tree so that other people > will not make the same mistake as I did, i.e. wrongly assuming that these > packages are still being maintained, even though they have very few users. > > Thanks. > Ron, I have a stock PIII/733 box running a version of STABLE that is 3 days old. /usr/bin/makeinfo does not segfault, nor has it ever. If I can build w/o this problem and the bento cluster can build w/o this problem, I will not change my position regards patching autoconf213. ---End reply -- AlanE (Alan Eldridge), who likes fixing weird distributed systems bugs. Unix/C(++) IT Pro for 20 yrs, desperately seeking employment in NYC. (http://wwweasel.geeksrus.net/~alane/resume.rtf) KDE, KDE-FreeBSD Teams (http://www.kde.org, http://freebsd.kde.org/)
In message <20021122223805.GA77179@wwweasel.geeksrus.net>, you wrote: >On Fri, Nov 22, 2002 at 12:11:58PM -0800, Ronald F.Guilmette wrote: >> >>>Number: 45598 >>>Category: ports >>>Synopsis: /usr/ports/devel/autoconf213 fails to build (affecting nmh) > >Problem is not reproducible. Autoconf213 builds correctly. I'm not going >to patch the GNU make mess if the problem only affects one person. > >Ron, the problem lies in your machine, not in the port or in makeinfo. >This port will be put in feedback state for 1 week, during which time >submittor can provide evidence of failure on a different system. If no >such evidence is forthcoming, the PR will be closed, as was its >predecessor. > >I'm sorry, Ron, but that decision is final. Why don't you just build the >autoconf213 port by itself using portupgrade and then portinstall nmh? >I have too many things to worry about than to add patches to a port that >only fails on one guy's system. OK, allow me to make a few comments... First, I don't really mind at all if you want to close out this bugreport, because in retrospect, it was rather badly done (on my part) anyway. It doesn't state what the _real_ problem(s) is/are. I have investigated a bit more deeply now, and now I can say definitively that the _real_ problems are as follows: #1) /usr/bin/makeinfo segfaults. (It shouldn't do that, even when given command line arguments in a screwy order.) (Note that this problem is probably out of your jurisdiction, so don't worry about it.) #2) The Makefile used within /usr/ports/devel/autoconf213 attempts to supply various option arguments to `makeinfo' _after_ the filename command line arguments. That's just not right, and it won't fly, even after the fundamental (segfault-causing) bug in `makeinfo' is fixed. (Basically, `makeinfo', like all UNIX commands that conform to POSIX IEEE Std. 1003.2-1992, Section 2.10.2, Guideline #9, expects and requires all of the option command line arguments to appear on the invocation line _before_ all of the other, non-option command line arguments. But the Makefile for autoconf213 attempts, incorrectly and unworkably, to put the options _after_ the filename arguments when invoking `makeinfo'. That clearly is a mistake, and it clearly cannot possibly work, because these days at least, `makeinfo' uses GNU getopt_long to parse all command line options and arguments, and that library routine, in turn, itself imposes the disipline that the options must preceed all of the non-option command line arguments.) I have already filed a separate bug report (with fix included) for problem #1 above (i.e. gnu/45744) and I have sent my fix also to the GNU Project people. I will file and new and different bug report for problem #2, listed above, soon. Probably today. I cannot account for the fact that you were unable to reproduce the bug(s) which are clearly present, both in the GNU `makeinfo' source code (causing the segfault, and documented in some detail in my gnu/45744 bugreport) and also in the Makefile(s) associated with /usr/ports/devel/autoconf213. My only theory is that you may perhaps being using some sort of non-ordinary hardware. Did you ask any other people... preferably people with ordinary x86 hardware... to verify your negative results? If so, what sorts of processors do those folks use? (I have only AMD-K6 processors here, but those are failr `normal' as far as i know.) It does seem to me that if you had asked a couple of other people with ordinary x86 machines to try reproducing what I reported, then _somebody_ should be able to do so without too much effort. (If you are reluctant to ask for help, I could ask around and see if I can find some volunteers.) Certainly, you can clearly see from my patch included in my gnu/45744 bugreport (on `makinfo') that there *is* quite clearly a case there where a NULL pointer may be dereferenced, resulting is the segfault and coredump that I have reported, more than a year ago, and also again, recently. I don't believe that there is any basis for controversy about this. The code speaks for itself, and the existing code is clearly wrong, and clearly subject to dereferencing of NULL pointers. Similarly, the code within the `main' function of `makeinfo' speaks for itself. It clearly uses the GNU getopt_long library function to parse all command line arguments, and that function is documented to have behaviour which expects all options arguments to preceed all non-option arguments (consistant with POSIX guidelines). Thus, it cannot be at all controversial that the invocations of `makeinfo' contained within the Makefiles of /usr/src/devel/autoconf213 in which option arguments are given *following* non-option arguments are clearly wrong, and that they clearly should be fixed. To summarize, these two bugs _are_ quite clearly and incontrovertably real, i.e. (1) the segfault bug in `makeinfo' and (2) the option ordering bug in the Makefiles for /usr/ports/devel/autoconf213. There can be no doubt that both bugs are real and that both should be fixed, regardless of any one person's ability of inability to reproduce the exact negative symptoms of each of these bugs on some specific (single) platform. As I say, the code speaks for itself, and the code is quite clearly busted. With regards to your comment that you aren't going to fix these bugs as long as only one person is reporting them as bugs, I can only say that I find that attitude odd. I do freely admit that I may perhaps be the last person on the planet who is still using `nmh' as my mail client, but I do like it, and I do continue to use it. And it _is_ still present in the FreeBSD ports tree. If it is not going to be maintained, at least to the point where it can be built from sources, then perhaps it should be removed from the ports tree so that people will know that it's just not supported on FreeBSD anymore. I will also stipulate that perhaps the `nmh' port is the one and only piece of FreeBSD that still requires or has any use for the (otherwise obsolete) autoconf-2.13 package/port. I'm frankly as surprised as any- one to see that there are _two_ versions of autoconf being distributed with FreeBSD (and maintained with it, for certain values of ``maintained''), one apparently obsolete and the other one apparently not. I think that maybe we should both ask the current `nmh' port maintainer why the `nmh' port continues to be reliant on this now-obsolete version of GNU autoconf, when clearly there is a much fresher version available, and ported, right there in the ports tree, right next to /devel/autoconf213. I confess that it is an enigma to me, and I'd love to know what some things in the ports tree are dependent on obsolete versions of other tools, just to get themselves built. Not that any of that is terribly important, mind you. The bottom line is that I have now submitted workable fixes for both of the two bugs I have noted above. (You already have my trivial set of suggested patches for the Makefile in /usr/ports/devel/autoconf213 from my original bugreport over a year ago.) If you elect not to fix the clearly evident bug in the Makefile for autoconf213, then that's OK with me. I would only ask that in that case, please also notify whoever is the master person in charge of the entire ports tree to remove these packages entirely: mail/nhm devel/autoconf213 Those should be removed entirely from the ports tree so that other people will not make the same mistake as I did, i.e. wrongly assuming that these packages are still being maintained, even though they have very few users. Thanks.
It would appear that the GNU Project's maintainer of the GNU texinfo package (which includes the `makeinfo' utility) concurs with my opinion that `makeinfo' contained a bug that could cause segfaults. It would also appear that he concurs with the patch for `makeinfo' that I sent him. ------- Forwarded Message Return-Path: karl@freefriends.org Delivery-Date: Tue Nov 26 15:16:30 2002 Return-Path: <karl@freefriends.org> Delivered-To: rfg@monkeys.com Received: from f7.net (consort.superb.net [209.61.216.22]) by segfault.monkeys.com (Postfix) with ESMTP id AB1B24225E for <rfg@monkeys.com>; Tue, 26 Nov 2002 15:16:28 -0800 (PST) Received: (from karl@localhost) by f7.net (8.11.6/8.11.6) id gAQNGRb05480; Tue, 26 Nov 2002 18:16:27 -0500 Date: Tue, 26 Nov 2002 18:16:27 -0500 Message-Id: <200211262316.gAQNGRb05480@f7.net> From: karl@freefriends.org (Karl Berry) To: rfg@monkeys.com Cc: bug-texinfo@gnu.org Subject: Re: Segfault in makeinfo in GNU texinfo-4.3 package (fix included) I have been experiencing segmentation faults in makeinfo for quite a long time now... over a year. Please see: http://www.freebsd.org/cgi/query-pr.cgi?pr=45598 Ah. Sorry, I wasn't aware of this. Obviously, it *is* possible for name_index_alist[i] to have a NULL value, Indeed. I moved the undefindex call after the conditional just as you suggested. Thanks much for the report and fix! ~karl ------- End of Forwarded Message
In message <200211270040.gAR0eAe8061034@wwweasel.geeksrus.net>, you wrote: >Ron, I have a stock PIII/733 box running a version of STABLE that is 3 >days old. > >/usr/bin/makeinfo does not segfault, nor has it ever. If I can build w/o >this problem and the bento cluster can build w/o this problem, I will >not change my position regards patching autoconf213. Can you please send me a log of your build of autoconf213? I would just like to see if, when you build it, the `makeinfo' utility program gets invoked with command line option arguments _following_ the filename command line argument, and if so, whether or not that elicits any complaints or warnings from makeinfo. Thanks. P.S. There _should_ be some errors, because the given the command line: makeinfo -I. ./autoconf.texi --no-split --output=autoconf213.info the way that makeinfo is programmed, it _must_ necessarily see all of the arguments after the ./autoconf.texi as also being *input filenames*. And thus, you should get two errors, like: --no-split: File not found --output=autoconf213.info: File not found If you are not getting such errors, then I'd love for you to enlighten me about how you are avoiding doing so. The man page for getopt_long: http://netbsd.gw.com/cgi-bin/man-cgi?getopt_long+3 makes clear that all command line arguments past the first non-option argument will *not* be treated as option arguments. There's no point in us disagreeing about this. The spec for getopt_long is perfectly clear on this point (and it is consistant with POSIX specs), and if you look at the source code for `makeinfo' you'll see quite clearly that it uses GNU getopt_long to parse makeinfo's command line arguments. (The `makeinfo' man page is also pretty clear that all options must come first, followed by all filename arguments.) P.P.S. If you look at the the _current_ GNU version of autoconf, and/or any version since 2.54 (released Sept 13th of this year) you'll see that this (command line argument ordering) bug has already been fixed in the newer GNU versions of autoconf. In those (GNU) releases, the options given on invocations of `makeinfo' already come first, before the filename arguments. I'm basically only suggesting that the FreeBSD port(s) of autoconf should follow suit. Doesn't seem very controversial to me.
State Changed From-To: feedback->closed not a demonstrable problem IMO http://www.freebsd.org/cgi/query-pr.cgi?pr=45598