Mike: Sorry I wait so long to answer your email. I was debugging an testing to try to find a cure for the patient (as you said) and doing it step by step. Let me first answer your questions about the error: 1. If you run this for the record at 176,677, do you get the error? No. This error happens only when a big amount of information is read. Not always happens at the same record. 2. If you read the first 1000 records without calling getContactInfo, then let it run, do you get the error at 177,677? No. I get it 1000 records or more after the 177,677 3. Does it always crash after running 176,677 iterations regardless of the data you reading? No. It happens at different times, depending the data. 4. If you watch the program running, do you notice anything unusual? Stack growing? Files growing? None of them. There is nothing unusual, stack and files stays the same. I ran it interactive and in batch and the results are the same. 5. Did you dump the program? Program dump listing? Yes I did dump the program, but the only program I can dump is WS.CONTAC and the error happens in the module HTTPUTILR4, which I could'nt dump. The error send me to WS.CONTAC. Now, lets go to the debug steps. 1. I download the beta version of HTTP API library (HTTPAPI Ver1.24beta11 released 2010-09-09) and installed it in LIBHTTPB I just compile my service program for the WS objects to use LIBHTTPB. Then I ran the program and I did NOT get the error. Try batch and iteractive 3 times. It read more than 300,000 records and NO error. 2. We have Fulfillment program that consume different web services: WS.EMAIL and WS.PHONES. And we were having the same problem that the other one (WS.CONTACT). I ran the program with the HTTP beta version and I got the heap memory error. I attached Fulfillment_Email_heap_memory_error_Using_LIBHTTPB The program is a complicate fulfillment process, but I recreate the problem using a test program (TSTPHONES) - the compiled version and the Heap memory error are attached. The 2 compile sources for the consuming Web Services are also attached. 3. I modified the module LIBHTTPB/HTTPUTILR4 where the error happens, and add a call after the pointer is allocated and after the pionter is deallocated. See attached file Call PTRTOHEX in HTTPUTILR4. This program just write the hex value of the pointer in a file. I am sending you also the last records I get for the process. I really do not know what else to do. May be with this information you see something that I cannot see. I appreciate your help Regards, JULIO C. CABRERA Sr. Programmer Analyst, Information Technology Interval International 6262 Sunset Drive * Miami, Florida 33143 305.666.1861, ext. 7287 * direct 305.925.7287 cell 305.928.7925* fax 305.668.3409 Julio.Cabrera@xxxxxxxxxxxxxxxx IntervalWorld.com * ResortDeveloper.com -----Original Message----- From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Mike Krebs Sent: Thursday, February 17, 2011 7:20 PM To: HTTPAPI and FTPAPI Projects Subject: RE: Invalid heap space using HTTPAPI Thanks for finally sending some almost useful information! Make only one change a time and test so we know what eventually cures the patient. You are running an old version. You really should be able to run this (especially in a test environment) with the latest version. As has been pointed out, backwards compatibility is very good. At least run a test WS.CONTACT with the new version so that we know it is a current problem. Download the Beta and install into a different library. Compile and run using the new version. >From limited experience, changing ptr between alloc and dealloc will cause a problem. If that happens, why? Did you dump the program? Program dump listing? Not sure it would help, but can't hurt when debugging. What is the value of "ptr"? Is there a pointer declared in your module WS.CONTACT called "ptr"? Are you using it? I don't think it needs to be there. If not, please delete and retry test. Add some debugging output...print the ptr value at the point where it allocates memory. Print it just before the dealloc. The pointer should be the same. Here is an article that talks about one way to print a pointer http://www.itjungle.com/fhg/fhg110310-story02.html. HTTPAPI is full of pointers and uses arrays of pointers in some places. If you run this for the record at 176,677, do you get the error? If you read the first 1000 records without calling getContactInfo, then let it run, do you get the error at 177,677? In other words, does it always crash after running 176,677 iterations regardless of the data you reading? Or at least within a few records of that? If you watch the program running, do you notice anything unusual? Stack growing? Files growing? Good of you to send a compile listing for the code so we can see the file layouts and other copied information...if want us to try to recreate, we also need just the source without the other stuff and maybe just a bit of knowledge on how to fake it. But try the new version, try the ptr removal, try printing the ptr. Let's see how far we get. > -----Original Message----- > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi- > bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Julio Cabrera > Sent: Thursday, February 17, 2011 11:00 AM > To: HTTPAPI and FTPAPI Projects > Subject: RE: Invalid heap space using HTTPAPI > > Charles: > > > > After a while trying to reproduce the error, I wrote a program > (TSTCONTACT) that reads our member file with almost 5 million records > in > a loop and call my program getContactInfo. After 176,677 records, it > gives the heap memory error: > > > > > > The error happens in the dealloc line (3448): > > > > Program: HTTPAPIR4 Library: LIBHTTP Module: > HTTPUTILR4 > > > 3444 3443 D xdealloc PI > > > 3445 3444 D ptr * > > > 3446 3445 /if defined(TERASPACE) > > > 3447 3446 /else > > > 3448 3447 C dealloc ptr > > > 3449 3448 /endif > > > 3450 3449 C eval ptr = *null > > > 3451 3450 P E > > > 3452 3451 > > > 3453 3452 > > > 3454 3453 > *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 3455 3454 * xrealloc(): re-allocate memory > > > 3456 3455 > *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 3457 3456 P xrealloc B export > > > 3458 3457 D xrealloc PI * > > > > > The http_debug was *ON > > I include here the source of the Test program, The source of the RPG to > consume the Web Service and the txt of the debug. > > I still do not have any clue of what happened. > > I will appreciate if you can give me any idea. > > > > Thank you very much, > > > > > > JULIO C. CABRERA > > Sr. Programmer Analyst, Information Technology > > Interval International > > 6262 Sunset Drive * Miami, Florida 33143 > > 305.666.1861, ext. 7287 * direct 305.925.7287 > > cell 305.928.7925* fax 305.668.3409 > > Julio.Cabrera@xxxxxxxxxxxxxxxx > > > > IntervalWorld.com * ResortDeveloper.com > > > > -----Original Message----- > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx > [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Charles > Wilt > Sent: Friday, January 21, 2011 3:02 PM > To: HTTPAPI and FTPAPI Projects > Subject: Re: Invalid heap space using HTTPAPI > > > > Julio, > > > > Turn debug logging on and post the resulting log.. > > > > http_debug(*ON); > > > > Charles > > > > On Fri, Jan 21, 2011 at 2:42 PM, Julio Cabrera > > <Julio.Cabrera@xxxxxxxxxxxxxxxx> wrote: > > > > > > > > > Gentlemen: > > > > > > > > > I need help with this error. > > > > > > It is happening with an RPG service using HTTPAPI, and normally > > > happens when the web service is called multiple times. > > > > > > > > > [cid:image002.jpg@01CBB979.7E576830] > > > > > > > > > Any help will be very appreciated. > > > > > > > > > Thanks, > > > > > > > > > > > > JULIO C. CABRERA > > > > > > Sr. Programmer Analyst, Information Technology > > > > > > Interval International > > > > > > 6262 Sunset Drive o Miami, Florida 33143 > > > > > > 305.666.1861, ext. 7287 o direct 305.925.7287 > > > > > > cell 305.928.7925 o fax 305.668.3409 > > > > > > [1]Julio.Cabrera@xxxxxxxxxxxxxxxx > > > > > > > > > IntervalWorld.com o ResortDeveloper.com > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > _______ > > > Scanned by IBM Email Security Management Services powered by > > > MessageLabs. For more information please visit > http://www.ers.ibm.com > > > > ______________________________________________________________________ > > > _______ > > > > > > References > > > > > > 1. mailto:Julio.Cabrera@xxxxxxxxxxxxxxxx > > > > > > > ----------------------------------------------------------------------- > > > This is the FTPAPI mailing list. To unsubscribe, please go to: > > > http://www.scottklement.com/mailman/listinfo/ftpapi > > > > ----------------------------------------------------------------------- > > > > > > > > ----------------------------------------------------------------------- > > This is the FTPAPI mailing list. To unsubscribe, please go to: > > http://www.scottklement.com/mailman/listinfo/ftpapi > > ----------------------------------------------------------------------- > > > > _______________________________________________________________________ > _ > _____ > > Scanned by IBM Email Security Management Services powered by > MessageLabs. > > _______________________________________________________________________ > _ > _____ > > > _______________________________________________________________________ > ______ > Scanned by IBM Email Security Management Services powered by > MessageLabs. For more information please visit http://www.ers.ibm.com > _______________________________________________________________________ > ______ ----------------------------------------------------------------------- This is the FTPAPI mailing list. To unsubscribe, please go to: http://www.scottklement.com/mailman/listinfo/ftpapi ----------------------------------------------------------------------- ________________________________________________________________________ _____ Scanned by IBM Email Security Management Services powered by MessageLabs. ________________________________________________________________________ _____ _____________________________________________________________________________ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.com _____________________________________________________________________________
Attachment:
Fulfillment_Email_heap_memory_error_Using_LIBHTTPB.doc
Description: Fulfillment_Email_heap_memory_error_Using_LIBHTTPB.doc
ÿþ 5 7 2 2 W D S V 5 R 4 M 0 0 6 0 2 1 0 R N I B M I L E R P G I I E R 0 0 V W / T S T P H O N E S I I M I A D E V 0 3 / 0 1 / 1 1 1 4 : 4 1 : 3 4 P a g e 1 C o m m a n d . . . . . . . . . . . . : C R T R P G M O D I s s u e d b y . . . . . . . . . . : J C A B R E R A M o d u l e . . . . . . . . . . . . . : T S T P H O N E S L i b r a r y . . . . . . . . . . . : I I E R 0 0 V W T e x t ' d e s c r i p t i o n ' . . . . . . . : * S R C M B R T X T S o u r c e M e m b e r . . . . . . . . . : T S T P H O N E S S o u r c e F i l e . . . . . . . . . . : Q R P G M O D L i b r a r y . . . . . . . . . . . : I I E R 0 0 V W C C S I D . . . . . . . . . . . . : 3 7 T e x t ' d e s c r i p t i o n ' . . . . . . . : T e s t B a s i c C o n t a c t W e b S e r v i c e L a s t C h a n g e . . . . . . . . . . : 0 2 / 2 5 / 1 1 0 9 : 1 4 : 3 8 G e n e r a t i o n s e v e r i t y l e v e l . . . : 1 0 C o m p i l e r o p t i o n s . . . . . . . . : * X R E F * G E N * N O S E C L V L * S H O W C P Y * E X P D D S * E X T * N O S H O W S K P * N O S R C S T M T * D E B U G I O * N O E V E N T F D e b u g g i n g v i e w s . . . . . . . . : * S O U R C E O u t p u t . . . . . . . . . . . . . : * P R I N T O p t i m i z a t i o n l e v e l . . . . . . . : * N O N E S o u r c e l i s t i n g i n d e n t a t i o n . . . : * N O N E T y p e c o n v e r s i o n o p t i o n s . . . . : * N O N E S o r t s e q u e n c e . . . . . . . . . : * H E X L a n g u a g e i d e n t i f i e r . . . . . . : * J O B R U N R e p l a c e m o d u l e . . . . . . . . . : * Y E S A u t h o r i t y . . . . . . . . . . . : * L I B C R T A U T T r u n c a t e n u m e r i c . . . . . . . . : * Y E S F i x n u m e r i c . . . . . . . . . . : * Z O N E D T a r g e t r e l e a s e . . . . . . . . . : * C U R R E N T A l l o w n u l l v a l u e s . . . . . . . : * N O B i n d i n g d i r e c t o r y . . . . . . . : * N O N E D e f i n e c o n d i t i o n n a m e s . . . . . : * N O N E E n a b l e p e r f o r m a n c e c o l l e c t i o n . : * P E P P r o f i l i n g d a t a . . . . . . . . . : * N O C O L L i c e n s e d I n t e r n a l C o d e o p t i o n s . : G e n e r a t e p r o g r a m i n t e r f a c e . . . : * N O I n c l u d e d i r e c t o r y . . . . . . . : P r e p r o c e s s o r o p t i o n s . . . . . . : * N O N E 5 7 2 2 W D S V 5 R 4 M 0 0 6 0 2 1 0 R N I B M I L E R P G I I E R 0 0 V W / T S T P H O N E S I I M I A D E V 0 3 / 0 1 / 1 1 1 4 : 4 1 : 3 4 P a g e 2 L i n e <