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

[Arne Vajhøj]

On 3/8/2022 4:55 PM, Mark Daniel 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

> Line 60790 is
> 
>>       3   60709             sprintf (ares[aCacheIdx], "[%s]", 
>> strerror(errno));

> The ACCVIO is related to the target, ares[aCacheIdx], or to the 
> argument, strerror(errno)), or...?

The access violation is trying to write to 39B00, so it has to be
ares[aCacheIdx].

And if ares is a valid array of char arrays, then every indication
is that aCacheIdx has a bad value.

Arne