Craig A. Berry wrote:
At 11:03 PM -0500 1/22/06, John E. Malmberg wrote:
John E. Malmberg wrote:
Craig A. Berry wrote:
At 8:15 PM -0500 1/21/06, John E. Malmberg wrote:
$ perl harness [.op]stat.t
[.op]stat....dubious
Test returned status 12 (wstat 1024, 0x400)
(VMS status is 12)
FAILED--1 test script could be run, alas--no output ever seen
%SYSTEM-F-ACCVIO, access violation, reason mask=00,
So far, this seems to be based on several phase of the moon issues.
I have placed comments in a copy [.op]stat.t1 to get it down to
the minimum code that will reproduce an access violation with every
>> run.
When I extract this code into a separate module, the access
violation does not occur.
I can also not reproduce the access violation when running it in
the debugger.
This usually means an uninitialized variable, as the debugger tends
to clear stack as it runs.
By adding in print STDERR statements to the [.op]stat.t1, I was
able to isolate where the failure is happening.
The access violation is occurring on the line below when $Null =
'_NLA0:', but not when it is '/dev/null'.
-e $Null;
It does not occur when $Null is replaced by either of the above
text constants.
It looks like the next step is to put some fprintf and fputs calls
to write output to stderr for the routines that should be processing
>> the above statement to see if the exact location of the access violation
>> can be found. Maybe once I start looking at that code it may become
>> obvious.
If I define DECC_BUG_DEVNULL in the environment, I can run several
times in a row with no accvios. Do you have that defined in your
normal test environment? That would explain why you weren't seeing
the failure in your test runs.
No, I do not have that logical name defined. That logical name is only
needed with the RMS Symbolic Link SDK, which requires that a real
/dev/null be present on under the "/". The tool to create the real
"/dev/null" did not appear until after this issue was found. I left the
logical in place just in case there were still versions of the CRTL
in use that were not automatically handling "/dev/null" correctly.
I think this is something you added and I don't fully understand what
it does. It looks like the default behavior is now to skip our old
code that concocted its own stat values for the null device, but
defining DECC_BUG_DEVNULL reverts to the old behavior. So stepping
through Perl_flex_stat_int while processing the null device with the
logical turned off might lead to further clues about what's not
getting initialized.
In my test code that is reproducing the issue 100% of the time, I have
found that changing any one of the remaining uncommented Perl statements
can make the problem go away 100% of the time.
This is telling me that stale data is probably an issue.
The puzzling thing is that the statement "-e $Null" will only cause an
access violation for $Null = '_NLA0:'. Replacing it with "-e '_NLA0:'
eliminates the access violation.
Now the one place where that code should be taking a different path
under those two conditions that I can find is in doio.c.
At the time that flex_stat() gets a hold of the code, there should be no
difference in the two cases.
This could be mis-leading though.
With the DECC_BUG_DEVNULL enabled, the string containing '_NLA0' is
never checked to see if it has a trailing NULL character. So if the
buffer is malformed for that value, it would not cause a problem.
Obviously a bug is present, but I still do not have enough information
to isolate it further until I can build a custom Perl that emits output
to stderr as it executes through the path taken by "-e $Null", which
will not be until at least tomorrow evening.
-John
[EMAIL PROTECTED]
Personal Opinion Only
