At 9:47 PM -0500 1/26/06, John E. Malmberg wrote: >John E. Malmberg wrote: >>I just got a reproduced crash with an instrumented vms.c. > >The access violation is occurring inside the stat() call in the CRTL. >According to the debugger, nothing is wrong with the arguments to function, >and I am referring this over to HP.
Thanks for pursuing this. There is a very recent patch that fixes some cases where Perl variables were not getting null terminated: http://public.activestate.com/cgi-bin/perlbrowse?patch=26973 Dunno if that's related or not. >In the mean time, I think that the bug you found in vmsish.h should be fixed >for completeness. I'll try to get in a patch for that one of these days. >I am also thinking of changing the code that looks up the logical name >DECC_BUG_DEVNULL to default to 1 unless the logical name is present to turn it >off. So that means doing the old behavior by default? >In order to isolate this, I had to modify Perl_vms_sig_to_condition() to call >lib$signal(SS$_DEBUG) instead of it's normal action. > >This causes the VMS debugger to be entered on any exception. > >I think it would be a useful feature to have a logical name like >PERL_EXCEPTION_DEBUG be able to enable this when needed. I like it. One could get fancy and define the logical to a signal number or condition value and trap only specific exceptions. > >I also want to convert the ino_t type copies and compares to be macros in >vmsish.t so that the references to _USE_STD_STAT can be removed from vmsish.t. As far as I can tell, st_ino is never a pointer type. The standard says that it is of "extended integral type". So it seems pretty safe to me if we just always pass it by address. On the other hand, defining macros in vmsish.h so that we do comparisons and copies consistently makes sense. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
