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));

and the machine code around it

> 00010930 L$142: // 060708
> { .mii
> 008082000800 00010930 ld4 in0 = [in0] // r32 = [r32] // 060709
> 012000000640 00010931 mov ai = 0 ;; // r25 = 0
> 00A7BB740800 00010932 shl in0 = in0, 8 ;; // r32 = r32, 8
> }
> { .mii
> 000008000000 00010940 nop.m 0
> 0000B2000800 00010941 sxt4 in0 = in0 ;; // r32 = r32
> 010002048800 00010942 add in0 = r36, in0 // r32 = r36, r32
> }
> { .mfb
> 000008000000 00010950 nop.m 0
> 000008000000 00010951 nop.f 0
> 00A000001000 00010952 br.call.sptk.many rp = // br0 = CMA$TIS_ERRNO_GET_ADDR
> CMA$TIS_ERRNO_GET_ADDR ;;
> }
> { .mii
> 008080800A80 00010960 ld4 out0 = [r8] // r42 = [r8]
> 012000002640 00010961 mov ai = 1 // r25 = 1
> 010802900040 00010962 mov gp = r41 ;; // r1 = r41
> }
> { .mib
> 000008000000 00010970 nop.m 0
> 0000B2A00A80 00010971 sxt4 out0 = out0 // r42 = r42
> 00A000001000 00010972 br.call.sptk.many rp = DECC$STRERROR ;; // br0 = DECC$STRERROR
> }
> { .mii
> 010802900040 00010980 mov gp = r41 // r1 = r41
> 012000006640 00010981 mov ai = 3 // r25 = 3
> 0000B0800B00 00010982 sxt4 out2 = r8 // r44 = r8
> }
> { .mmi
> 010802000A80 00010990 mov out0 = in0 ;; // r42 = r32
> 0120001008C0 00010991 add in3 = @ltoff($LITERAL$+432), // r35 = @ltoff($LITERAL$+432), r1
> gp
> 000008000000 00010992 nop.i 0 ;;
> }
> { .mfb
> 0080C2300AC0 000109A0 ld8 out1 = $LITERAL$ // r43 = [r35]
> 000008000000 000109A1 nop.f 0
> 00A000001000 000109A2 br.call.sptk.many rp = DECC$TXSPRINTF ;; // br0 = DECC$TXSPRINTF
> }
> { .mfi
> 010802900040 000109B0 mov gp = r41 // r1 = r41
> 000008000000 000109B1 nop.f 0
> 000008000000 000109B2 nop.i 0
> }
> 000109C0 L$152:

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

TIA for any input.

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

On 2022-03-08, Mark Daniel <mark.daniel@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.

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.

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.

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.

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

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

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

On 2022-03-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
> 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.
>

Or alternatively, depending on how the VMS linker gathers any static
data areas within a module when generating a final image, there could
have been a buffer overflow from a writable page into a following R/O
code page.

Take another look at the reported virtual address. Don't you find it
suspicious that the failing VA is exactly at the start of a page boundary ?

Oh, and that sprintf() really should become snprintf() if it's available
to Mark on the systems he supports people running this code on.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 9/3/22 10:43 am, Simon Clubley wrote:
> On 2022-03-08, Mark Daniel <mark.daniel@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.

On 3/9/2022 8:32 AM, Simon Clubley wrote:
> On 2022-03-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> 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.
>
> Or alternatively, depending on how the VMS linker gathers any static
> data areas within a module when generating a final image, there could
> have been a buffer overflow from a writable page into a following R/O
> code page.

That is also a problem of aCacheIdx.

> Take another look at the reported virtual address. Don't you find it
> suspicious that the failing VA is exactly at the start of a page boundary ?

39B00 is not on a page boundary.

> Oh, and that sprintf() really should become snprintf() if it's available
> to Mark on the systems he supports people running this code on.

snprintf is available on VMS.

Arne

On 3/9/2022 8:58 AM, Mark Daniel wrote:
>> On 2022-03-08, Mark Daniel <mark.daniel@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.

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

Something must be overwriting something.

Multithreaded code?

Arne

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

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;

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

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?

Arne

Mark,

just create/run that process using the /DUMP qualifier. It should create a process dump, when hitting the ACCVIO. Then you can analyze the dump using ANALYZE/CRASH (or ANALYZE/PROCESS) and look at the failing instruction code and data.

Reason Mask = 4 indicates an error during WRITE of data

Volker.

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.

On 2022-03-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> 39B00 is not on a page boundary.
>

You are correct sorry. Wrong number of trailing zero digits in my head
while doing the sums.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.