%BAS-F-IO_CHANOT problem after moving from PersonalAlpha to FreeAXP

Hi Volker

This is to confirm that I have already validated what happens when I rename the file to prevent my application from being able to open it.

The application displays an error message indicating that the open attempt had failed and then exits in an orderly fashion. This is of course how it is designed to work.

I will attempt to perform a SET PROC/DUMP analysis in the hope I can make some sense of the end result and let you know what I find when I get a chance.

Volker

Here is the result of the post crash dump analysis.

$ ANALYZE/PROCESS_DUMP MAMENU.DMP

OpenVMS Alpha Debug64 Version V8.3-009


%DEBUG-W-IMAGENF, target image MAMENU not found on host system
%BAS-F-IO_CHANOT, I/O channel not open
-BAS-I-ON_CHAFIL, on channel 51 for file È[
-BAS-I-FROGSBMOD, In GOSUB in module
-BAS-I-FROMOD, In module
break on unhandled exception preceding SHARE$LIBRTL_CODE0+466524
DBG>

This doesn't tell us anything we didn't already know
beyond adding further confirmation that the data file upon
which the FIELD operation was subsequently performed
did not open successfully. This stands in sharp contrast to the
fact that my application indicates file open success by
passing the error trap which surrounds the relevant open
statement. In addition, there exists no justification for an
open failure to occur given that the subject data file is
both present and correctly positioned for a positive outcome.

Something strange is afoot here.....

John: Private message received and responded to.

John,

please consider to look for CLUE files from those bugchecks. They should be found in CLUE$COLLECT:CLUE$node_ddmmyy_hhmm.LIS.
$ TYPE CLUE$HISTORY will also show the crash history, one line per crash. I would assume, that all those crashes show the same footprint (i.e. bugcheck name, module and offset). If so, please send me a copy of one of those CLUE files, before trying to provide the dumpfile itself (you'll find my mail address in my profile).

I do have a database of OpenVMS crash footprints and some experience of interpreting CLUE files, so I might be able to tell you, what's causing these problems or what the next step for analysis should be.

Volker.

John,

thanks for creating a process dump. This dumpfile can now be further analzyed with the debugger or SDA. It shows the static situation at the time of the program crash. And it can be easily distributed for expert analysis. Depending on the actual source code and where certain variables or status information is stored, further checks could be done. But this requires the source code and maybe even the /MACHINE_CODE listing...

You can now look at the process dump with SDA as well and look at the open channels:

$ ANAL/CRASH MAMENU.DMP
SDA> SHOW PROC/CHAN

This should show all open channels and files. Is that application file shown ? If not, then you can be sure, that the file is NOT opened !

As a next step, try $ SET WATCH FILE/CLASS=MAJOR (needs CMKRNL privilege) and then run your program. This traces XQP IOs (file system), so an OPEN statement in your program should produce some trace output. Does it ? Turn off XQP tracing with SET WATCH FILE/CLASS=NOMAJOR.

The most effective way to debug this problem is by using the debugger. Compile with /DEB/NOOPT and link with /DEBUG, then run your program. On the DBG> prompt, first just type GO and see, if the problem still exists.

Then start another debug session and set a breakpoint BEFORE the code, which is supposed to OPEN the file. Step through the code, consider to use DBG> SET BREAK/EXCEPTION, so that any exception will automatically enter the debugger and allow you to examine the context.

The most important step would be to confirm, that the file has successfully been opened. Once you've stepped past the OPEN statement, you can check with SHOW DEV/FILES or SDA, whether the file is actually open. It may be open, but the channel number may have been corrupted, causing further access to that file from your program to fail. Many things are possible and it is important to systematically find and diagnose them.

Could you also please provide some excerpt from the code, which opens the file and the code, which incurs the problem ?

Volker.

We've tracked this to what appears to be a floating point conversion or arithmetic bug in the emulator. We are working on it. Thanks to John for providing the code and data needed to track down the problem.