T.R | Title | User | Personal Name | Date | Lines |
---|
3493.1 | More information needed | STAR::VATNE | Peter Vatne, VMS Development | Fri Oct 19 1990 11:38 | 6 |
| Sorry, we are not mind readers. Error code 12 means ACCVIO, nothing more.
See note 1735.1 on how to interpret system statuses.
Please post the contents of the server error log. More importantly,
please tell us which version of VMS you are using and the type of
graphics hardware!
|
3493.2 | VS3100 Model 30 with SPX graphics and VMS v5.3-1 | SCOTMN::WOOD | El Vaquero | Wed Oct 24 1990 08:57 | 102 |
|
>>Sorry, we are not mind readers.
What does this mean !?
How are we supposed to know what is relevant in a server log, is the information
contained therein documented ?
If it says 'internal error code 12' after explicitly saying SYSTEM-F-ACCVIO,
this seems to be completely redundant information.
It seemed to me that 'internal error code 12' was a SERVER internal error
and that maybe there was some sort of documentation to provide an
explanation for it that I did not know about.
As I said, .0 was a first pass, I wanted to avoid spending an hour typing in
a server error log, that a customer faxed to me if possible, however, here it is,
I hope it's worth it!
Rich
15-OCT-1990 07:50:27.1 Hello, this is the X server
Dixmain address=13074
Now attach all known txport images
%DECW-I-ATTACHED, transport DECNET attached to its network
%DECW-W-ATT_FAIL, failed to attach transport LAT
-SYSTEM-F-PRIVINSTAL, shareable images must be installed to run priveledged
image
in SetFontPath
Connection 99700 is accepted by Txport
out SetFontPath
ScanProc color support loaded
scn$InitOutput address=12acd0
Connection Prefix: len == 60
15-OCT-1990 07:51:17.4 Now I call scheduler/dispatcher
15-OCT-1990 07:51:19.0 Connection 99738 is accepted by Txport
15-OCT-1990 07:51:21.6 Connection 99700 is closed by Txport
15-OCT-1990 07:51:54.9 Connection 99738 is closed by Txport
15-OCT-1990 07:51:57.0 Connection 99700 is accepted by Txport
15-OCT-1990 07:52:18.8 Connection 99770 is accepted by Txport
15-OCT-1990 07:52:26.2 Connection 9adf8 is accepted by Txport
15-OCT-1990 07:52:41.4 Connection 9ae30 is accepted by Txport
15-OCT-1990 10:54:25.9 Connection 226290 is accepted by Txport
15-OCT-1990 11:16:52.6 Connection 2266c8 is accepted by Txport
15-OCT-1990 11:28:23.9 Connection 2266c8 is closed by Txport
15-OCT-1990 11:28:52.4 Connection 2266c8 is accepted by Txport
15-OCT-1990 11:30:44.3 Connection 2266c8 is closed by Txport
15-OCT-1990 11:30:44.5 Txport status = 2dba002 ( copy and write) on client 6
15-OCT-1990 11:32:16.8 Connection 2f3a00 is accepted by Txport
15-OCT-1990 13:13:36.7 Using extra todo packet pool...
15-OCT-1990 16:48:54.0 Connection 2ca648 is accepted by Txport
15-OCT-1990 16:52:48.2 Connection 2ca648 is closed by Txport
15-OCT-1990 17:06:56.9 Connection 226290 is closed by Txport
15-OCT-1990 17:06:57.2 Connection 2f3a00 is closed by Txport
15-OCT-1990 17:06:58.4 Client 5 resets the server
15-OCT-1990 17:07:02.6 FreeAllUnusedFonts: gc_ref_count = 1 for
SYS$COMMON:[SYSFONT.DECW.75DPI]FIXED.DECW$FONT;1
15-OCT-1990 17:07:03.3 Destroying Loadable Microcode Context
15-OCT-1990 17:07:03.6 ...Deallocating Ucode ROM
15-OCT-1990 17:07:03.9 ...Deallocating Ucode FIXED
15-OCT-1990 17:07:06.4 ScanProc color support loaded
scn$InitOutput address=12acd0
Connection 2f8848 is accepted by Txport
15-OCT-1990 17:07:14.9 Now I call scheduler/dispatcher
15-OCT-1990 17:07:15.7 Connection 2f5e18 is accepted by Txport
15-OCT-1990 17:07:19.6 Connection 2f8848 is closed by Txport
16-OCT-1990 07:32:35.2 Connection 2f5e18 is closed by Txport
16-OCT-1990 07:32:37.3 Connection 2f5e50 is accepted by Txport
16-OCT-1990 07:32:59.0 Connection 2f5e88 is accepted by Txport
16-OCT-1990 07:33:01.3 Connection 2f5ec0 is accepted by Txport
16-OCT-1990 07:33:17.2 Connection 2f5ef8 is accepted by Txport
16-OCT-1990 08:19:40.9 SYSTEM-F-ACCVIO, access violation, reason mask=05,
virtual address=200000B2, PC=001317F2, PSL=03C00001
Unrecoverable server internal error(error code = 12) found, terminating all
connections.
Exception Call stack dump follows:
8f8c5
1317f2
131218
131
12ab4f
12a94a
12ecf4
220aa
d5ee
1083d
10355
13343
********** marking the end of call stack dump **********
********************************************************
16-OCT-1990 08:19:44.6 Destroying Loadable Microcode Context
16-OCT-1990 08:19:44.9 ...Deallocation Ucode ROM
16-OCT-1990 08:19:45.2 ...Deallocation Ucode FIXED
16-OCT-1990 08:19:45.5 MEMMGR/XFREE - memory block 135244 has an invalid header
and is not freed
16-OCT-1990 08:19:45.9
Fatal server bug!
16-OCT-1990 08:19:46.2 Server runtime error limit exceeded - type
@SYS$MANAGER:DECW$STARTUP server to restart, or see your system
manager.16-OCT-1990 08:19:46.3
|
3493.3 | ScanProc bug | STAR::VATNE | Peter Vatne, VMS Development | Wed Oct 24 1990 14:38 | 27 |
| Thanks for the server error log. Sorry about the brusque language,
it's just that without the VMS version and the full log file, your
request sounded like "This program doesn't work, what's the matter?".
All the information in the error log is useful. That's why we put
it in there in the first place. The base addresses and the stack
dump are particularly useful. The information isn't documented.
It is only useful to the support organizations and engineering,
who have access to the map files to be able to decode the stack.
Yes, the information in the server error log is redundant. Fatal
error recovery in the server is tricky, so we figured it was better
to print too much information than not enough. I agree that the
wording 'internal error code' is misleading and should be changed
to something like 'status code' or the like. I suggest entering
a QAR to make sure we don't forget to do this for DECwindows V3.
As far as the customer problem: this appears to be a problem
with the ScanProc specific drawing code. I don't know if this
problem has already been fixed or not. Our policy for SSB
releases is that all server ACCVIOs should be reported via SPR
or CLD, so that the correct support organizations can get
involved. They will supply the customer with a patch or
workaround if this is one of the known problems.
P.s. is the stack dump completely accurate? Address 131
looks like the first three digits of a six digit address.
|
3493.4 | High priority SPR | SCOTMN::WOOD | El Vaquero | Thu Oct 25 1990 09:38 | 13 |
|
Thanks for the info, after speaking with the customer, I am submitting
a priority 1 SPR.
I'd be interested in any documentation on the server, even if it's just for
internal use. It's a bit disconcerting for us in support if all we can say to
a customer is, we'll log an SPR for you.
Also, on a personal note I'd like to know more about the internals of the server
process.
Rich
P.S. Omit the line with '131' in it, case of 1 too many cut and pastes.
|
3493.5 | Request noted | STAR::VATNE | Peter Vatne, VMS Development | Thu Oct 25 1990 11:34 | 9 |
| I've forwarded your request for a server manual to the documentation group.
They've had a server internals manual on the back burner for quite some time.
Unfortunately, it is still incomplete in a lot of areas -- in particular,
it does NOT describe all the messages in the server error log file.
If you are in a support group that has access to the listing and map files
of DECwindows, then we may be able to supply you with a tool to help you
analyze the stack dump. Give me a few days to work this out with the
VMS Support Group.
|
3493.6 | Marvellous | SCOTMN::WOOD | El Vaquero | Thu Oct 25 1990 13:36 | 5 |
|
Yeah, thanks, it'd be nice to have that tool, I haven't looked at source
listings for a while. The server internal manual sounds promising, I
don't suppose there's any general information (books) on X Servers available
is there ?
|