Re: Memory leak ? [message #5026] |
Mon, 11 September 1995 00:00  |
Frank J. �ynes
Messages: 17 Registered: February 1995
|
Junior Member |
|
|
This was originally sent to comp.sgi.admin/bugs.
I post it here as well - maybe some other
IDL users have experienced similar things.
"Frank J. �ynes" <frank@spacetec.no> wrote:
> I have a strange behav. on my Indigo 2 running IRIX 5.3
> (192 MB RAM)
>
> I run an IDL session which accesses a shared library written in C
> pluss two other small processes doing data input from external devices.
>
> After some time, typically a few hours, the IDL application terminates
> while doing a SPAWN command (i.e. a fork/exec combination),
> and the syslog claims : Out of logical swap space.
>
> The strange thing is as follows:
> The error happens even if we exit the application at regular intervals to
> free memory.
>
> By monitoring the swap space manager we can see that the amount
> of memory reserved by user applications is increased after every
> session of our application. The only way to get it back (?)
> is to reboot the Indigo.
>
> What is happening?
> Where in the world is the memory going?
> Who is reserving it when we are not running ANY user applications?
> except the swap space manager?
>
> Please help me out here, I'm out of ideas!
>
Additional info: The IDL session uses a moving window display,
(compound widget by me) wher I store images of up to
500x20000 rgb pixels. (~ 30 MB). But still, when the
IDL session dies, X should free this memory - right ?
--
/* Frank J. �ynes -------------------- (frank@spacetec.no) */
/* Spacetec a.s */
/* Prestvannveien 38, N-9005 Troms�, Norway */
/* Telephone : +47 77 68 45 00 Telefax: +47 77 65 58 59 */
/* (...with the bravery of being out of range!) */
|
|
|
Re: Memory leak ? [message #5098 is a reply to message #5026] |
Tue, 19 September 1995 00:00  |
Frank J. �ynes
Messages: 17 Registered: February 1995
|
Junior Member |
|
|
nmw@ion.le.ac.uk (Nigel Wade,Physics,3568,,) wrote:
>
[ Quote of my original post deleted...]
>
>
> When you quit IDL what happens to those two small processes which are
> doing data input?
>
> If you do a "ps -el" command to look at everything on the system, does
> any process show up as a memory hog? Look at the SZ:RSS column, the
> first number is the size of the process in 4Kb blocks.
>
> We use IDL extensively on SGI kit and have not come across this problem.
> IDL can be a memory hog, but it does give it back to the system when it is
> exited (at least it always has done for us so far). We are running IRIX 5.2
> though, so there might be a difference there.
>
> --
> Nigel Wade, System Administrator, Ionospheric Physics Group,
> University of Leicester, Leicester, LE1 7RH, UK
> E-mail : nmw@ion.le.ac.uk
> Phone : +44 (0)116 2523568, Fax : +44 (0)116 2523555
>
I got a reply from SGI on my original post, and they say it's
a known bug in IRIX 5.3. Your experience might indicate that the
problem is not present in IRIX 5.2 - if that is the case I will
downgrade our system. I have asked SGI if 5.2 has the same problem,
and I'll post the reply here when it arrives.
Until then I stronly suggest IDL users NOT to upgrade to 5.3
Heres the mail I got from SGI:
>
> Note however that displaying the image with imgview does NOT
> reserve memory between sessions. This might indicate that
> there is a bad combination of a non-robust Xserver and IDL's way
> of using X-resources.
>
> But Martin experienced similar problems without using IDL,
> so: SGI, don't blame it all on RSI, I do believe you play
> a part in this mess too! :-)
I don't blame anyone. Before I go and blame it on bug # 254412
I want to make sure it's not somthing else.
Here is a work around for 254412 that was posted a while back !
Insert the following lines in /usr/bin/X11/X just before the exec to
the Xsgi and Xsgi_d
MALLOC_CONFIG=2:mm_minunmapsize=2097152:mm_szunmapshift=21:m m_minunmapsrch=0\
:mm_xf[0].mm_flindx=8:mm_xf[0].mm_szshft=5:mm_xf[1].mm_flind x=2055\
:mm_xf[1].mm_szshft=9:mm_xf[2].mm_flindx=2065:mm_xf[2].mm_sz shft=20:mm_flsearh=3
0
export MALLOC_CONFIG
Add large amounts of virtual swap.
IT DOES NOT FIX THE PROBLEM !! It prolongs it. We have a patch in the
works being tested at a couple of customers.
The memory is actually not being used, it's not a leak in the traditional
sense, it's more an accounting problem/fragmentation problem that only shows
up with some special sizes and allocation sequences that seem to be more
frequent than when we originally tested it.
Apologies for the inconvienience, it's a top priority problem. I can't
make commitments to this since this problem belongs to someone else and
I cannot speak for them.
--
_ ` _ ` Internationalization R&D
/ \ / / \ /-- /-- /
/ // / / / / / / / Graphics is cool
\_/ \ \_ \/ /_/ /_/ o Internationalization c'est magnifique
/ /
\_/ (415) 390 4387 Opinions mine etc ...
-------
Frank.
--
/* Frank J. �ynes -------------------- (frank@spacetec.no) */
/* Spacetec a.s */
/* Prestvannveien 38, N-9005 Troms�, Norway */
/* Telephone : +47 77 68 45 00 Telefax: +47 77 65 58 59 */
/* (...with the bravery of being out of range!) */
|
|
|