[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vaxaxp::vmsnotes

Title:	VAX and Alpha VMS
Notice:	This is a new VMSnotes, please read note 2.1
Moderator:	VAXAXP::BERNARDO

Created:	Wed Jan 22 1997
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	703
Total number of notes:	3722

179.0. "Crash in EXE$SETIMR+001C7" by LATINA::JMGUERRA (MCS Madrid) Wed Feb 12 1997 03:48

Hi,

I just got the following crash , and I would like to know if
somebody has had something like it.


Thanks in advance
Jose Miguel 

********************************************************************

VAX/VMS System dump analyzer

Dump taken on 11-FEB-1997 14:39:26.90
SSRVEXCEPT, Unexpected system service exception

SDA> read/exec
		.
		.
		.
SDA> SDA> read sys$system:sysdef
%SDA-I-READSYM, reading symbol table  SYS$COMMON:[SYSEXE]SYSDEF.STB;1
SDA> sh crash
System crash information
------------------------
Time of system crash: 11-FEB-1997 14:39:26.90

Version of system: VAX/VMS VERSION V6.1

System Version Major ID/Minor ID: 1/0

VAXcluster node: PROD01, a VAX 7000-730

Crash CPU ID/Primary CPU ID:  01/00

Bitmask of CPUs active/available:  00000007/00000007

CPU bugcheck codes:
        CPU 01 -- SSRVEXCEPT, Unexpected system service exception
        2 others -- CPUEXIT, Shutdown requested by another CPU

CPU 01 reason for Bugcheck: SSRVEXCEPT, Unexpected system service exception

Process currently executing on this CPU: SYMBIONT_4

Current image file: DSA0:[SYS0.SYSCOMMON.][SYSEXE]DCPS$SMB.EXE;1

Current IPL: 2  (decimal)

CPU database address:  92756000

General registers:

        R0  = 00020009   R1  = 7FFE77C4   R2  = 975EE340   R3  = 0000001F
        R4  = 986CE140   R5  = 00113AA8   R6  = 009AFBB1   R7  = 00113EF0
        R8  = D83B7740   R9  = 009AFBB1   R10 = 00108844   R11 = 0011E6A8
        AP  = 7FFE77A0   FP  = 7FFE7788   SP  = 7FFE7788   PC  = 927C0FE3
        PSL = 00020000
                       
Processor registers:

        P0BR   = A26C8400     SBR    = 1EF80400     ASTLVL = 00000004
        P0LR   = 00001642     SLR    = 003FFF00     SISR   = 00000000
        P1BR   = A2173E00     PCBB   = 4E21F620     ICCS   = 80000080
        P1LR   = 001FF800     SCBB   = 1EF67400     SID    = 17000201
        P0BR   = A26C8400     SBR    = 1EF80400     ASTLVL = 00000004
        P0LR   = 00001642     SLR    = 003FFF00     SISR   = 00000000
        P1BR   = A2173E00     PCBB   = 4E21F620     ICCS   = 80000080
        P1LR   = 001FF800     SCBB   = 1EF67400     SID    = 17000201

SDA> sh stack

Current operating stack (KERNEL):

                7FFE7768  009AFBB1
                7FFE776C  00108844
                7FFE7770  0011E6A8
                7FFE7774  7FFE77A0      CTL$GL_KSTKBAS+005A0
                7FFE7778  7FFE7788      CTL$GL_KSTKBAS+00588
                7FFE777C  7FFE7780      CTL$GL_KSTKBAS+00580
                7FFE7780  927C0FE3      EXE$EXCPTNE
                7FFE7784  00020000      SYS$K_VERSION_03

         SP =>  7FFE7788  00000000
                7FFE778C  00000000
         
       7FFE7790  7FF02474
                7FFE7794  7FFE77E4      CTL$GL_KSTKBAS+005E4
                7FFE7798  80000014      EXE$QIOW_3+00004
                7FFE779C  927C34D1      EXE$CONTSIGNAL+0007C
                7FFE77A0  00000002
                7FFE77A4  7FFE77C4      CTL$GL_KSTKBAS+005C4
                7FFE77A8  7FFE77AC      CTL$GL_KSTKBAS+005AC
                7FFE77AC  00000004
                7FFE77B0  7FFE77E4      CTL$GL_KSTKBAS+005E4
                7FFE77B4  FFFFFFFD      LKB$K_SCSWAIT
                7FFE77B8  DB3667C0
                7FFE77BC  009AFBB1
                7FFE77C0  000008F8      BUG$_SYSAPLERR
                7FFE77C4  00000005
                7FFE77C8  0000000C
                7FFE77CC  00000000
                7FFE77D0  D83B77A8
                7FFE77D4  928463AD      EXE$SETIMR+001C7
                7FFE77D8  00C20001
                7FFE77DC  92846227      EXE$SETIMR+00041
                7FFE77E0  0000003F
                7FFE77E4  00000000
                7FFE77E8  00000000
                7FFE77EC  7FF02474
                7FFE77F0  7FF02438
                7FFE77F4  927C1258      EXE$EXCEPTION+00227
                7FFE77F8  7FFEE026      P1SYSVECTORS+00226
                7FFE77FC  03C00000

SDA> ex/in EXE$SETIMR+001C7-20;20
%SDA-W-INSKIPPED, unreasonable instruction stream - 2 bytes skipped
EXE$SETIMR+001A9:  MNEGL   R0,R0
EXE$SETIMR+001AC:  SBWC    #00,R1
EXE$SETIMR+001AF:  CMPL    #000186A0,R0
EXE$SETIMR+001B6:  BLEQU   EXE$SETIMR+001BF
EXE$SETIMR+001B8:  MOVL    #000186A0,R0
EXE$SETIMR+001BF:  ADDL2   R8,R0
EXE$SETIMR+001C2:  ADWC    R9,R1
EXE$SETIMR+001C5:  BRB     EXE$SETIMR+00203
EXE$SETIMR+001C7:  CMPZV   #00,#03,6B(R8),228B(FP)

T.R	Title	User	Personal Name	Date	Lines
179.1	please try CANASTA Mail Server...	HAN::HALLE	Volker Halle MCS @HAO DTN 863-5216	`Wed Feb 12 1997 03:56`	14
	Jose Miguel, please read note SPECXN::CANASTA #204 on how to obtain the CLUE file and then - after reading note #222 on how to use the CANASTA Mail Server, send the CLUE file to CANASTA. This will analyze your crash and either tell you a solution, give you additional troubleshooting information or show you other crashes with similar footprint, which have been entered into CANASTA before. Thanks, Volker.
179.2	CANASTA, COMET, Patch Area, QAR/IPMT...	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Wed Feb 12 1997 09:21`	17
	While checking a crash, the first stop is CANASTA. Then please check the Internet patch area and the COMET support database. In this case, I have seen some print symbiont patches that are available for various releases that may be applicable. http://www.service.digital.com/html/patch_public.html http://comet.alf.dec.com/ CANASTA is an automated tool that scans for known crash footprints, and adds new footprints over time. (Use of CANASTA means we usually only have to look at a particular crashdump once, and anyone that sees the same crash can get an immediate answer -- either the crash is a known one and here is what is known, or the crash is a new one and should be elevated through formal channels. CANASTA has 25,000+ total crash footprints present in its database.)
179.3	Node unrechable	LATINA::JMGUERRA	MCS Madrid	`Thu Feb 13 1997 06:20`	15
	Re.: .1 Volker, Thanks for your answer. I'm trying to send a vaxmail to the CANASTA Mail Server, but the node is not reachable. The mail is being send to XOCOMP::CAN_SERVER Please, can you help me? Thanks again Jose Miguel
179.4	Update Your DECnet Database	XDELTA::HOFFMAN	Steve, OpenVMS Engineering	`Thu Feb 13 1997 09:33`	28
	: I'm trying to send a vaxmail to the CANASTA Mail Server, but the node : is not reachable. : The mail is being send to XOCOMP::CAN_SERVER : Please, can you help me? Update your node's DECnet database. Pending that fix, send the e-mail to 29044::CAN_SERVER. (29044 = (28 * 1024) + 372; 28.372 is XOCOMP::.) $ mc ncp NCP>tell LATINA show node xocomp Node Volatile Summary as of 13-FEB-1997 09:32:08 Node State Active Delay Circuit Next node Links 25.22 (XOCOMP) MNA-0 51.995 (SQOROU) NCP>tell anchor show node xocomp Node Volatile Summary as of 13-FEB-1997 09:32:16 Node State Active Delay Circuit Next node Links 28.372 (XOCOMP) BNA-0 55.10 (ESCNGR) NCP>
179.5	THANKS	MDR01::JMGUERRA	MCS Madrid	`Thu Feb 13 1997 09:59`	4
	Thanks for your answers Regards Jose Miguel
179.6	never seen a crash at that instruction in CANASTA	HAN::HALLE	Volker Halle MCS @HAO DTN 863-5216	`Sat Feb 15 1997 10:41`	12
	Jose Miguel, we don't have a crash in CANASTA with this footprint ;-( and no solution... It looks like R8 is clobbered, can you find out, which datastructure R8 has been loaded from ? You need someone with crashdump analysis knowledge to have a look at the dump and then decide, whether to escalate it. Volker.
179.7	MEMORY CORRUPTION !!!	HAN::HALLE	Volker Halle MCS @HAO DTN 863-5216	`Sat Feb 15 1997 10:57`	42
	Hm, the code in my V6.1 system looks different !! Could you have a look in the running system, please: ANAL/SYS SDA> READ/EXEC SDA> EXA/INS EXE$SETIMR+1C7 You seem to have something corrupting your memory... Especially the EXE$SETIMR+001C7: CMPZV #00,#03,6B(R8),228B(FP) ^^^^^^^^^^^^^^^<<< that part does not look healthy ! In that case (memory corruption through hw/sw), it's not a big surprise, that there is no crash at offset in the CANASTA case db ! Volker. SDA> exa/ins exe$setimr+1c7-30;40 EXE$SETIMR+00197: MOVL (SP)+,R0 EXE$SETIMR+0019A: MTPR (SP)+,#12 EXE$SETIMR+0019D: MOVQ R0,R0 EXE$SETIMR+001A0: BGEQ EXE$SETIMR+001C7 EXE$SETIMR+001A2: BICB2 #08,0B(R2) EXE$SETIMR+001A6: MNEGL R1,R1 EXE$SETIMR+001A9: MNEGL R0,R0 EXE$SETIMR+001AC: SBWC #00,R1 EXE$SETIMR+001AF: CMPL #000186A0,R0 EXE$SETIMR+001B6: BLEQU EXE$SETIMR+001BF EXE$SETIMR+001B8: MOVL #000186A0,R0 EXE$SETIMR+001BF: ADDL2 R8,R0 EXE$SETIMR+001C2: ADWC R9,R1 EXE$SETIMR+001C5: BRB EXE$SETIMR+00203 EXE$SETIMR+001C7: CMPZV #00,#03,0B(R2),#06 <<< should look like this !!! EXE$SETIMR+001CD: BEQL EXE$SETIMR+001F1 EXE$SETIMR+001CF: MOVQ R8,-(SP) EXE$SETIMR+001D2: ADDL2 #000186A0,(SP) EXE$SETIMR+001D9: ADWC #00,04(SP) SD