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

Conference clt::cma

Title:	DECthreads Conference

Moderator:	PTHRED::MARYSTEON

Created:	Mon May 14 1990
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1553
Total number of notes:	9541

1497.0. "ACCVIO without CMA exception" by COOKIE::MHUA () Thu Feb 27 1997 12:09

    
    Our image has cms TRY - ENDTRY block (in some places it's nested) to
    catch eny excpetion.  Some customer reported a case of access violation
    which does not come with a CMA exception error.
    
    We had numerous access violation before, but they all came with errors:
    CMA-F-EXCCOP or
    CMA-F-EXCEPTION 
    along with access violation information.
    
    The code that was executed at the point of failure was for sure within 
    the TRY-END TRY block.
    
    Could it be possible to get access violation as below while in the TRY
    block without being caught by CMA exception mechanism?
    
    The customer is on OpenVMS V6.2 on Alpha.
    
    
        %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
        address=80808060, PC=805AD6D8, PS=0000001B
    
          Improperly handled condition, image exit forced.
            Signal arguments:   Number = 00000005
                                Name   = 0000000C
                                         00000004
                                         80808060
                                         805AD6D8
                                         0000001B
    
            Register dump:
            R0  = 0000000000000000  R1  = 0000000000C893D5  R2 =
    000000000070CBF0
            R3  = 0000000000000000  R4  = 0000000000CC6850  R5 =
    0000000000000000
            R6  = 0000000000CD2BB0  R7  = 0000000000F19B88  R8 =
    0000000000CC6ACA
            R9  = 0000000000CD2BB0  R10 = 0000000000000000  R11=
    0000000000000000
            R12 = 0000000000000000  R13 = 0000000000000000  R14=
    0000000000000000
            R15 = 000000000065E0E0  R16 = 0000000000C897D1  R17=
    0000000000CD2BB0
            R18 = FFFFFFFFFF32D450  R19 = 0000000000000000  R20=
    0101010101010101
            R21 = 8080808080808080  R22 = 000000007F3C2878  R23=
    000000000000005B
            R24 = 0000000000002BB0  R25 = 0000000000000003  R26=
    0000000000813FDC
            R27 = 000000007F3C2878  R28 = 000000000000000C  R29=
    0000000000000000
            SP  = 000000007EE4E000  PC  = FFFFFFFF805AD6D8  PS =
    000000000000001B
        
    
    Masami

T.R Title User Personal
Name Date Lines

1497.1 Couldn't handle it! WTFN::SCALES Despair is appropriate and inevitable. Thu Feb 27 1997 13:22 21

T.R	Title	User	Personal Name	Date	Lines
1497.1	Couldn't handle it!	WTFN::SCALES	Despair is appropriate and inevitable.	`Thu Feb 27 1997 13:22`	21
	.0> Could it be possible to get access violation as below while in the TRY .0> block without being caught by CMA exception mechanism? Yes and no: .0> Improperly handled condition, image exit forced. That is, something (presumably DECthreads) tried to handle the ACCVIO but a catastrohpic problem occurred and the system killed the image. I don't really have a good idea of what happened in this particular case. My gut feeling is that a memory corruptor nailed a frame on a thread's stack, so that when the thread returned from that routine the stack pointer ended up pointing to lalaland, and that made it imposible to run the condition handler. So, my advice is to do all the normal things that you have to do to find a memory corruptor. (Most likely it's something writing beyond the end of an array on the stack.) Webb

.0> Could it be possible to get access violation as below while in the TRY
.0> block without being caught by CMA exception mechanism?

Yes and no:

.0>         Improperly handled condition, image exit forced.

That is, something (presumably DECthreads) tried to handle the ACCVIO but a
catastrohpic problem occurred and the system killed the image.

I don't really have a good idea of what happened in this particular case.  My
gut feeling is that a memory corruptor nailed a frame on a thread's stack, so
that when the thread returned from that routine the stack pointer ended up
pointing to lalaland, and that made it imposible to run the condition handler.

So, my advice is to do all the normal things that you have to do to find a
memory corruptor.  (Most likely it's something writing beyond the end of an
array on the stack.)


				Webb