CRASH ANALYSIS of VAX/VMS server

[Sk Noorul Hassan]

Volker, Pls find the SDA output as asked by u. This is in continuation of my last thread.

[Volker Halle · Accepted solution]

See previous thread:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=997282

SDA> exa/ins 195FEB-10;20
00195FDB: MOVL 08(AP),R1
00195FDF: MOVL 0C(R1),R0
00195FE3: MOVL 10(R1),R1
00195FE7: BUGW #0164 <<< that's the culprit
00195FEB: XFC <<< PC in crash points here

That's it: this code has the FATAL bit set when declaring a HALT bugcheck (BUG$_HALT =0x160), so it crashes the whole system. The other routines nearby just had BUGW #0160, which caused a non-fatal HALT bugcheck errlog entry and just aborted the running image.

This is an APPLICATION FORCED CRASH. You need to contact your application support for this application and find out, why this code thinks it has to crash the whole system.

I've also shown in the previous thread, that there is a parameter passing problem to SYS$PUTMSG, which may trigger this bug.

If you need help with your application programming, please contact me offline (see my e-mail address in my ITRC profile).

Volker.

[Sk Noorul Hassan]

Many thanks Volker,

Sure, I will get back to u

[Sk Noorul Hassan]

Volker, Can you just explain it once in more details...

"The stack limits show, that the failing address in question is outside any of the user, supervisor, executive or kernel stacks.

But the MSGVEC argument to the SYS$PUTMSG call looks VERY suspicious:

The call frame to SYS$PUTMSG from your code (return address = 005E8ED3) presents ONE argument to SYS$PUTMSG - the argument list is on the stack:

Argument List: 7FF75210 00000001
______________ 7FF75214 7FF75218

The first argument to SYS$PUTMSG is the message vector MSGVEC passed by reference. So the MSGVEC starts at 7FF75218 and looks like this:

7FF75218: 7FF7562D <<< def msg options & arg count !
7FF7521C: 0001827A <<< message code = %RMS-E-EOF
7FF75220: 00000000 <<< STV value
7FF75224: 00000000
...

The argument count field, the low 16 bits of the first longword in the message vector is DEFINITELY WRONG ! It should have been 0001 ! EXE$PUTMSG 'walks' the argument vector based on the argument count. It may well walk into in-accessible address space based on that incorrect value of 562D.

Please use SDA> SHOW PROC/IMAGE to find out, which code is at address 005E8ED3, find the map and listings and the programmer (!) and check the construction of the MSGVEC for this call to SYS$PUTMSG."

[Volker Halle]

We know why the system finally crashed: The application code at 00195FE7: BUGW #0164 issued a fatal HALT bugcheck.

When looking at the traceback data, it could be seen, that a call frame contained an address in system S0 space:

EXE$PUTMSG+23: CMPZV #10,#0C,(R9),#01

This instruction failed accessing the data pointed to by R9 = 7FF89D70 (as can be seen in the application error message %MCLIBPRV-I-FATAL ...)

This is the code processing the SYS$PUTMSG call from your application code (return address is 005E8ED3).

This call to EXE$PUTMSG passed 1 argument on the stack, the address of the MSGVEC (message vector):

Argument List 7FF75210 00000001
_____________ 7FF75214 7FF75218

The message vector starts like this:

7FF75218: 7FF7562D <<< def msg options & arg count !
7FF7521C: 0001827A <<< message code = %RMS-E-EOF
7FF75220: 00000000 <<< STV value
7FF75224: 00000000

According to the system services reference manual (SYS$PUTMSG), the MSGVEC has to start with a longword of:



In case of this crash, the first longword of the message vector looks like this:

7FF7562D

If the low order word is interpreted as an argument count, this may cause a problem !

You need access to your application code (the machine code listing !) and further debug this.

SDA> SHOW PROC/IMAGE will tell you, which code (shareable library) is loaded at address 005E8ED3

You will need a LINK MAP and machine code listing of that code to further debug this problem.

All further debugging requires in-depth understanding of the OpenVMS VAX calling standard and architecture. Without access to the source code and the ability to identify the failing code, recompile and relink, you cannot solve this problem, you would have to live with it.

If this is not your own code, contact the service organization, which provides service for that code.

As I've expressed earlier, I'm willing to help, but debugging and fixing application source code is probably beyond the scope of this forum.

Please send mail, if you would like further support in this matter.

Volker.