In the release version of DX, all images are cached internally
differently than what you can set with the modules cache pulldown
options. What you must do is set an attribute to turn this off. At
400k per execution--I'd bet this is what you are seeing. Even if you
run with -cache off, it would still cache the images in Image and
Display. You can test to see if this is still the case by placing an
Option before your image and set the attribute "cache" to 0.
David
In-Reply-To: <[EMAIL PROTECTED]>
Hi! I'm the original poster about the possible memory leak issue, and I just
wanted to clarify a few things in response to the other posts on
this topic. I
hope this message gets posted in the right thread...Problems with internal
mail have kept me from receiving the list messages, so I can't
actually "reply"
to the thread.
In response to Richard's post:
> When I run DX on a remote machine (SGI Irix 6.5 with OpenDX in the most
recent case)
> through an X window on my local SGI (with setenv DISPLAY) I have
noticed that
the Xsgi
> process on my local machine (owned by root) grows and grows with
every use of
DX until
> memory is exceeded and very bad things happen (X dies and
sometimes the whole
> machine dies).
An interesting problem, to say the least, but I think what I'm seeing is more
of an OpenDX memory-management issue than a system-level problem. When OpenDX
"crashes" in this case, it only runs up against the dxexec memory limit
(-memory 200) and doesn't free any of that up, so the network won't run. This
is not a case of any single image being too large to run in memory, but a
problem that compounds with each network execution. It's never
crashed X or my
machine...just bumped up against OpenDX's internal memory limit.
Only takes a
disconnect/reconnect server (not reset server) in OpenDX to free up the
memory.
In response to Ballard's post:
> I don't have the seed email but was this user trying to import a
lengthy file
series using
> the Sequencer?
Nope. Just one file, using the sequencer to select data at different
time-steps out of the file.
In response to Suhaib's post:
> The OpenDx/Cygwin version Windows 98? That is a known problem. You
> have right to yell at M$ for selling the gloriously shitty product.
> Win98 itself has memory leak, which gets horrible when an
> X-application (X-server) is running because Win98 tries to be selfish
> and hat to share
> resources with any other server... With X-server trying to share
> Display causes Win98/95 to start eating CPU resources and may once
> in a while will force you to reboot the PC..... because it gets
> horribly slow.
Actually, I was able to create the problem under NT as well. The problem is
not with CPU resources, but memory usage. It seems like OpenDx
isn't releasing
memory somewhere, so eventually it fills up its memory limit
(-memory 200) and
won't release any of it. Nothing effects the system, except the dx network
won't run until you disconnect/reconnect the dxexec to force the release of
memory.
Thanks for the responses! Let's keep at it so we can figure out what's going
on here...
Jeremy Zoss
Southwest Research Institute
(210)522-3089
[EMAIL PROTECTED]
.............................................................................
David L. Thompson The University of Montana
mailto:[EMAIL PROTECTED] Computer Science Department
http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812
Work Phone : (406)257-8530
