My initial comment about ARGV is wrong - I must have hit something magical
*somewhere* else! Alas, I don't think you're gonna be able to repeat it.

This is most odd. I have a program that can cause dump in question but if
I make the slightest code change then it works fine.

 - Adding a print statement to beginning of code make it work
 - commenting out some statement makes it work
 - renaming program makes it work (!!!)
 - running on difference machine works - basically same perl build
   except faulty is on i586 Linux 2.2.16 and successful is on i686 2.2.14
 - running under debug works

 - reording statements - same problem - core dump
 - changing text of a variable assignment - same problem - core dump
 - renaming its directory - same problem

If you want me to try any other sort of diagnostics I'll hold on to it.

Cheers,
Jay

On Fri, 29 Sep 2000, Hugo wrote:

>  In <20000930070622.3588.qmail@[...].com>, jlawrenc@[...].com writes:
>  :By assigning $ARGV[1] to a variable:
>  : $lang=$ARGV[1] || "e";
>  :and then later using it in hash references:
>  : $blort{'e'}="Happy day"
>  : print $blort{$lang}
>  :I sometimes core dump.
>  
>  That seems very strange. If you can find a way of making it reliably
>  reproducible and then cut it down to a small test case it would be
>  very helpful. It initially sounds as if the original system memory
>  for the arguments is being moved out from under you, but as far as I
>  can see the arguments are _copied_ into newly acquired memory when
>  setting up the ARGV array. (In 5.6.0 this should be done by the code:
>              SV *sv = newSVpv(argv[0],0);
>  at line 3180 of perl.c).
>  
>  If that is the case, it sounds likely to be a more random corruption
>  that just happens to be hitting this variable. If so, I'd expect
>  you to see other variables causing a coredump from time to time as
>  well. This shouldn't be happening. :)
>  
>  Hugo
>