Actually, I did get a minute to look into this:
> > As I (well, really mostly Alan Stewart) have cleaned up the environment
> > processing logic greatly in PAR 0.81 (and now PAR 0.82), I'm curious about
> > whether the heisenbug you mentioned still exists -- I tried to duplicate
> > it here and can no longer see it, but perhaps I didn't try hard enough. :-)
>
> Yes, when we looked into it before, we had to try hard. It
> would appear and disappear, sometimes in connection with
> small changes to the env before running.
The problem still exists, sorry to say, at least one flavor
of it....
Today, working on Linux RH 7.3, using bash, I downloaded,
built, and installed (privately) the following stable
releases --
Archive-Zip-1.10
Compress-Zlib-1.33
Digest-SHA1-2.10
Module-ScanDeps-0.42
Module-Signature-0.38
PAR-0.82
PAR-Dist-0.07
perl-5.8.4
I put their common bin dir at the front of my PATH.
Here is my little perl script, demo.pl --
print "Args = \"@ARGV\"\n";
That's all it contains. If I run 'perl demo.pl 1', it
prints 'Args = "1"' as expected, in all cases.
Now I package it with the newly built pp. I saw the problem
at least once after packaging with 'pp -o demo demo.pl', but
I did more extensive tests after packaging with
'PAR_GLOBAL_CLEAN=1 pp -C -o demo demo.pl' and saw the same
thing.
Much of the time, if I run 'demo 1', it prints 'Args = "1"'
as expected. But sometimes it prints 'Args = ""', which is
wrong; the command-line parameter has been lost.
As far as I can determine, the wrong behavior occurs when
'env | wc' reports a total number of characters which is
a multiple of 4. Thus, I can turn the bad behavior on & off
by running a test sequence like this --
demo 1
export X=1
demo 1
export X=11
demo 1
export X=111
demo 1
export X=1111
...
Each new 'export' command increases the env table length by 1.
Every time I see the bad behavior, 'env | wc' reports a
multiple of 4 characters.
-- Mark
