[Info-vax] %SYSTEM-F-ACCVIO in LIBOTS after several hours

[Mark Daniel]

On 9/3/22 10:43 am, Simon Clubley wrote:
> On 2022-03-08, Mark Daniel <mark.daniel at wasd.vsm.com.au> wrote:
>> Reproducible after several hours of continuous execution.
>>
>>> %SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=0000000000039B00, PC=FFFFFFFF842341D0, PS=0000001B
>>> %TRACE-F-TRACEBACK, symbolic stack dump follows
>>> image     module    routine               line      rel PC           abs PC
>>> LIBOTS                                       0 00000000000121D0 FFFFFFFF842341D0
>>> DECC$SHR  C$TXDOPRINT  putbuf            43567 000000000000CA82 FFFFFFFF84BC4FA2
>>> DECC$SHR  C$TXDOPRINT  decc$$txdoprint   43658 000000000000CD62 FFFFFFFF84BC5282
>>> DECC$SHR  C$TXDOPRINT  sprintf           44192 0000000000012492 FFFFFFFF84BCA9B2
>>> HTTPDMON  HTTPDMON  TcpIpLookup          60709 00000000000109A2 00000000000409A2
>>> HTTPDMON  HTTPDMON  AddRequest           60536 0000000000009A62 0000000000039A62
>>> HTTPDMON  HTTPDMON  MonitorHttpd         58867 0000000000001392 0000000000031392
>>> HTTPDMON  HTTPDMON  main                 58751 0000000000000962 0000000000030962
>>> HTTPDMON  HTTPDMON  __main               58666 00000000000000B2 00000000000300B2
>>>                                               0 FFFFFFFF80A37952 FFFFFFFF80A37952
>>> DCL                                          0 000000000007D2B2 000000007AE292B2
>>> %TRACE-I-END, end of TRACE stack dump
>>
>> Line 60790 is
>>
>>>        3   60709             sprintf (ares[aCacheIdx], "[%s]", strerror(errno));
>>
> 
> [snip]
> 
>>
>> The ACCVIO is related to the target, ares[aCacheIdx], or to the
>> argument, strerror(errno)), or...?
>>
>> TIA for any input.
>>
> 
> Since no-one else has replied, some generic observations:
> 
> Given the address and reason mask, it looks like something is trying to
> write into what looks like RO program code.

Normally you don't see to many LIBOTS or DECC$SHR references in such 
traces.  Not too much in the FFFFFFFFxxxxxxxx space at all.

BTW: VSI C V7.4-001 on OpenVMS IA64 V8.4-2L1

     Image name:                                 "DECC$SHR"
     Global Symbol Table name:                   "DECC$SHR"
     Image file identification:                  "V8.4-00"
     Image build identification:                 "XE4H-H4N-000066"
     Link identification:                        "Linker I02-37"
     Link Date/Time:                             22-AUG-2020 13:30:50.69

> Does changing the optimisation level (or disabling optimisation) change
> the behaviour ?
> 
> Don't assume errno is valid or that strerror() has behaved in an
> intelligent way if it has been presented with an invalid errno value.

Fair enough observation.

> Can you take an image dump when the program crashes and then look around
> the general area of the failing VA to see if there are any clues about
> what is at that location ? > > Are you sure that ares[aCacheIdx] points to a memory location big 
enough
> to hold the message ? Before that line of code is executed, you could
> try writing to a temporary file both errno and the length of the output
> from strerror(). Also try dumping the current value of aCacheIdx to that
> file.

Should be.

#define CACHE_MAX 16

    static  aCacheIdx, nCacheIdx;
    static char  abuf [CACHE_MAX][256],
                 ares [CACHE_MAX][256],
                 nbuf [CACHE_MAX][256],
                 nres [CACHE_MAX][256];
8< snip 8<
       idx = nCacheIdx++ % CACHE_MAX;

The ACCVIO is very indeterminate.  I mean the CACHE_MAX limit (16) will 
have been round-robined many times in the 8+ hours since last activated. 
  There are thousands/16 over that period.

> This has the feel of some out-of-bounds write. Whether that's due to a
> VMS issue or your code I can't tell.

You'd think it would be caught before being passed to LIBOTS.

> Also, consider the use of snprintf() instead of sprintf() if it is
> available to you. That line of code looks like an error reporting
> version of an unbounded strcpy() call and there's a reason why
> strncpy() and friends now exist. :-)

Yes.  Embarrassing.  Have moved these to snprintf().

> Simon.
Thanks.

-- 
Anyone, who using social-media, forms an opinion regarding anything 
other than the relative cuteness of this or that puppy-dog, needs 
seriously to examine their critical thinking.