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

James,

That error means that it is trying to free up memory that isn't allocated.  When memory is allocated (in this case via the xalloc() subprocedure) the system makes a table of all of the things that have been allocated.  The "key" to the "table" of allocations is the starting address that's stored in the pointer.

When you ask to free memory (via xdealloc in this case) it looks up the allocation by the address, and if not found, you get the CEE0810.

What that tells me is that the pointer being passed to xdealloc() (which is eventually being passed to the CEEFRST "Free heap storage" API of the ILE environment) is that the pointer being passed to xdealloc either (1) has already been freed, or (2) the pointer value has changed since it was allocated.

You say that the only difference between this and other programs that don't have this problem is that you have a routine that is calling iconv(), and show a little bit of the code in that routine.

What's interesting about that is that iconv() does manipulate pointers and write data to memory.  If you are using it incorrectly, it could be changing a pointer, or overwriting another spot in the system's memory (which could potentially be changing a pointer, too.)

I would start by removing that iconv() code -- just as a test -- to see if it eliminates the error.  If it does, you know it is the culprit, and then can look at the details in that routine to figure out how you might be using it incorrectly.  (Likely culprits would be that the prototype is coded wrong, you are passing pointers to it wrong, or that the buffer sizes are wrong.)

If disabling that code doesn't solve the problem, then you know that was a red herring, and can look for other causes.  In particular, it'd be good to know what was calling xdealloc at the time the error is happening.

You say it only occurs on V6R1, but I think that's a long shot. While, it's unusual for someone to be using 6.1 today, HTTPAPI has been around for a long time, and at one time it was widely used on 6.1 without having this error.

On 7/2/2024 6:50 PM, James H. H. Lampert via MIDRANGE-L wrote:

I've been using my slightly customized 2012 version of HTTPAPI for years, decades, in fact, without any difficulty. I've had jobs calling it hundreds of times over the course of a single program execution, often multiple times per second, and I've never seen this before.

But now, testing a new application, I'm getting this:

Message ID . . . . . . :   CEE0810


Message . . . . :   The starting address for reallocation is not valid.


Cause . . . . . :   The starting address for reallocation is not valid. The exception occurred in procedure CEEFRST.
Recovery  . . . :   Use an address that was obtained through previous allocation procedures.

Sent from QLEAWI to the XDEALLOC procedure in HTTPUTILR4 of program HTTPAPIR4.

But it's only happening on our V6R1 box. And always on the third iteration of calling the new application.

If I put the same program on our cloud box (V7R5), I can call it over and over again without the problem appearing.

The *only* thing I'm doing in this new application, that I've never done in any previous application, is calling "iconv" directly. What I have is:

   Eval      iconv_t = IconvOpen(%Addr( tocode )
                            : %Addr( fromcode )
                            )

   EVAL      RC = ICONV(ICONV_T:
                        pBUFFY:
                        BUFLEN:
                        pMUFFY:
                        MUFLEN)
   EVAL      RC = ICONV_CLOSE(ICONV_T)

Anybody have any idea what could be going wrong here?

--
JHHL