GNU bug report logs - #25629
Automake output non-deterministic when used with later Perls

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Karl Berry <karl <at> freefriends.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#25629: closed (Automake output non-deterministic when used
 with later Perls)
Date: Sun, 16 Jun 2024 01:19:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 15 Jun 2024 19:18:43 -0600
with message-id <202406160118.45G1IhWQ586894 <at> freefriends.org>
and subject line Re: bug#25629: Hrm, actually autom4te isnt part of automake, but rather autoconf.
has caused the debbugs.gnu.org bug report #25629,
regarding Automake output non-deterministic when used with later Perls
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
25629: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: demerphq <demerphq <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: Automake output non-deterministic when used with later Perls
Date: Mon, 6 Feb 2017 03:32:11 +0100

Some time back I switched Perl to using a randomly seeded hash
function. (I am a core perl committer, and I do a lot of work on its
hash function.)

A consequence of this is that default output from tools like
Data::Dumper is non-deterministic, meaning output files under source
control, etc, change unnecessarily every time.

At least part of the automake toolset is affected, for instance autom4te.

For autom4te a simple solution is to add:

$Data::Dumper::Sortkeys = 1;

to the script. This seems to fix the problem I was observing, but an
audit of the use of  the "keys" function to ensure that any such use
for output is sorted will eliminate this class of errors.

I would be happy to put together a pull request, or a patch if you
could point me to the relevant repository. (Which does not appear to
be documented in the installed versions of automake, although I may
have overlooked it.)

I am sorry I cannot give a better reproduction description than this:

while hacking the "dieharder" package I observed that after running
"autoreconf -i" that the file ./autom4te.cache/requests file changed
in ways that it should not have. Opening the file I observed it
contains output clearly from the Perl Data::Dumper module, I then made
the patch to autom4te described above, and observed that after running
"autoreconf -i" again the output was sorted, and that after running it
yet again the file was unchanged.

Classic unsorted use of undefined hash order bug that we had to do a
lot of cleanup in the Perl world around the time of Perl 5.10

Thanks,
Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

[Message part 3 (message/rfc822, inline)]

From: Karl Berry <karl <at> freefriends.org>
To: demerphq <at> gmail.com
Cc: 25629 <at> debbugs.gnu.org
Subject: Re: bug#25629: Hrm, actually autom4te isnt part of automake,
 but rather autoconf.
Date: Sat, 15 Jun 2024 19:18:43 -0600

Hi Yves - back in 2017 you sent a patch to sort keys in automake:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25629
    Attached is a patch that I believe fixes any remaining uses of
    unsorted keys.

I've now applied this, with the exception of
a) the cases that had already been done in the meantime,

b) gendocs.sh and gitlog-to-changelog, which are maintained in gnulib
(I forwarded the changes there and they have been applied), and

c) help2man, which is maintained separately; I would have forwarded that
change to bug-help2man <at> gnu.org except that as far as I can see this is a
case where truly no sorting is needed. It's purely an internal
assignment:
--- a/doc/help2man
+++ b/doc/help2man
@@ -204,7 +204,7 @@ while (@opt_include)
 # Compress trailing blank lines.
 for my $hash (\(%include, %append))
 {
-    for (keys %$hash) { $hash->{$_} =~ s/\n+$/\n/ }
+    for (sort keys %$hash) { $hash->{$_} =~ s/\n+$/\n/ }
 }
 
 sub get_option_value;

So I'm closing the bug.

Belated thanks for the contribution.
(And Sam, thanks for unearthing this and bringing it up again.)

Happy hashing,
karl

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.