Bug 45598

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/)

Comment 2 Alan Eldridge 2002-11-22 22:49:39 UTC

State Changed
From-To: open->feedback

Need demonstration of reproducibility on another system. 

Comment 3 Alan Eldridge 2002-11-22 22:49:39 UTC

Class Changed
From-To: sw-bug->change-request

Problem only appears to affect this user's system. 

Comment 4 Alan Eldridge 2002-11-22 22:49:39 UTC

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.

Comment 9 Alan Eldridge 2002-12-09 19:06:09 UTC

State Changed
From-To: feedback->closed

not a demonstrable problem IMO
http://www.freebsd.org/cgi/query-pr.cgi?pr=45598