STORAGE Errors

STORAGE Errors

[ericm]

I have 4 very large ADA program that uses X/Motif as a GUI interface.  
These programs all run in the background at the same time on a HP9000 755 
with 128Meg.

My problem is that after a while of processing lists and displays I tend 
to get storage exceptions that usually freeze the process.  I've checked 
and all the linked lists are deallocated when they are not being used and 
all motif windows are destroyed when they are unmapped.  Does anyone have 
any information on STORAGE Errors or any suggestions on this particular 
problem.

Thanks in advance.

Re: STORAGE Errors

[Mats Weber]

>My problem is that after a while of processing lists and displays I tend 
>to get storage exceptions that usually freeze the process.  I've checked 
>and all the linked lists are deallocated when they are not being used and 
>all motif windows are destroyed when they are unmapped.  Does anyone have 
>any information on STORAGE Errors or any suggestions on this particular 
>problem.

First check that your program is not constantly eating memory while it
executes. If it does, it has a memory leak. Memory leaks are not
necessarilly your fault: the X11 libs you're using might leak, or the
compiler might fail to deallocate some temporary memory (I've seen this
happen).

Another cause for storage_error in some implementations is an access
violation (access to a memory address that you are not allowed to
read/write) or erroneous usage of the memory allocator, such as
deallocating the same object more than once (the standard recommends
Program_Error, but some implementations do raise Storage_Error).

Good Luck

--Mats

Re: STORAGE Errors

[Ted Dennison]

ericm@genesis.ac3i.dseg.ti.com wrote:
> 
> I have 4 very large ADA program that uses X/Motif as a GUI interface.
> These programs all run in the background at the same time on a HP9000 755
> with 128Meg.
> 
> My problem is that after a while of processing lists and displays I tend
> to get storage exceptions that usually freeze the process.  I've checked
> and all the linked lists are deallocated when they are not being used and
> all motif windows are destroyed when they are unmapped.  Does anyone have
> any information on STORAGE Errors or any suggestions on this particular
> problem.

X and Motif have a reputation for leaking memory like a sieve. I'd try to
localize the problem if I were you.

We had someone here who had the same problem with VADS's X/Motif bindings
on that platform. I seem to remember that he tracked down some rather nasty
leaks in the Ada Motif list bindings. Once he worked around those, he was
still getting a leak, but it was more of a "trickle". I suspect the 
culprit for that is Motif itself. But his application only needs to run for
at most a couple of hours, so he had slowed it down enough to quit worrying
about it.

You might also want to check with your binding's vendor. They make have some
known bugs. That could save you some valuable time.


-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: STORAGE Errors

[Michael E. Wesolowski]

On Thu, 22 Aug 1996 ericm@genesis.ac3i.dseg.ti.com wrote:

> My problem is that after a while of processing lists and displays I tend 
> to get storage exceptions that usually freeze the process.  I've checked 
> and all the linked lists are deallocated when they are not being used and 
> all motif windows are destroyed when they are unmapped.  Does anyone have 
> any information on STORAGE Errors or any suggestions on this particular 
> problem.

If you are getting a storage error, you may have a memory leak. 

Although your code may be fine, other stuff you link in may not be (it
happened to me recently. The project I'm working on links in vendor code
which had a memory leak. To confuse the issue further, the problem
appeared on only one platform [this particular application ran on three
different platforms]).

The way we found the source of teh leak was to use the "malloc debug"
package provided with the VADS compiler that we are using. It allowed us
to profile heap
usage and deduce what was happening knowing what we were doing. We were
then able to go to the vendor with our conclusions and get a speedy fix.

More detail available if you want them. 
---------------------------------------------------------------------

Michael Wesolowski (mewesolo@freenet.calgary.ab.ca)