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

[Mark Daniel]

On 10/3/22 1:37 am, Arne Vajhøj wrote:
> On 3/9/2022 9:52 AM, Mark Daniel wrote:
>> On 10/3/22 1:19 am, Mark Daniel wrote:
>> 8< snip 8<
>>>> And similar for aCacheIdx I presume.
>>>
>>> Yes.
>>>
>>>        idx = nCacheIdx++ % CACHE_MAX;
>> 8< snip 8<
>>
>> Oops...
>>
>>        idx = aCacheIdx++ % CACHE_MAX;
> 
> Something is missing.
> 
> idx = aCacheIdx++ % CACHE_MAX;
> sprintf (ares[aCacheIdx], "[%s]", strerror(errno));
> 
> must be equivalent of:
> 
> idx = aCacheIdx % CACHE_MAX;
> aCacheIdx = aCacheIdx + 1;
> sprintf (ares[aCacheIdx], "[%s]", strerror(errno));
> 
> and that does not limit aCacheIdx.
> 
> Typo?

No.  Cut-and-paste :-)  But a bug all the same.  Well-spotted!

There are two code paths.  One for Ipv4 and another for 6.

Everywhere uses ares[idx] except one :-{

>          memset (&addr6, 0, sizeof(addr6));
>          if (inet_pton (AF_INET6, Address, &addr6.sin6_addr) > 0)
>          {
8< snip 8<
>          }
>          else
>             snprintf (ares[aCacheIdx], sizeof(ares[0]),
>                       "[%s]", strerror(errno));
>          return (ares[idx]);

That's likely it!

And IPv6 addresses are resolved so infrequently -- and are corrupted 
even less frequently -- that would explain the frequency of the crash.

> Arne

Thank you Arne.

And Simon; note the clip is from the revised code.

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