Conference vaxaxp::vmsnotes

638.0. "Inconsistent alloc-dealloc in SYS$DKDRIVER?" by PRSSOS::MAILLARD (Denis MAILLARD) Fri May 23 1997 12:47

	The following lines are extracted from the ring buffer of a V6.2-1H3
AlphaServer 8400 Model EV56/440 DOUBLDEALO crash dump with SYSTEM_CHECK set to 1
which looks extremely similar to those mentionned in a TIMA article (non
customer readable) titled "[PLY_PSDC] System Crashes with Pool Corrupted After
Restarting PSDC" for which no solution has yet been provided.

                        Non-Paged Pool History Ring-Buffer
                         (2048 entries: Most recent first)

   Packet Adr  Size  Type  Subtype Caller's PC   Routine called      Entry Adr
    --------  -----  -----  ----    --------    ---------------      --------

    82A79240  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82433140
    82A79240  65040  CI      97     8032AC44    EXE$ALONPAGVAR       82431ED0
    82A79240  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82439450
    82A79240  65040  CI      97     8032AC44    EXE$ALONPAGVAR       824387F0
    82A79240  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82437A90
    82A79240  65040  CI      97     8032AC44    EXE$ALONPAGVAR       82436D70
    82A79240  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82435910
    82A79240  65040  CI      97     8032AC44    EXE$ALONPAGVAR       82434910
    82A79240  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82434160
    82A79240  65040  CI      97     8032AC44    EXE$ALONPAGVAR       82433630


    82A89080  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82431A40
    82A89080  65040  CI      97     8032AC44    EXE$ALONPAGVAR       82438D10
    82A89080  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     82438430
    82A89080  65040  CI      97     8032AC44    EXE$ALONPAGVAR       82437220
    82A89080  65088  MISC    29     8032AD64    EXE$DEANONPGDSIZ     824332B0

	I've two similar dumps for two different systems in the same cluster.
In the present case, same as in those mentionned in the article, PSDC$DC_SERVER
has just been started (LOGIN bit still set in process status and accumulated CPU
time equals 8, i.e. 0.08 second) and the variable non-paged pool list is also
corrupted (at the third element, which point to 82A89000, %x80 bytes before the
end of the deallocated above packets, or %x50 before the end of the allocated
packets; as the packet in the dump is entirely zeroed except for its first 16
bytes, the list of course ends there and as it is inside the deallocated packet,
this is what causes the DOUBLDEALO bugcheck). I haven't yet found any positive
element to incriminate DECPS (only circumstancial ones, including the fact that
there's no more crash since DECPS has been stopped, while there were several of
them a day before), but I'd like to get an explanation of the fact that
SYS$DKDRIVER (both 8032AD64 and 8032AC44 are located in its NPRO zone) seems to
consistently allocate 48 bytes less than it deallocates (there's no ring buffer
entry in between showing the allocation of these 48 bytes). Is it a normal
behaviour that I'm not aware of, or a specific problem that should be escalated?
		Thanks for any input.
			Denis.

This issue is being investigated by CA at the present time under the 
followin cases CFS.49122, CFS.43457, CFS.49725, CFS.50363 Please use IPMT 
to get added to the list.

Jilly

Denis,

I think the effect is due to rounding. If you ask the system for 65040 bytes
you will get 65088 bytes (rounded at 64 bytes), the driver will record what
it gets back and use that number for the deallocation.

Jur.

    Re .1: Thanks, Jilly. I knew that and am going to enter an(other) IPMT
    on the subject (there are four IPMT cases referenced in the STARS
    article). This note was mainly aimed at understanding the reason for
    the alloc-dealloc discrepancy.
    
    Re .2: Thanks for the explanation, Jur. I really feel a bit stupid now,
    the more so as I knew that there was a rounding and had simply
    forgotten about it... Time for some vacations, I suppose...
    			Denis.