Hi,
On May 25, 2004, at 3:18 PM, Mark Reboul wrote:
[...]The problem still exists, sorry to say, at least one flavor of it....
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.
I never passed the results of my own tests on to the PAR list, but, if you're pursuing this issue now they might be helpful. What follows is an editted copy of a report I sent to Mark Reboul last December 23.
I can provide the test outputs mentioned there, as well, if you think they'd be useful.
------------------------
Last Friday I ran a series of tests using the Perl and modules that Brad built in /utils/bin. I found that it seems to be a very subtle bug under Linux - it manifests itself more clearly in SGI and AIX Perl.
First, I discovered one other interesting characteristic - in my testing,
it looked like the bug only appeared when the executable name had a length
which was a multiple of four. So, an executable called "demo" manifested
the problem, and so did an executable named "demodemo"; but executables
named "d", "de", "dem", "demo5", "demo66", and "demo777" (all created from
the same "demo.pl" script) all seemed to work normally.
Also, under Linux the bug shows no clear dependence on how the
"LANG", "LC_CTYPE" and "LC_ALL" are set. I tried various combinations of
settings and found no discernible pattern - actually, most combinations
worked. Under SGI and AIX, there was no dependence on these variables;
things always failed when the length of the executable name was a multiple
of four. I've attached my test scripts and a test outputs for these
tests,in case anyone's curious.
I did a fresh build of perl 5.8.2, PAR, and it's associated modules on my
home machine and ran my test set against that, too. It failed in a manner
similar to the way Brad's Perl 5.8.1 instalation failed, but the
particular combinations of environment variable settings that would
trigger the bug were different(!!). Also, the problem seemed to be a
Heisenbug in my home Perl 5.8.2 build, in that the conditions that elicted
the bug (quite reproducibly) in my test set didn't seem to trigger it when
running by hand in an instrumented build of PAR. I haven't had time to
pursue further than that yet.
