Hi,
Durk Talsma wrote:
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 ??? ]
If this is a local variable and not huge (have not looked at what
FGATCMain contains, why not make it auto and let it be on the stack?
It'll be destroyed when it goes out of scope, and allocation is just
moving the stack pointer.
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
Cheers
Lou
|
