At 11:42 AM -0500 12/5/03, Tom Edelson wrote: >(Still back at Perl 5.6.1, and VMS V7.2-2), I can get an access violation from Perl >by giving the "glob" function a really long argument, which also would return a lot >of files. For example, rename a copy of Perl to a very deep directory location (I >did it on an ODS-5 volume) and do the equivalent of a glob on PERL_ROOT:[LIB]: > >$ set ver >$ @ temp >$ PERL -e "PRINT (glob
You want print, not PRINT, but I don't think that's related to the accvio. >'$1$DUA1400:[RE_TOEDEL.VERY_VERY_LONG_DIRECTORY_NAME.MAN_IS_THIS_EVER_A_LONG_DIR_NAME.HOW_COULD_ANYONE_GIVE_A >_DIRECTORY_SUCH_A_LONG_NAME.2003-11-25.INSTALL.PGM.PERL.LIB]*.*') ? 'yes' : 'no';" >%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000636C7FFF, >PC=0000000000145664, PS=0000001B I tried a quick reproducer with mixed results. I usually get a silent failure, though sometimes it actually works. One time it started gobbling memory until it filled up the page file :-(. If it's completely reproducible on your system, it might be best to debug it there. One thing to keep in mind is that we definitely don't handle resultant path specs longer than NAM$C_MAXRSS (i.e., 255). We should die informatively, though, rather than allow a stack corruption, which I suspect is what is happening. I'm a bit short on debugging time, but if you step through Perl_start_glob in doio.c, you may be able to spot what's happening. We are dependent on lib$find_file detecting a string that's too short and returning an error. If it silently truncates, then we'll go into an endless loop searching for a semicolon in the result spec. This assumes that exceeding 255 characters in the glob result is the source of the problem, which I am not 100% sure of but it seems the likeliest. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
