On Wednesday 27 September 2006 18:28, Andy Ross wrote:
> Finally, please make sure you remove *all* traces of FlightGear and
> SimGear from you system before doing a
>
> Durk Talsma wrote:
> > Lou Sanchez-Chopitea wrote:
> > > I have assembled a box based on a Tyan MB with two Athlon MP 2000+
> > > with 2GB of ram, running Fedora Core 5. I get segfaults in both
> > > the yum installed FG and a local version built from sources. Has
> > > anyone encountered problems (or success) on dual processor
> > > systems?
> >
> > About two weeks ago, I posted a valgrind error log on the list, which
> > you can find here: http://durktalsma.xs4all.nl/valgrind.log
>
> Note that both the X11 libraries and NVIDIA libGL implementation
> generate a huge stream of (apparently benign) uninitialized memory
> reads. You will need to filter them out if you want to get any use
> out of valgrind. But the general answer to your question is no:
> because of FlightGear's interactive nature and the performance hit
> from running under valgrind, we don't tend to run it on the fgfs
> binary*. So there are almost certainly some good bugs living in there
> for someone with the energy to find them.
>
FWIW, I'm currently investigating a huge memory problem that was exposed by
the new AI code (although I'm still not sure it is causing it). When I'm
running with AI/traffic manager enabled, flightGear leaks about 5 MB a minute
on my system. Without AI it runs stable. This problem first appeared after I
added the ground network distance monitoring AI part, but since I don't
explicitly allocate or deallocate memory, I can hardly see that this new code
is causing it. (I'm just using stl vectors, so memory allocation is done
automatically.
In the mean time, I did investigate a few potential other memory leaks. I've
listed those I found below. One tiny leak is in FlightGear, one is in
SimGear, and one in plib's ac model loader.
Please comment if my assumptions listed below are not correct. Otherwise, I
ll go ahead and fix these shortly.
Cheers,
Durk
FlightGear: src/Main/fg_io.cxx: line 110.
if ( protocol == "atcsim" ) {
FGATCMain *atcsim = new FGATCMain;
atcsim->set_hz( 30 );
if ( tokens.size() != 6 ) {
SG_LOG( SG_IO, SG_ALERT, "Usage: --atcsim=[no-]pedals,"
<< "input0_config,input1_config,"
<< "output0_config,output1_config,file.nas" );
[ Shouldn't there be "delete atcsim;" here before
returning ??? ]
return NULL;
}
SimGear: simgear/scene/model/placement.cxx: line
SGModelPlacement::SGModelPlacement ()
: _lon_deg(0),
_lat_deg(0),
_elev_ft(0),
_roll_deg(0),
_pitch_deg(0),
_heading_deg(0),
_selector(new ssgSelector),
_position(new ssgPlacementTransform),
_location(new SGLocation)
{
}
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.
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];
}
-------------------------------------------------------------------------
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
