sleyzerzon / soar

Automatically exported from code.google.com/p/soar
1 stars 0 forks source link

memory leaks with remote connection #44

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Description From Bob Marinier 2008-12-16 16:40:37 (-) [reply]
To reproduce:

0) Start with a debug or debug scu build.
1) Open two command prompt windows in the SoarLibrary/bin directory.
2) In the first one, do "java -jar SoarJavaDebugger.jar".
3) In the second one, do "java -jar SoarJavaDebugger.jar -remote".
4) Close the first debugger. This should close both debugger windows 
(unless
you've changed the default debugger settings).

Tons of memory leaks are reported by the second debugger (the first has 
none).
Many of them appear to be related to ElementXML.

Note that, to debug leaks in Java, you can set a memory leak breakpoint 
near
the bottom of sml_ClientInterface.i (in the Resources Files folder of the
ClientSMLJava project in Visual Studio). But this probably has nothing to 
do
with Java, so it might be worth the effort to reproduce it in C++.
------- Comment #1 From Jonathan Voigt 2009-01-05 14:52:00 (-) [reply] ----

---
I am able to reproduce the problem as you described.

In an attempt to reproduce this without Java in the loop, I created a 
remote
flag to TestCLI so that it can use a remote kernel. I modified the Tests
executable (simple listener) to dump memory leaks. Connecting the TestCLI 
to
that Tests simple listener and closing the simple listener does not produce
memory leaks.
------- Comment #2 From Bob Marinier 2009-01-05 20:14:12 (-) [reply] ------
-
It sounds like it's Java-specific, in which case it may be that ElementXML 
(or
something related) isn't SWIG'd quite right. It would be good to determine 
if
this is only a shutdown issue, or if these leaks accumulate during a run. 
If
it's just a shutdown issue, then I'm much less concerned about it. If it's 
an
ongoing issue, it's probably an ownership issue in SWIG. That is, SWIG may 
need
to be told that the Java object "owns" the underlying C++ object, so that 
when
the Java object goes away, the C++ object does too. I think this is the
%newobject syntax that exists for other things in sml_ClientInterface.i 
already
(so we may need to add similar things for whatever returns ElementXML 
objects).

Original issue reported on code.google.com by voigtjr@gmail.com on 23 Jul 2009 at 5:07

GoogleCodeExporter commented 9 years ago

Original comment by voigtjr@gmail.com on 23 Jul 2009 at 5:29

GoogleCodeExporter commented 9 years ago

Original comment by voigtjr@gmail.com on 23 Feb 2010 at 7:44