Discussion:
Bug in HPE OpenVMS V8.3 Alpha CRTL
(too old to reply)
RobertsonEricW
2017-05-23 16:29:53 UTC
Permalink
Raw Message
Just an FYI in case anyone else runs across this problem.

While running the CMake 3.8.1 bootstrap executable (CMake builds in two stages; bootstrap CMake.exe is the result of the first stage) it bailed out after performing about 253 (or there about) tests because it could not open channels to any more files. After some sessions through the debugger, I discovered what appears to be a bug in the OpenVMS CRTL on HPE OpenVMS Alpha V8.3. It appears that lstat() leaves behind an open channel when called with a path that is a directory specification (e.g. PRJ_ROOT:[cmake-3^.8^.1.Source]) where the device portion of the directory specification (i.e. PRJ_ROOT in the example above) is a logical name defined as concealed with a list of directory logicals which are also defined as concealed. Each call to lstat() with such a directory specification as its first argument succeeds (assuming that the underlying logical name translation values are valid) but leaves behind an open channel to the physical disk device to which the translated physical directory specification refers. I have the DEC AXPVMS VMS83A_ACRTL V10.0 patch installed. But, I am not certain if that is the latest available for HPE OpenVMS Alpha V8.3. I am also not sure if anyone at HPE or VSI is aware of this particular bug or whether or not any subsequent CRTL patch actually fixes it.

This particular bug was revealed because, in the canonical Open Source GNV build environment that John Malmberg, Bill Pedersen and myself (and perhaps others as well) use when porting Open Source projects has three different directories that are all grouped together behind one concealed logical name PRJ_ROOT. The three directory configuration is used because it makes it simpler to determine which files are artifacts of the build process and which source files require modification in order to build on OpenVMS because such files are located in separate physical directories in their corresponding relative paths within the original source tree of the Open Source project.
John Reagan
2017-05-23 18:30:42 UTC
Permalink
Raw Message
Post by RobertsonEricW
Just an FYI in case anyone else runs across this problem.
While running the CMake 3.8.1 bootstrap executable (CMake builds in two stages; bootstrap CMake.exe is the result of the first stage) it bailed out after performing about 253 (or there about) tests because it could not open channels to any more files. After some sessions through the debugger, I discovered what appears to be a bug in the OpenVMS CRTL on HPE OpenVMS Alpha V8.3. It appears that lstat() leaves behind an open channel when called with a path that is a directory specification (e.g. PRJ_ROOT:[cmake-3^.8^.1.Source]) where the device portion of the directory specification (i.e. PRJ_ROOT in the example above) is a logical name defined as concealed with a list of directory logicals which are also defined as concealed. Each call to lstat() with such a directory specification as its first argument succeeds (assuming that the underlying logical name translation values are valid) but leaves behind an open channel to the physical disk device to which the translated physical directory specification refers. I have the DEC AXPVMS VMS83A_ACRTL V10.0 patch installed. But, I am not certain if that is the latest available for HPE OpenVMS Alpha V8.3. I am also not sure if anyone at HPE or VSI is aware of this particular bug or whether or not any subsequent CRTL patch actually fixes it.
This particular bug was revealed because, in the canonical Open Source GNV build environment that John Malmberg, Bill Pedersen and myself (and perhaps others as well) use when porting Open Source projects has three different directories that are all grouped together behind one concealed logical name PRJ_ROOT. The three directory configuration is used because it makes it simpler to determine which files are artifacts of the build process and which source files require modification in order to build on OpenVMS because such files are located in separate physical directories in their corresponding relative paths within the original source tree of the Open Source project.
News to me.

I don't see any changes that look related. The code for stat/lstat is pretty twisted since it has support for STD_STAT as well as older DECC_V4_SOURCE and DECC_V6_SOURCE.

Looking at the internal routine that does the actual work, I see the actual open and close of the link file (that looks fine at a quick glance). There is also a call to decc$findfile which is jammed full of calls to SYS$SEARCH, SYS$PARSE, etc. There is also one call to $ASSIGN to get some device info for the stat block but I think it will always go into the call to $DEASSGN.

Probably need to come up with the reproducer and step through the RTL code.
RobertsonEricW
2017-05-23 21:15:46 UTC
Permalink
Raw Message
Post by John Reagan
Post by RobertsonEricW
Just an FYI in case anyone else runs across this problem.
While running the CMake 3.8.1 bootstrap executable (CMake builds in two stages; bootstrap CMake.exe is the result of the first stage) it bailed out after performing about 253 (or there about) tests because it could not open channels to any more files. After some sessions through the debugger, I discovered what appears to be a bug in the OpenVMS CRTL on HPE OpenVMS Alpha V8.3. It appears that lstat() leaves behind an open channel when called with a path that is a directory specification (e.g. PRJ_ROOT:[cmake-3^.8^.1.Source]) where the device portion of the directory specification (i.e. PRJ_ROOT in the example above) is a logical name defined as concealed with a list of directory logicals which are also defined as concealed. Each call to lstat() with such a directory specification as its first argument succeeds (assuming that the underlying logical name translation values are valid) but leaves behind an open channel to the physical disk device to which the translated physical directory specification refers. I have the DEC AXPVMS VMS83A_ACRTL V10.0 patch installed. But, I am not certain if that is the latest available for HPE OpenVMS Alpha V8.3. I am also not sure if anyone at HPE or VSI is aware of this particular bug or whether or not any subsequent CRTL patch actually fixes it.
This particular bug was revealed because, in the canonical Open Source GNV build environment that John Malmberg, Bill Pedersen and myself (and perhaps others as well) use when porting Open Source projects has three different directories that are all grouped together behind one concealed logical name PRJ_ROOT. The three directory configuration is used because it makes it simpler to determine which files are artifacts of the build process and which source files require modification in order to build on OpenVMS because such files are located in separate physical directories in their corresponding relative paths within the original source tree of the Open Source project.
News to me.
I don't see any changes that look related. The code for stat/lstat is pretty twisted since it has support for STD_STAT as well as older DECC_V4_SOURCE and DECC_V6_SOURCE.
Looking at the internal routine that does the actual work, I see the actual open and close of the link file (that looks fine at a quick glance). There is also a call to decc$findfile which is jammed full of calls to SYS$SEARCH, SYS$PARSE, etc. There is also one call to $ASSIGN to get some device info for the stat block but I think it will always go into the call to $DEASSGN.
Probably need to come up with the reproducer and step through the RTL code.
Interestingly the stat() CRTL function does NOT exhibit this bug; only lstat(). I'll put together a simple reproducer, send it your way and let you or anyone else available at VSI look it over whenever a "free" moment comes along.
Stephen Hoffman
2017-05-24 16:39:48 UTC
Permalink
Raw Message
Post by John Reagan
Probably need to come up with the reproducer and step through the RTL code.
Not now, but maybe soon... http://embed.cs.utah.edu/creduce/
--
Pure Personal Opinion | HoffmanLabs LLC
RobertsonEricW
2017-05-24 19:29:22 UTC
Permalink
Raw Message
Post by Stephen Hoffman
Post by John Reagan
Probably need to come up with the reproducer and step through the RTL code.
Not now, but maybe soon... http://embed.cs.utah.edu/creduce/
--
Pure Personal Opinion | HoffmanLabs LLC
In this particular case, this tool would not have been able to help because the bug is not solely dependent on the function call and its arguments or application program input or state under the control of the software producer. It instead depends on an environmental factor (logical name environment in this case which is completely independent of the application and its state or previous input) at the time the CRTL call is made. Such is not analyzable based on application program input or state.
Loading...