Hi Fred,
On Wednesday 27 September 2006 22:07, Frederic Bouvier wrote:
> Hi Durk,
>
> I am still unclear about the way to reproduce what you are seeing. The
> aircraft_demo not repeating is only creating a single AI object. Hard to
> see a huge memory leak with just this single occurence. How do you manage
> to have zillions of AI created and destroyed ?
By using the traffic manager, and having a huge test database of traffic.
Unfortunately, I can't redistribute this database (due to licencing issues
with projectai), so it's going to be really difficult for other people to
reproduce.
>
> Yes, but this is a very small leak, only on error.
Yeah, that's what I thought as well, but it might be worth fixing, just to
remove it from the valgrind leak report.
> >
> > SGModelPlacement::~SGModelPlacement ()
> > {
> > [ Shouldn't there be a "delete _location;" location statement here ???
> > ] }
> >
> > N _selector and _position are ssgSharedPointers, and those are not
> > required to
> > be deleted, if I'm correct, but location is a regular class member
> > pointer.
>
> You may have found what you are looking for. There is a SGModelPlacement
> for every AI object created. BTW, I don't see why a pointer is needed here.
> The _location object is created anyway, so it should be simpler to make it
> a regular value member, instead of keeping a reference.
Yeah, that's what I thought initially as well, but it doesn't look like it. I
added the delete statement in the distructor, and still have the leak.
FWIW, I don't believe so strongly that it's actually a leak in the AI system
itself, although the AI system may be causing it. My best lead sofar, is the
fact that I completed two intercontinental flights using the CVS version of
flightgear after I uncommented one line of code in src/Airports/simple.cxx
(line 93: cerr << "Trying to load dynamics for " << _id << endl;)
this this line commented out, I'm seeing huge leaks, but with it activated,
memory use was fairly stable (I commented on this on our off list mailing, at
which point I disregarded it as being highly unlikely). This is a bit
worrysome, as it would indicate that we have a stack corruption somewhere.
Since then, I've rewritten large sections of the traffic manager /
groundnetwork code to use vectors that store pointers to objects instead of
vectors of objects themselves. Since the rewrite, uncommenting the "cerr"
line mentioned above doesn't seem to have an effect anymore, but memory use
keeps increasing.
Another observation is that the increase in memory seems to be unrelated to
the actual loading and unloading of the AIModels. I've been keeping an eye on
the virtual memory footprint using the linux top command, which I ran in a
console overlaying flightgear. In flightgear itself, I was keeping an eye on
model loading using the property browser.
One final observation is that the memory leak is a lot larger during flight
than when I'm leaving the program idling on the runway. It's almost as if
something prevents the scenery tiles from being removed from memory.
So, I'm still puzzled. I'm planning to rewrite the final bits tomorrow or so
(which contains actually the code that triggered my awareness of the leak in
the first place, so hopefully that will expose something.
>
> > plib: src/ssg/ssgLoadAC.cxx: line 943:
> >
> > I believe that there should be a block of code that deallocates the
> > memory that is assigned to mlist[num_materials] at line 292.
> >
> > for (int i = 0; i <= num_materials; i++)
> > {
> > delete mlist[i];
> > }
>
> agreed
>
Okay.
Cheers,
Durk
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
