Possible angle on JPL failures

Hello,

Re:  persistent JPL failures/core dumps with Java 1.2 and 1.3. 

Some brute force debugging on my host (Solaris 2.7 host with Perl 
5.005_03) revealed that the Sample.java core dumps are occurring
in the embedded interpreter (PerlInterpreter.c): 

PerlInterpreter.c -> perl_parse -> perl.c -> init_postdump_symbols: 

Here's the scene of the crime in init_postdump_symbols: 

   for (; *env, env++) {
     ...
     fprintf(stderr, "postdump: *s++=\\0 at s='%s'\n",s);   # I added
     *s++ = '\0';   # core dump
     ...
   }


Apparently Java is no longer tolerant of native code environment 
diddling... ?

Perhaps  Perl could dup the environment to avoid the snafu but I'm 
not really familiar enough with Perl internals (or Java either) to 
proceed with the analysis. 

Can someone shed some light?  

Regards,
--
Charles DeRykus 


 JDK 1.2.1_03a 
 --------------
 ...
 postdump: *s++=\0 at s='=/usr/dt/lib/nls/msg/%L/%N.cat'
 Segmentation Fault
    si_signo [11]: Segmentation Fault
    si_errno [0]: Error 0
    si_code [2]: SEGV_ACCERR [addr: 0xff15aafb]

 JDK 1.3
 -------
 ...
 postdump: *s++=\0 at s='=/usr/dt/lib/nls/msg/%L/%N.cat'
 # # An unexpected exception has been detected in native code outside the VM.# Program counter=0xfae25424
 #
 # Problematic Thread: prio=5 tid=0x280a0 nid=0x1 runnable 
 #
 Abort - core dumped
 Couldn't run Sample