Re: Help with Error -4518

In <2etm1sINNo8f@emory.mathcs.emory.edu> johnl@informix.com (Jonathan Leffler) writes: >}From: marchett@eng.gtefsd.com (Tony Marchetti) >}I was wondering if anyone can help me with a problem I am having when >}creating a report using INFORMIX-4GL. I am receiving error number -4518 - >}"The 4GL program cannot allocate any more space for temporary string >}storage" during executing of my application. Has anyone had any >}experience with this problem. I have contacted my local INFORMIX office >}and received some input to what is going on and why, but no way to solve >}the problem to date. >You have my sympathy. However, you will find that you have one of the >listed statement types somewhere in your program, and this will be the >cause of your trouble. Speaking from considerable experience, it can be >the very devil of a job to find the problem -- it's the sort of job I >least enjoy dealing with. However, on every occasion except one, it has >proved possible to eliminate the error by being excruciatingly careful >with these statements. Er, I _really_ hate to differ with you on this, but I ran into -4518 so many times (esp. in one ~15,000 line application) that I feel confident saying this is not so. There are _many_ ways to hit -4518, as the tech. support articles I was faxed indicate; I found a new one myself involving clipping. I also found one that was caused by *none* of the known causes, but was somewhere in the 15k-lines of code (even after *every* line was checked several times for offense). [Thinking back, it may have been the 'return' in the report that was at the root of it.] Our solution was to replace the fglalloc functions with ones that calls malloc, under, unfortunately, non-disclosure (and non-support-thereof) terms. We still have a few calls to acdealloc() sprinkled in the code where we *know* the temp string space must be empty (but wasn't being freed); now harmless, just there to prevent leaks. Nonetheless, users with -4518's should start with your most useful -4518 error library, to help determine where the error lies [and the routine to deallocate the TSS if you're confident it should be empty]. (I'm surprised you didn't mention your own handiwork! Such modesty. Should be in the archives.) >The good news is that version 4.12 of I4GL does not generate error >-4518, period. Hallelujah! Does this mean someone did the extraordinarily trivial and correct (IMHO) fix of calling malloc() instead of using the silly 10x512 chunks? (Though malloc() could still exhaust memory, so presumably some error is generated when this happens, yes?) -- Andrew Burt aburt@du.edu "But if he was dying he wouldn't bother to carve "Aaaaargh", he'd just say it."