Conference turris::ada

3838.0. "ACCVIO during ADA$ELAB_* !!" by TAV02::ZVI_P (Here we are) Tue Feb 04 1997 10:59

Hi

 A customer problem.

 He was kind enough to build special sources that reproduce the problem.

 I reproduced it at the office on ALPHA OVMS 6.2 with both DEC ADA 3.2-8
and 3.3-7 .

 An image ACCVIOlates during the elaboration of a package.

 The sources are at:

$ dir ppantr::$2$DKB200:[IPMT.DAVID]/sec

Directory PPANTR::$2$DKB200:[IPMT.DAVID]

DUMB.ADA;1               504/504      29-JAN-1997 13:05:23.00            
[376,3
73]             (RWED,RWED,RWED,RE)
DUMMY_.ADA;1              13/14        3-FEB-1997 11:01:55.00            
[376,3
73]             (RWED,RWED,RWED,RE)

Total of 2 files, 517/518 blocks.
$


 Here is a log of a debug session:

On 3.3-7

$ run dumb

         OpenVMS Alpha DEBUG Version V6.2-103R

%DEBUG-I-INITIAL, language is ADA, module set to DUMB
%DEBUG-I-NOTATMAIN, type GO to get to start of main program

DBG> Go
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=0002C000, PC
=8048EEAC, PS=0000001B
%ADA-E-FORTRABAC, Force traceback signal: an unhandled exception is
terminating
main program
break on unhandled exception preceding SHARE$ADARTL+347284
DBG> sho calls
 module name     routine name                     line       rel PC    abs
PC
 SHARE$ADARTL                                               00000000 
001B0C94
 SHARE$LIBOTS_DATA2
                                                            00000000 
80495D44
----- above condition handler called with exception 0000000C:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=0002C000, PC
=8048EEAC, PS=0000001B
----- end of exception message
                                                            00000000 
8298A2BC
*DUMMY_          DUMMY_                                     00000000 
8048EEAC
*ADA$ELAB_DUMB                                              00000000 
000400C0
 SHARE$ADARTL                                               00000000 
001B0E18
 SHARE$ADARTL                                               00000000 
001B0594
 SHARE$ADARTL                                               00000000 
0019B4D0
*ADA$ELAB_DUMB                                              00000000 
0004005C
                                                            00000000 
00043D3C
                                                            00000000 
82A841F8
DBG> exit

---------

On 3.2-8 similar results are achieved.

The customer says he gets that also on ALPHA OVMS 6.1

Is this a known bug ?

			Thanks
			Zvi - ISrael MCS.

Hi ADA people

 It's a big customer and our sales are pushing ...

 Can someone look at -.0 and find what is that ACCVIO.

		Thanks
		Zvi

I'll do it right away

/Bevin          

I can't reproduce it.

/Bevin

Does it run OK on your environment ?

What version of ADA ?

		Thanks
		Zvi

Hi Bevin

 Sorry I did not mention.

 It happens when I compile it with "/deb/noop" and link with "/deb".
 Both on ADA 3.2-8 and 3.3-7 .

 The customer claims that it happens also without the "/deb" - I'll check
that with him on Sunday.

		Thanks again
		Zvi
		 

Ok - I have it reproduced

	ada/noopt/deb DUMMY_.ADA;,DUMB.ADA;
	linka/deb DUMB

/Bevin

I now have a simple version of the problem

If you look at the IL for the following, you will notice that we
create a 37 byte constant...

        VARIABLE SYMBOL A00CF0998 : IS_MUTABLE, LOCATOR={1:0}, ENVIRONMENT=TMP,
            UPLEVEL_REFERENCED=&ASSUMED_TRUE, NO_DST_INFO, ALLOCATED, LENGTH=37,

and promptly proceed to fetch 117 bytes from it

    	L000005:    FETCHF.STR8 (A00CF0998, [INT64 117];

which, as in the .0 example, can accvio...

The problem is limited to some rather unusual aggregates, and unless it
accvio's, is actually pretty innocuous.

I'll look into a fix.

/Bevin


package Tmp is

    type R is
        record
            C1,C2           : String(1..16);
            C3,C4,C5,C6,C7  : Boolean;
            D               : String(1..80);
        end record;

    D_Init : constant String(1..80) := (1..80=>' ');

    X : constant R := (C1 => "1234567812345678",
              C2 => "1234567812345678",
              C3|C4|C5|C6|C7 => False,
              D  => D_Init);

end;

By the way - VAX ADA gets this right...

Line 12
                        66 50 AC 25 28    0016          movc3   #37,80(ap),(r6)

Line 15
                   25 A6 6C 0050 8F 28    001B          movc3   #80,(ap),37(r6)

We have a likely fix to this issue which should show up in future 
versions of DEC Ada.

(Potentially the V3.3 ECO kit for OpenVMS Alpha, and V3.4 for OpenVMS VAX.
The edit does pass the reproducer given by the customer, and is being
thoroughly tested now...)

Charlie

On OpenVMS Alpha, the ECO kit is being submitted, ADAAE23033.

On VAX, its in V3.4 which is currently in field test.