James,
When any of those CEExxxx errors pertaining to dynamic storage in the ILE heap occur, use the following tools and approach to assist in isolating the probable cause -- use the ILE heap debugger.
See:
https://www.ibm.com/support/pages/system/files/inline-files/i-mysterious_application-pdf.pdf
Hope that helps,
Mark S. Waterbury
On Wednesday, July 3, 2024 at 01:26:19 PM EDT, James H. H. Lampert via MIDRANGE-L <midrange-l@xxxxxxxxxxxxxxxxxx> wrote:
On 7/2/24 9:26 PM, Scott Klement wrote:
That error means that it is trying to free up memory that isn't
allocated.
. . .
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.
. . .
I would start by removing that iconv() code -- just as a test -- to see
if it eliminates the error.
. . .
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.
Well, I now know what it isn't: it isn't my usage of iconv. I switched
the code over to call your HTTP_xlatep instead, and it's still crapping
out the third time the program is called from the command line.
What's particularly odd is that the program exits with LR set. Now most
of my other applications that use HTTPAPI don't just do a single call,
and then exit. They do dozens, or even hundreds of calls. So I tried
putting the part of the application that makes the call into a do-loop,
so it would get called three times.
No change. The third time http_url_get_raw gets called, I get "CEE0810
unmonitored by HTTPAPIR4 . . . ."
Taking out the loop, and doing a RCLRSC between calls to my program, the
same results.
FWIW, I *never* call XDEALLOC directly. As with all my past HTTPAPI
applications, I use a global large static variable as my buffer:
D DS
D BUFFY 1 500000A
D BUFFA 1 500000A DIM(500000)
and a very simple buffer-filling procedure.
**** Breakthrough! ****
I didn't even *think* to call the application again after it had blown
up, instead of signing off and signing back on. I just did so, expecting
it to simply blow up again. It didn't. Instead, it gave me a repeating
pattern of two good web service calls, and a CEE0810. Over and over again.
Is there maybe something I should look for in the http_debug.txt? All I
see is that a failed call is 202 lines, ending with
SetError() #13: HTTP/1.1 200 OK
recvresp(): end with 200
recvdoc parms: identity 3022
but a successful one is 208 lines, ending with
SetError() #13: HTTP/1.1 200 OK
recvresp(): end with 200
recvdoc parms: identity 3022
header_load_cookies() entered
recvdoc(): entered
SetError() #0:
{ "results" : [ . . .
http_close(): entered
I do note that the additional lines at the end only account for 5 of the
6 additional lines. I wonder where the other line is . . .
I probably need to knock off the active testing of this application for
today: the web service I'm calling is the Google Geocoding service,
"maps.googleapis.com/maps/api/geocode/json?address= . . . ," and we only
get a finite number of calls per day on our key.
--
JHHL
midrange.com
