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

[Mark Daniel]

On 10/3/22 12:49 am, Arne Vajhøj wrote:
> On 3/9/2022 8:58 AM, Mark Daniel 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 
> 
>>>> Line 60790 is
>>>>
>>>>>        3   60709             sprintf (ares[aCacheIdx], "[%s]", 
>>>>> strerror(errno));
> 
>> 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;
> 
> And similar for aCacheIdx I presume.

Yes.

       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.
> 
> I would put in a:
> 
> if(aCacheIdx < 0 || CACHE_MAX <= aCacheIdx)
> {
>      printf("We have a problem aCacheIdx = %d\n", aCacheIdx);
> }
> sprintf (ares[aCacheIdx], "[%s]", strerror(errno));
> 
> Or maybe:
> 
> if(aCacheIdx < 0 || CACHE_MAX <= aCacheIdx)
> {
>      printf("We have a problem aCacheIdx = %d\n", aCacheIdx);
> }

As "debug" statements; can be done.  Would signal on corruption of the 
indices.

2147483647 is a big number of lookups.

At 100/S that's ~249 days before rollover.

The maximum lookup rate is actually once every 2 seconds.

> if(strlen(strerror(errno)) > 255)
> {
>      printf("We have a problem strlen(strrerror) = %d\n", 
> strlen(strerror(errno)));
> }
> sprintf (ares[aCacheIdx], "[%s]", strerror(errno));

As a "debug" statement; can do.

The move to snprintf() should mitigate any effect though.

Will wait and see if that has any effect.

> Something must be overwriting something.

Yes.  And most commonly laid at the feet (or fingertips) of the developer.

> Multithreaded code?

No.

> Arne

-- 
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.