[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Alpha Developer Support |
| Notice: | [email protected], 800-332-4786 |
| Moderator: | HYDRA::SYSTEM |
|
| Created: | Mon Jun 06 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3722 |
| Total number of notes: | 11359 |
3123.0. "Paston Chase Ltd - Point 18755" by KZIN::ASAP () Mon Feb 03 1997 06:36
Company Name : Paston Chase Ltd - Point 18755
Contact Name :
Phone : 44 1603502061
Fax : 44 1603502072
Email : [email protected]
Date/Time in : 3-FEB-1997 11:36:10
Entered by : Nick Hudson
SPE center : REO
Category : vms
OS Version : 6.2
System H/W :
Brief Description of Problem:
-----------------------------
From: ESSB::ESSB::MRGATE::"ILO::ESSC::bsanting" 3-FEB-1997 10:38:18.06
To: RDGENG::ASAP
CC:
Subj: 18755 Paston Chase Ltd
From: NAME: ESCTECH@ILO
TEL: (822-)6704
ADDR: ILO <bsanting@ESSC@ILO>
To: ASAP@RDGENG@MRGATE
Hello -
POINT Log Number 18755
ASAP No: A60265
Paston Chase Ltd
Phone 44 1603502061
FAX 44 1603502072
EMAIL: [email protected]
Problem Statement
Alpha AXP, OpenVMS 6.2, and the 'C' compiler.
The following section of code is within a routine that executes in kernel mode.
{
..
PCB *server_pcb;
MUTEX *io_database_mutex;
..
server_pcb = CTL$GL_PCB;
io_database_mutex = SCH_STD$IOLOCKW(server_pcb);
..
}
I'm certain that its the SCH_STD$IOLOCKW that is causing a crash.
The program produces a log file which I've copied verbatim below in case there
is anything useful there, ie the process PCB (which is found earlier in the
program also using CTL$G_PCB) :-
Sat Feb 1 15:54:39, IRIS Server Initialized, Version 4.0-0
Sat Feb 1 15:54:40, Server_init, pages locked 00002000 to 00005FFF
Sat Feb 1 15:54:40, Server_init, Server process PCB = 80D76140
Sat Feb 1 15:54:40, Server_init, Common code address 80E00440
Sat Feb 1 15:54:40, Server_init, notify_creator
Sat Feb 1 15:54:40, Server_init, Server process PCB = 80D76140
Sat Feb 1 15:54:40, Server_init, Completed
Sat Feb 1 15:54:46, Record, Common file processing
Sat Feb 1 15:54:46, Record, DVH 00076000, DVR 00076078
Anal/system clue results show:
Crashdump Summary Information:
------------------------------
Crash Time: 1-FEB-1997 15:54:46.75
Bugcheck Type: INVEXCEPTN, Exception while above ASTDEL
Node: GREEN (Standalone)
CPU Type: DEC 3000 Model 300
VMS Version: V6.2
Current Process: IRIS Server
Current Image: GREEN$DKA100:[SYS0.SYSCOMMON.][SYSEXE]IRIS_SERVER.EXE;6
Failing PC: FFFFFFFF 8001D388
Failing PS: 00000000 00000803
Module: SYSTEM_PRIMITIVES_MIN
Offset: 00009388
Boot Time: 1-FEB-1997 14:00:28.00
System Uptime: 0 01:54:18.75
Crash/Primary CPU: 00/00
Pagesize: 8 KByte (8192 bytes)
Physical Memory: 32 MByte (4096 PFNs)
Dumpfile Pagelets: 65536 blocks
Dump Flags: olddump,writecomp,errlogcomp
Crashdump Summary Information:
------------------------------
EXE$GL_FLAGS: poolpging,init,bugdump
Stack Pointers:
KSP = 00000000 7FF91C28 ESP = 00000000 7FF96000 SSP = 00000000 7FF9E000
USP = 00000000 7EF739C0
General Registers:
R0 = 40000000 00000000 R1 = 00000000 00000000 R2 = FFFFFFFF FFFFFFFD
R3 = FFFFFFFF 80C32840 R4 = 00000000 7FF91C80 R5 = 00000000 7FF91DE8
R6 = 00000000 7FF91E40 R7 = 00000000 00000803 R8 = 00000000 00000000
R9 = FFFFFFFF 821B32C8 R10 = 00000000 7FFBF800 R11 = 00000000 7FF781A2
R12 = 00000000 00000000 R13 = FFFFFFFF 80C25570 R14 = 00000000 00000000
R15 = 00000000 009AF3E0 R16 = 00000000 000001CC R17 = 00000000 7FF91C80
R18 = 00000000 7FF91E40 R19 = 47FF041F 47FF041F R20 = 00000000 00000004
R21 = 80D6012C 00000000 R22 = FFFFFFFF 80C04AB0 R23 = 00000000 00016000
R24 = FFFFFFFF 80D60000 AI = 00000000 00000001 RA = FFFFFFFF 8001CE94
PV = FFFFFFFF 80C25570 R28 = 00000000 00008010 FP = 00000000 7FF91EB0
PC = FFFFFFFF 80044CBC PS = 28000000 00000800
Exception Frame:
R2 = 00000000 00006020 R3 = 00000000 00076000 R4 = 00000000 00000000
R5 = 00000000 00000090 R6 = 00000000 0001E510 R7 = 00000000 7FF91FC0
PC = FFFFFFFF 8001D388 PS = 00000000 00000803
Signal Array:
Arg Count = 00000005
Condition = 0000000C
Argument #2 = 00000000
Argument #3 = 00000008
Argument #4 = 8001D388
Argument #5 = 00000803
Mechanism Array:
Arguments = 0000002B Establisher FP = 00000000 7FF91EB0
Flags = 00000000 Exception FP = 00000000 7FF91E40
Depth = FFFFFFFD Signal Array = 00000000 7FF91DE8
R0 = FFFFFFFF 80C04AB0 R1 = 00000000 00008010 R16 = 00000000 00000001
R17 = 0000FE00 00007400 R18 = 00000000 00016084 R19 = 47FF041F 47FF041F
R20 = 00000000 00000004 R21 = 80D6012C 00000000 R22 = FFFFFFFF 80C04AB0
R23 = 00000000 00016000 R24 = FFFFFFFF 80D60000 R25 = 00000000 00000001
R26 = FFFFFFFF 8001CE94 R27 = FFFFFFFF 80C25570 R28 = 00000000 00008010
System Registers:
Page Table Base Register (PTBR) 00000000 00000E70
Processor Base Register (PRBR) FFFFFFFF 80D2A000
Privileged Context Block Base (PCBB) 00000000 00758080
System Control Block Base (SCBB) 00000000 000001A9
Software Interrupt Summary Register (SISR) 00000000 00000000
Address Space Number (ASN) 00000000 0000000D
AST Summary / AST Enable (ASTSR_ASTEN) 00000000 0000000F
Floating-Point Enable (FEN) 00000000 00000001
Interrupt Priority Level (IPL) 00000000 00000008
Machine Check Error Summary (MCES) 00000000 00000000
Virtual Page Table Base Register (VPTB) 00000002 00000000
Failing Instruction:
SCH_STD$LOCKR_QUAD_C+000F8: LDL R27,#X0008(R4)
Instruction Stream (last 20 instructions):
SCH_STD$LOCKR_QUAD_C+000A8: STL R27,(SP)
SCH_STD$LOCKR_QUAD_C+000AC: SUBQ SP,#X0C,SP
SCH_STD$LOCKR_QUAD_C+000B0: BIS R31,#X03,R25
SCH_STD$LOCKR_QUAD_C+000B4: LDL R18,#X000C(SP)
SCH_STD$LOCKR_QUAD_C+000B8: LDA R27,#X03A0(R13)
SCH_STD$LOCKR_QUAD_C+000BC: BSR R26,#XFFFD48
SCH_STD$LOCKR_QUAD_C+000C0: ADDQ SP,#X10,SP
SCH_STD$LOCKR_QUAD_C+000C4: LDQ R28,(SP)
SCH_STD$LOCKR_QUAD_C+000C8: LDQ R0,#X0008(SP)
SCH_STD$LOCKR_QUAD_C+000CC: LDQ R1,#X0010(SP)
SCH_STD$LOCKR_QUAD_C+000D0: LDQ R13,#X0018(SP)
SCH_STD$LOCKR_QUAD_C+000D4: ADDQ SP,#X20,SP
SCH_STD$LOCKR_QUAD_C+000D8: RET R31,(R28)
SCH_STD$LOCKR_QUAD_C+000DC: BIS R31,R31,R31
SCH_STD$LOCKR_QUAD_C+000E0: SUBQ SP,#X20,SP
SCH_STD$LOCKR_QUAD_C+000E4: STQ R26,(SP)
SCH_STD$LOCKR_QUAD_C+000E8: STQ R0,#X0008(SP)
SCH_STD$LOCKR_QUAD_C+000EC: STQ R1,#X0010(SP)
SCH_STD$LOCKR_QUAD_C+000F0: STQ R13,#X0018(SP)
SCH_STD$LOCKR_QUAD_C+000F4: BIS R31,R27,R13
SCH_STD$LOCKR_QUAD_C+000F8: LDL R27,#X0008(R4)
SCH_STD$LOCKR_QUAD_C+000FC: EXTBL R27,#X02,R27
SCH_STD$LOCKR_QUAD_C+00100: SUBQ R27,#X0C,R17
SCH_STD$LOCKR_QUAD_C+00104: BNE R17,#X000020
SCH_STD$LOCKR_QUAD_C+00108: LDL R25,#X00E4(R4)
Thanks,
Ben
QED Qualitas Est Demonstrandum
==============================
Ben Santing, Technical Consultant Phone: DTN 822 4330
European Customer Service Centre Phone: DTN 822 4269
Digital Equipment International B.V. FAX: DTN 822 4445
In replying, please use [email protected]
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3123.1 | | KZIN::HUDSON | That's what I think | Mon Feb 03 1997 11:03 | 48 |
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 3-FEB-1997 16:02:32.72
To: nm%vbormc::"[email protected]"
CC: HUDSON
Subj: RE: 18755 Paston Chase Ltd, system bugcheck
Hello,
Thanks for your question on the INVEXCEPTN bugcheck.
The instruction that appears to have failed is:
SCH_STD$LOCKR_QUAD_C+000F8: LDL R27,#X0008(R4)
Which is part of the MACRO-64 generated for the source line:
CMPB #DYN$C_PCB,PCB$B_TYPE(R4) ; CHECK FOR PCB
The INVEXCEPTN is an access violation (from the signal array):
Arg Count = 00000005 - 5 args
Condition = 0000000C - arg #1, 0xC == "access violation"
Argument #2 = 00000000 - arg #2, 0
Argument #3 = 00000008 - arg #3, failing v/a
Argument #4 = 8001D388 - arg #4, failing pc
Argument #5 = 00000803 - arg #5, failing psl
The "LDL" instruction is attempting to read a location which is offset 8 bytes
from R4 (PCB$B_TYPE == 8). From the Exception frame, the contents of R4 at the
time of the crash was 0. This all fits with the accvio - i.e. attempting to
read address 8, which is an invalid address, while in kernel mode will cause a
bugcheck.
So the code is expecting that R4 will contain a PCB. In the start of the code
for "SCH_STD$IOLOCKW", the first thing it does is to :
MOVL ARG$_PCB(AP),R4 ; GET PCB INPUT
So it looks like R4 should be OK, assuming that the PCB was passed as an
argument.
From this, I can only conclude that when you're calling SCH_STD$IOLOCKW, you're
passing zero as a PCB address.
Regards
Nick Hudson
Digital Software Partner Engineering
|
| 3123.2 | | KZIN::HUDSON | That's what I think | Mon Feb 10 1997 10:29 | 38 |
| From: VBORMC::"[email protected]" "MAIL-11 Daemon" 10-FEB-1997 10:48:51.47
To: [email protected]
CC: [email protected]
Subj: RE: FWD: Returned mail: Cannot send message for 5 days
Nick,
Declan Lennon had already forwarded me a copy, but thanks all the same.
I'm still struggling with this. I have proved that the cmkrnl call and the
sch_std$iolockw call work fine by writing a bit of 'Noddy' code. However,
there must be something in the real code that is causing a problem because it
still crashes if I call it where I want to call it. I'm in the process of
'rolling forward' the call to try to isolate the problem.
Regards
Graham Mann
Paston Chase
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id LAA07804 for
<[email protected]>; Mon, 10 Feb 1997 11:45:29 +0100
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id LAA23849 for
<[email protected]>; Mon, 10 Feb 1997 11:50:15 +0100 (MET)
% Received: from GREEN.paston.co.uk (green.paston.co.uk [194.129.188.9]) by
server21.digital.fr (8.7.5/8.7) with SMTP id LAA20399 for
<[email protected]>; Mon, 10 Feb 1997 11:52:20 +0100 (MET)
% Received: by green.paston.co.uk (MX V4.1 AXP) id 1; Mon, 10 Feb 1997 10:48:27
ES
% Date: Mon, 10 Feb 1997 10:48:26 EST
% From: Graham Mann <[email protected]>
% Reply-To: [email protected]
% To: [email protected]
% CC: [email protected]
% Message-ID: <[email protected]>
% Subject: RE: FWD: Returned mail: Cannot send message for 5 days
|
| 3123.3 | | KZIN::HUDSON | That's what I think | Tue Feb 11 1997 04:42 | 45 |
| From: VBORMC::"[email protected]" "MAIL-11 Daemon" 11-FEB-1997 09:38:16.36
To: [email protected]
CC: [email protected]
Subj: SCH$IOLOCK Crash
Nick,
I may have found the issue, and it agrees with your assesment, and the crash
dump.
I've used the following which crashes in some procedures but not in others!
extern PCB *CTL$GL_PCB; /* Own PCB address */
server_pcb = CTL$GL_PCB;
io_database_mutex = SCH_STD$IOLOCKW(server_pcb);
SCH_STD$IOUNLOCK(server_pcb);
'server_pcb' does not always get the PCB value, it is sometimes set to zero.
The routine that fails has previously been locked into memory, does this
explain it?
A work around appears to be to explicitly pass the PCB value to the proceedure.
Graham Mann
Paston Chase
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id KAA09040 for
<[email protected]>; Tue, 11 Feb 1997 10:34:37 +0100
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id KAA26382 for
<[email protected]>; Tue, 11 Feb 1997 10:39:22 +0100 (MET)
% Received: from GREEN.paston.co.uk (green.paston.co.uk [194.129.188.9]) by
server21.digital.fr (8.7.5/8.7) with SMTP id KAA29970 for
<[email protected]>; Tue, 11 Feb 1997 10:41:31 +0100 (MET)
% Received: by green.paston.co.uk (MX V4.1 AXP) id 1; Tue, 11 Feb 1997 09:37:55
ES
% Date: Tue, 11 Feb 1997 09:37:54 EST
% From: Graham Mann <[email protected]>
% Reply-To: [email protected]
% To: [email protected]
% CC: [email protected]
% Message-ID: <[email protected]>
% Subject: SCH$IOLOCK Crash
|
| 3123.4 | | KZIN::HUDSON | That's what I think | Tue Feb 11 1997 05:07 | 40 |
| From: DEC:.REO.REOVTX::HUDSON "[email protected] - UK Software
Partner Engineering 830-4121" 11-FEB-1997 10:07:03.21
To: nm%VBORMC::"[email protected]"
CC: HUDSON
Subj: RE: SCH$IOLOCK Crash
Hello Graham
>extern PCB *CTL$GL_PCB; /* Own PCB address */
>
> server_pcb = CTL$GL_PCB;
> io_database_mutex = SCH_STD$IOLOCKW(server_pcb);
> SCH_STD$IOUNLOCK(server_pcb);
>
>'server_pcb' does not always get the PCB value, it is sometimes set to zero.
The only reason I could think that "CTL$GL_PCB" might not be valid is if the
code thread concerned happens to be in interrupt mode at the time it reads that
location. All the CTL$... symbols point at P1-space; P1-space is process
specific, and is only valid when you're running in process context. From my
research, everyone seems to say that using CTL$GL_PCB is a valid way to obtain
your own PCB address; I can't see mention of anyone saying stuff like "be
careful because..."
>The routine that fails has previously been locked into memory, does this
>explain it?
Only if it's been locked into memory because it's going to be called on the
interrupt stack.
>A work around appears to be to explicitly pass the PCB value to the proceedure.
If this is feasible, and you know you have a decent PCB value, then this sounds
a good idea.
Does this help?
Nick
|
| 3123.5 | | KZIN::HUDSON | That's what I think | Tue Feb 11 1997 06:06 | 34 |
| From: VBORMC::"[email protected]" "MAIL-11 Daemon" 11-FEB-1997 10:42:02.08
To: [email protected]
CC: [email protected]
Subj: RE: SCH$IOLOCK Crash
Nick,
Yup I believe that it does, as long as I have a work around.
You can close this one.
Thanks again for your help.
Graham Mann
Paston Chase
% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by
vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id LAA12652 for
<[email protected]>; Tue, 11 Feb 1997 11:38:57 +0100
% Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by
mail.vbo.dec.com (8.7.3/8.7) with ESMTP id LAA27619 for
<[email protected]>; Tue, 11 Feb 1997 11:43:43 +0100 (MET)
% Received: from GREEN.paston.co.uk (green.paston.co.uk [194.129.188.9]) by
server21.digital.fr (8.7.5/8.7) with SMTP id LAA26360 for
<[email protected]>; Tue, 11 Feb 1997 11:45:51 +0100 (MET)
% Received: by green.paston.co.uk (MX V4.1 AXP) id 1; Tue, 11 Feb 1997 10:42:15
ES
% Date: Tue, 11 Feb 1997 10:42:15 EST
% From: Graham Mann <[email protected]>
% Reply-To: [email protected]
% To: [email protected]
% CC: [email protected]
% Message-ID: <[email protected]>
% Subject: RE: SCH$IOLOCK Crash
|