Re: Weirder and weirder, Re: CEE0810: I think I have something fighting with itself, or with my own code

Let's take stock of what we know:

1. This is quite literally the same version of HTTPAPI that I've been using for over a decade, and I've never seen this exception before.

2. The exception occurs whether I'm translating the reply with my own call to iconv, or I'm using Scott's HTTP_xlatep.

3. I'm not explicitly allocating or deallocating any memory myself, and my buffers are global static blocks of 500000 bytes each.

4. The only explicit external calls are the ones to HTTPAPI, and the ones to iconv. Everything else is contained within a single source member.

5. The only place where I'm passing a length (and therefore the only place where I could be lying about a length) is when I translate the reply.

6. The mere act of setting a QIBM_MALLOC_TYPE envvar with a non-null value, even a nonsense value, prevents it from happening.

7. It has only been observed to happen on an old box, running a no-longer-supported OS release.

8. When the exception occurs, it is always in a 1-2-3 pattern of two successful web service calls, then an exception, then two more successfull calls, then another exception, and it does not appear to make any difference whether the application exits with LR set after each call, or makes the call repeatedly, nor whether I'm using iconv directly, or using HTTP_xlatep. Were it not for the fact that our Google Geocoding web service key is only good for a finite number of calls per day, I could test whether this pattern can repeat ad nauseum, and whether the consistently successful calls on our cloud box can repeat ad nauseum.

9. In this repeating 1-2-3 pattern, the "1" iterations always have a "New iconv() objects set" message near the top of the debug file, the "2" iterationss do not, and the "3" iterations have neither the "New iconv() objects set" message, nor the 5 lines that are supposed to follow the "recvdoc parms" message.

10. When the exception is *not* occurring, the "New iconv() objects set" message *only* occurs the *first* time the application is run within a given job.

I will check for the unlikely possibility that I am in fact lying about the length of BUFFY, and that in doing so twice, I'm setting up conditions for the exception to occur. Because nothing else occurs to me at this point.

--
JHHL