|
|
|
|
|
|
| Author |
Message |
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
 Posted: Sun Jan 22, 2006 1:57 am Post subject:
Re: Blead 26919 on OpenVMS - All tests successful.
|
|
|
At 8:15 PM -0500 1/21/06, John E. Malmberg wrote:
| Quote: | All tests successful.
u=141.39 s=0.00 cu=0.00 cs=0.00 scripts=1084 tests=157283
|
Not for me. With HP C V7.1-015 on OpenVMS Alpha V8.2, I still get:
t/op/stat..................................................FAILED--no leader found
Running it a number of times, it fails on odd runs and succeeds on even:
$ perl harness [.op]stat.t
[.op]stat....ok
All tests successful.
Files=1, Tests=86, 9 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
$ 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, virtual address=000000000000000C, PC=0000000000000012, PS=00000003
It turns out that the difference is whether the temporary file
Op_stat.tmp is present or not. A failed run leaves four versions of
it sitting there. The next run succeeds but cleans them all up.
Then the next run fails again. It gets pretty far in the test
because it creates the four temp files successfully, but it returns
no output. The accvio only happens when the test is run as a piped
subprocess. It does not happen when the subprocess runs Perl under
the VMS debugger. I do not see the failure with Compaq C V6.4-005 on
OpenVMS Alpha V7.2-1. I do not see the failure with maintperl.
Suspects include recent changes to the stat structure and to exit
handling and to memory allocation and deallocation of the structures
used by pipes.
John, are you running on an unreleased version of VMS or of the CRTL?
What version of the compiler are you using? There's not much
difference between v7.1 and v6.5 on Alpha, is there?
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
 |
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Sun Jan 22, 2006 9:01 pm Post subject:
Re: Blead 26919 on OpenVMS - All tests successful.
|
|
|
Craig A. Berry wrote:
| Quote: | 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,
virtual address=000000000000000C, PC=0000000000000012, PS=00000003
It turns out that the difference is whether the temporary file
Op_stat.tmp is present or not. A failed run leaves four versions of
it sitting there. The next run succeeds but cleans them all up.
Then the next run fails again. It gets pretty far in the test
because it creates the four temp files successfully, but it returns
no output. The accvio only happens when the test is run as a piped
subprocess. It does not happen when the subprocess runs Perl under
the VMS debugger. I do not see the failure with Compaq C V6.4-005 on
OpenVMS Alpha V7.2-1. I do not see the failure with maintperl.
Suspects include recent changes to the stat structure and to exit
handling and to memory allocation and deallocation of the structures
used by pipes.
John, are you running on an unreleased version of VMS or of the CRTL?
What version of the compiler are you using? There's not much
difference between v7.1 and v6.5 on Alpha, is there?
|
On this system, I am running OpenVMS 8.2 Alpha, no ECOs at the present
time. I am still running the Compaq C 6.5 compiler.
I am not running a threaded Perl at the moment either.
EAGLE> 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, virtual
address=000000000000000C, PC=0000000000000012, PS=00000003
Since I can reproduce this, I should be able to find out what the
problem is.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Mon Jan 23, 2006 4:03 am Post subject:
Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
John E. Malmberg wrote:
| Quote: | 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.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Mon Jan 23, 2006 5:04 am Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
At 11:03 PM -0500 1/22/06, John E. Malmberg wrote:
| Quote: | 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.
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.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Mon Jan 23, 2006 3:17 pm Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
Craig A. Berry wrote:
| Quote: | 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.
| Quote: | 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
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Mon Jan 23, 2006 9:26 pm Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
On Monday, January 23, 2006, at 09:18AM, John E. Malmberg <wb8tyw@qsl.net> wrote:
| Quote: | 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.
|
Remember Perl is a dynamic language. If $Null is never assigned to, the Perl compiler may optimize it away. A very slightly different memory allocation signature could make a difference in whether we trigger the bug. You can watch memory allocation and deallocation happen by running with -"Dm" :
$ perl -"Dm" [.op]stat.t |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Mon Jan 23, 2006 10:01 pm Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
Craig Berry wrote:
| Quote: |
On Monday, January 23, 2006, at 09:18AM, John E. Malmberg <wb8tyw@qsl.net> wrote:
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.
Remember Perl is a dynamic language. If $Null is never assigned to,
the Perl compiler may optimize it away. A very slightly different memory
allocation signature could make a difference in whether we trigger the
bug. You can watch memory allocation and deallocation happen by running
with -"Dm" :
$ perl -"Dm" [.op]stat.t
|
$Null is definitely assigned to, I have a debugging statement that
prints out it's value.
I can add statements for "-e '_NLA0:' to the test script before the
access violation occurs and they execute with out affecting the access
violation for "-e $Null".
It is curious, as for a reproducer, I ended up with code that
opens/create the temporary file, and then closes it.
Then it opens it and leaves it open.
| Quote: | 1 while unlink $tmpfile;
open(FOO, ">$tmpfile") || DIE("Can't open temp test file: $!");
close FOO;
open(FOO, ">$tmpfile") || DIE("Can't open temp test file: $!");
|
It does not seem to make a difference if $Null is set from the
File::Spec->devnull; or from $Null = '_NLA0:'.
$Null = '/dev/null' does not cause an access violation either.
After that the "-e $Null" statement causes a access violation.
In the test file, if I close that temporary file, no access violation,
but in the real stat.t the temporary file should be closed at this
point, and I do not see a way around it in the Perl script, so I do not
know why that makes a difference.
If I do not open and close the file once before opening it and leaving
it open, I do not get the access violation.
If I extract what is left of uncommented of the script out into a new
script, I do not get the access violation.
I think this one is going to be a bit painful to find as it does not
show up in the VMS debugger.
Some of the other -"D" flags may help isolate what routines that Perl
was in just before the access violation as a first pass in zeroing in on it.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Mon Jan 23, 2006 10:18 pm Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
Another thing to check. This code in Perl_flex_stat looks worrisome to me:
#ifdef _USE_STD_STAT
memcpy(&statbufp->st_ino, &statbufp->crtl_stat.st_ino,  ;
#else
memcpy(&statbufp->st_ino, statbufp->crtl_stat.st_ino, ;
#endif
It seems to me that when _USE_STD_STAT is not in effect, we should only be copying 6 bytes, not 8. That and/or the fact that my_ino_t in vmsish.h is only declared to be 32 bits instead of 48, which we appear to expect in some places. I could well be missing something and won't be near my debugging tools until late tonight. |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Tue Jan 24, 2006 5:19 pm Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
Hello Craig,
It appears that there is something wrong with nntp.perl.org so until
this evening I have limited access to e-mails.
| Quote: | I've attached a patch which I'm still testing that addresses this and
a couple of other stat-related nits. After applying it, I don't get
the accvio when running the stat.t test any more. I'm not entirely
convinced we've found the bug, as copying 8 bytes when we only needed
6 should have just put the first 2 bytes of the st_mode field into
the high word of our rvn field where it would never be seen. We
probably need a more thorough review of alignment settings and such.
|
Depending on the build options, the size of struct stat varies greatly.
I have found about 14 different variants. Most of the struct stat
variants have either a 64 bit ino_t field or are padding it with a 16
bit filler field.
With the _USE_STD_STAT, the ino_t value is scaler and must be passed by
address with the & prefix. With out it, the ino_t value is an array and
does not need the & prefix. While the & prefix is superfluous on an
array, if someone does the same thing with a pointer, it greatly changes
the meaning.
That is why I had the two separate syntaxes.
-#ifdef _USE_STD_STAT
- memcpy(&statbufp->st_ino, &statbufp->crtl_stat.st_ino, ;
-#else
- memcpy(&statbufp->st_ino, statbufp->crtl_stat.st_ino, ;
-#endif
This could be wrapped in a macro for COPY_INO_T(x,y) and CMP_INO_T(x,y)
to make the code more readable, where memcpy and memcmp are only used
when the st_ino is an array type.
Such a macro could be put in vmsish.h to remove the tests for
_USE_STD_STAT from vms.c.
In any case, the memcpy should not be the cause of the access violation
unless the ranges were overlapping.
Obviously the st_fab_mrs member is not being referenced or the compiler
would have caught my typo.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Wed Jan 25, 2006 3:22 am Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
Craig A. Berry wrote:
| Quote: |
I've attached a patch which I'm still testing that addresses this and
a couple of other stat-related nits. After applying it, I don't get
the accvio when running the stat.t test any more. I'm not entirely
convinced we've found the bug, as copying 8 bytes when we only needed
6 should have just put the first 2 bytes of the st_mode field into
the high word of our rvn field where it would never be seen. We
probably need a more thorough review of alignment settings and such.
|
I added some fputs("text...", stderr) statements to an unmodified
Flex_stat_int and it made the access violations go away.
This is curious. I am trying again with less fputs() statements to see
if that makes a difference.
I also am going to try to get a process dump on the access violation.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Wed Jan 25, 2006 4:29 am Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
I just got a reproduced crash with an instrumented vms.c.
Here is the code fragment:
my $Null = '_NLA0:';
print STDERR "# stat.t1 step 7 - Null = $Null\n\n";
#SKIP: {
# skip "No null device to test with", 1 unless -e $Null;
my $isnull1 = -e '/dev/null';
print STDERR "# stat.t1 step 8.1\n\n";
my $isnull1 = -e '_NLA0:';
print STDERR "# stat.t1 step 8.2\n\n";
-e $Null;
print STDERR "# stat.t1 step 8.3\n\n";
my $isnull = -e $Null;
print STDERR "# stat.t1 step 8.4\n\n";
Here is the output:
# stat.t1 step 7 - Null = _NLA0:
Entering Perl_flex_stat_int
Exiting Perl_flex_stat_int
# stat.t1 step 8.1
Entering Perl_flex_stat_int
Exiting Perl_flex_stat_int
# stat.t1 step 8.2
Entering Perl_flex_stat_int
Entering Perl_flex_stat_int
Exiting Perl_flex_stat_int
Entering Perl_flex_stat_int
Exiting Perl_flex_stat_int
dubious
Test returned status 12 (wstat 1024, 0x400)
FAILED--1 test script could be run, alas--no output ever seen
%SYSTEM-F-ACCVIO, access violation, reason mask=00,
virtual address=000000000000000C, PC=0000000000000012, PS=00000003
The entering and exiting were output by the fputs() statement that I added.
What is curious is that Perl_flex_stat_int was called 3 times when the
file specification was passed in a variable, yet only once when the file
specification was passed as a string constant.
Even more interesting is that Perl_flex_stat appears to be called
recursively in this case, as it is entered twice before it is exited once.
I am no longer getting an access violation on every run with this test
script. When there is no access violation, Perl_flex_stat_int is only
called once for that step.
I can find no cases where Perl_flex_stat_int could recursively call it
self either directly or indirectly.
So this looks like a case where the stack has become corrupt so that it
is returning to the wrong place.
But why is it only doing this for a variable and not a constant?
And why is it only doing this some of the time?
This is all I have time for tonight.
I think I might put in a test to see if ((strncmp(fspec,"_NLA0:",6) ==
0) && (fspec[6] != 0)) ever shows up.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Fri Jan 27, 2006 2:47 am Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
John E. Malmberg wrote:
| Quote: | 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.
We can use the logical name to keep the NLA0: device from having a
stat() done on it.
In the mean time, I think that the bug you found in vmsish.h should be
fixed for completeness.
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.
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 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.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Craig A. Berry
*nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
| Posted: Sun Jan 29, 2006 3:59 am Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
At 9:47 PM -0500 1/26/06, John E. Malmberg wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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?
| Quote: | 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.
| Quote: |
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:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
|
John E. Malmberg
*nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
| Posted: Sun Jan 29, 2006 11:11 pm Post subject:
Re: Blead 26919 on OpenVMS - op/stat.t failures
|
|
|
Craig A. Berry wrote:
| Quote: | At 9:47 PM -0500 1/26/06, John E. Malmberg wrote:
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?
|
Yes, until we can verify that the problem is fixed and which versions/
ECOs are needed. The old behavior is probably desired for any major
version of VMS that would need an ECO as CRTL ECO's may not be present.
| Quote: | 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.
|
That turns out not the place to put the LIB$SIGNAL trap as that routine
is also called by kill()
| Quote: | 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.
|
I am making a test run now with the /DEV/NULL and st_ino macro changes
to see how it works.
The LIB$SIGNAL hack should be in it's own patch, and it may need to be
in the Perl_csighandlerp procedure.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
|
Mark Berryman
*nix forums addict
Joined: 04 Aug 2005
Posts: 50
|
| Posted: Tue Jan 31, 2006 10:32 pm Post subject:
Re: patch@26996 - patch around stat("_NLA0:") bug
|
|
|
Craig A. Berry wrote:
| Quote: | At 11:21 PM -0500 1/30/06, John E. Malmberg wrote:
In vmsish.h:
* Fix a typo for vms specific st_fab_mrs macro that was not noticed
because currently nothing uses it.
* Create macros VMS_INO_T_COMPARE and VMS_INO_T_COPY to hide difference
from traditional VMS specific ino_t array type and standard 64 bit ino_t
type.
In vms.c:
1. Set default to have /dev/null work around active until it can be
verified that the problem is fixed. The logical name DECC_BUG_DEVNULL
can be used to deactivate the work around.
2. Convert all ino_t compares or assignments to use the macros in vmsish.h.
3. Fix the test for /dev/null to only check the first 9 characters.
Thanks, applied as #27015.
|
I am curious. Why would you not want to simply define _USE_STD_STAT?
Is it because this feature is not available on the VAX? How old of a
VMS version does this version of Perl need to compile on?
Mark Berryman |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Tue Dec 02, 2008 6:35 am | All times are GMT
|
|
Loans | Per Insurance | Fast Loans | Business Sales | Buy PSP
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Not Unix
»
VMS
»
vmsperl
