[Info-vax] Home-grown application process dumps

[David Froble]

VAXman- @SendSpamHere.ORG wrote:
> In article <bb40ccb6-4921-4aee-8285-134894086ac0 at googlegroups.com>, RGB <11brvo at gmail.com> writes:
>> Hi all and happy new year.
>>
>> We are currently running a home-grown application, which uses its own "data=
>> base" on an Itanium rx2800 i2 cluster of 2 nodes running VMS v8.4.  All ECO=
>> 's are up to date on the cluster.  This home-grown application has various =
>> modules which do specific tasks.  Two of the modules have been crashing/dum=
>> ping as of late and the developers, who wrote the code, claim it's a bug in=
>> VMS whereas I believe that the cause of the process dumps are coding issue=
>> s.  I'm going to output a couple of the process dumps here with the hope th=
>> at someone could give me their opinion on what might be causing these proce=
>> sses to dump like this.  That's my hope anyway!
> 
> Try posting PLAIN TEXT next time.
> 
> 
> All three dumps have the same error:
> 
> 
>> %BAS-F-MEMMANVIO, Memory management violation
>> -BAS-I-USEPC_PSL, at user PC=3D84236620, PSL=3D0000001B
>> -SYSTEM-F-ACCVIO, access violation, reason mask=3D04, virtual address=3D000=
>> 00000002D
>> 0002, PC=3DFFFFFFFF84236620, PS=3D0000001B
> 
>> %BAS-F-MEMMANVIO, Memory management violation
>> -BAS-I-USEPC_PSL, at user PC=3D84236620, PSL=3D0000001B
>> -SYSTEM-F-ACCVIO, access violation, reason mask=3D04, virtual address=3D000=
>> 00000002D
>> 0002, PC=3DFFFFFFFF84236620, PS=3D0000001B
> 
>> %BAS-F-MEMMANVIO, Memory management violation
>> -BAS-I-USEPC_PSL, at user PC=3D84236620, PSL=3D0000001B
>> -SYSTEM-F-ACCVIO, access violation, reason mask=3D04, virtual address=3D000=
>> 00000002D
>> 0002, PC=3DFFFFFFFF84236620, PS=3D0000001B
> 
> I'd suspect a coding error in the BASIC program; however, it might be a bug
> in DEC$BASRTL.
> 
> Build the program with /LIST/MACHINE and LINK it with /MAP/FULL.  That will
> help to make sense of the various addresses see in the dump.  Find out what
> was being invoked that coughed up the "%BAS-F-MEMMANVIO, Memory management 
> violation" and trace the stack back from it to your program code.  SDA can
> be your friend here to figure out what was invoked in DEC$BASRTL or what it
> might have invoked in other RTLs and system routines.
> 

Got to agree with Brian.  I don't see it in what you provided, but the 
line number in the listing of the source code of the Basic statement, 
or, the Basic statement that invoked the lower level code, the RTL or 
SS, whatever, will be in the error messages.  Find that line number in 
the listing to see what was happening when the fault occurred.

For example:

run z2
Z2     6-JAN-2015 01:16

Diagnostic on source line 1, listing line 1, BASIC line 10
         source file: SYS$SYSDEVICE:[DFE]Z2.BAS;1

         10      Z = 1 / 0.
......................1

%BASIC-W-DIVBY_ZER, division by zero

%BAS-F-DIVBY_ZER, Division by 0
-BAS-I-USEPC_PSL, at user PC=0017D7E3, PSL=03C000A0
-SYSTEM-F-FLTDIV_F, arithmetic fault, floating divide by zero at 
PC=0017D7E3, PS
L=03C000A0
-BAS-I-FROLINMOD, from line 10 in module Z2
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ready

list
Z2     6-JAN-2015 01:16

10      Z = 1 / 0.
99      End

Ready

Note, the above does not involve a listing file, but I believe the 
result is the same.