[Flightgear-devel] Memory leak fixes for random vegetation and buildings
Hi All, I've just pushed two fixes for possible memory leaks in random vegetation and buildings. One was noticed by valgrind, the other is speculative, to make use of osg::ref_ptrs where possible. At the same time, I've changed the random vegetation so that the normals are bound per-vertex rather than overall. Please let me know if you see any perf or memory impact. I'm hoping that this will reduce the memory occupancy over long flights. Note that the random buildings in particular still have a large memory footprint. These fixes do no address that. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak in latest sound code?
On Tue, 2011-12-06 at 20:05 +0100, Durk Talsma wrote: Hi All, Using the following command line options, I am seeing a dramatic increase in memory consumption, in just a few seconds, up to the point where flightgear becomes unusable (top reporting that flightgear uses more than 85% of memory on a 4 GiG linux box): fgfs --timeofday=dawn --airport=SAVE --aircraft=dc-3 Running a comparable session using the fokker50 instead of the dc-3 shows a stable memory footprint of about 25% (as reported by the linux top command). While running the dc-3 I see many warnings printed that stereo sound files are not supported, and after disabling the master sound channel (GUI: File-Sound-uncheck master sound), the memory footprint becomes stable again. Given that I don't see this behavior using the fokker50, makes me suspect it's something specific to the dc-3, and probably related to the erroneous stereo file. Is this possible? OK, this is fixed in simgear. I also adjusted the code to show the message only once. Erik -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak in latest sound code?
OK, this is fixed in simgear. I also adjusted the code to show the message only once. Thanks Erik! I'll give it a go tonight. d. -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory leak in latest sound code?
Hi All, Using the following command line options, I am seeing a dramatic increase in memory consumption, in just a few seconds, up to the point where flightgear becomes unusable (top reporting that flightgear uses more than 85% of memory on a 4 GiG linux box): fgfs --timeofday=dawn --airport=SAVE --aircraft=dc-3 Running a comparable session using the fokker50 instead of the dc-3 shows a stable memory footprint of about 25% (as reported by the linux top command). While running the dc-3 I see many warnings printed that stereo sound files are not supported, and after disabling the master sound channel (GUI: File-Sound-uncheck master sound), the memory footprint becomes stable again. Given that I don't see this behavior using the fokker50, makes me suspect it's something specific to the dc-3, and probably related to the erroneous stereo file. Is this possible? Cheers, Durk -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory leak in latest sound code?
Hi All, Using the following command line options, I am seeing a dramatic increase in memory consumption, in just a few seconds, up to the point where flightgear becomes unusable (top reporting that flightgear uses more than 85% of memory on a 4 GiG linux box): fgfs --timeofday=dawn --airport=SAVE --aircraft=dc-3 Running a comparable session using the fokker50 instead of the dc-3 shows a stable memory footprint of about 25% (as reported by the linux top command). While running the dc-3 I see many warnings printed that stereo sound files are not supported, and after disabling the master sound channel (GUI: File-Sound-uncheck master sound), the memory footprint becomes stable again. Given that I don't see this behavior using the fokker50, makes me suspect it's something specific to the dc-3, and probably related to the erroneous stereo file. Is this possible? Cheers, Durk -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak in latest sound code?
Me too with the f-14b as of today or very recently. On Tue, Dec 6, 2011 at 1:00 PM, Durk Talsma wrote: Hi All, Using the following command line options, I am seeing a dramatic increase in memory consumption, in just a few seconds, up to the point where flightgear becomes unusable (top reporting that flightgear uses more than 85% of memory on a 4 GiG linux box): fgfs --timeofday=dawn --airport=SAVE --aircraft=dc-3 Running a comparable session using the fokker50 instead of the dc-3 shows a stable memory footprint of about 25% (as reported by the linux top command). While running the dc-3 I see many warnings printed that stereo sound files are not supported, and after disabling the master sound channel (GUI: File-Sound-uncheck master sound), the memory footprint becomes stable again. Given that I don't see this behavior using the fokker50, makes me suspect it's something specific to the dc-3, and probably related to the erroneous stereo file. Is this possible? Cheers, Durk -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak in latest sound code?
On Tue, 6 Dec 2011 20:00:42 +0100 Durk Talsma durk.tal...@ugent.be wrote: Hi All, Using the following command line options, I am seeing a dramatic increase in memory consumption, in just a few seconds, up to the point where flightgear becomes unusable (top reporting that flightgear uses more than 85% of memory on a 4 GiG linux box): fgfs --timeofday=dawn --airport=SAVE --aircraft=dc-3 Running a comparable session using the fokker50 instead of the dc-3 shows a stable memory footprint of about 25% (as reported by the linux top command). While running the dc-3 I see many warnings printed that stereo sound files are not supported, and after disabling the master sound channel (GUI: File-Sound-uncheck master sound), the memory footprint becomes stable again. Given that I don't see this behavior using the fokker50, makes me suspect it's something specific to the dc-3, and probably related to the erroneous stereo file. Is this possible? I noticed a git commit to simgear recently that also meantioned this behaviour (and claimed to be a fix for it). Best practice is off cource to convert stereo wave files to mono. This will also make them useable in 3d space (otherwise they just get rendered as stereo files, without positional information). I'll investigate tomorrow. Erik -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory leak head branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Markus Zojer wrote: | Hi everyone, | | A memory leak ran over me with fg + sg cvs/OSG 2.3.1 using SDL/osgviewer. | | It accumulates about 200mb/ 10 min, until your memory and swap is full, | despite the 15mb/10min of the unleaked version. | | I narrowed the search: with fg + sg cvs from 5th of jan. there is no | leak, while it is present in the cvs of the 7th, so I suspect the faulty | code could have been added on the 6th, possibly in simgear cvs. | | Any clues? Yes, your detailed report points the finger at the new random object code. I checked in a fix that fixes several leaks; please test again and see if the problem is still there. Thanks, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHjxKweDhWHdXrDRURAtupAKCyouR0lTk3zy+hP7kx68z1OEXJcwCgmg+M j53HPbSL71QoasIf6Kd4lzw= =iVKm -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] memory leak head branch
Hi everyone, A memory leak ran over me with fg + sg cvs/OSG 2.3.1 using SDL/osgviewer. It accumulates about 200mb/ 10 min, until your memory and swap is full, despite the 15mb/10min of the unleaked version. I narrowed the search: with fg + sg cvs from 5th of jan. there is no leak, while it is present in the cvs of the 7th, so I suspect the faulty code could have been added on the 6th, possibly in simgear cvs. Any clues? markus - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory leak (was: bug roundup)
On 02/05/2007 07:55 PM, Durk Talsma wrote: I've never seen any memory leaks that bad. Could you please try it with the simulator /paused/? A rather steady leak of 2 meg per minute is observed chez moi during pause, no matter whether the aircraft is aloft or parked on the ground. Vastly less leakage (two orders of magnitude less, possibly zero) is observed when the simulator is not paused, and the aircraft is simply sitting on the ground with the parking brake set. This bug has been observed in multiple versions of fgfs, including one compiled back in May, 2006 as well as the most current CVS version. This is 100% reproducible chez moi, with a ATI RV350 [Mobility Radeon 9600 M10] chipset and the ati-fglrx driver. The leak is observed whether or not OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory leak
John Denker wrote: On 02/05/2007 07:55 PM, Durk Talsma wrote: I've never seen any memory leaks that bad. Could you please try it with the simulator /paused/? A rather steady leak of 2 meg per minute is observed chez moi during pause, no matter whether the aircraft is aloft or parked on the ground. Vastly less leakage (two orders of magnitude less, possibly zero) is observed when the simulator is not paused, and the aircraft is simply sitting on the ground with the parking brake set. This bug has been observed in multiple versions of fgfs, including one compiled back in May, 2006 as well as the most current CVS version. This is 100% reproducible chez moi, with a ATI RV350 [Mobility Radeon 9600 M10] chipset and the ati-fglrx driver. The leak is observed whether or not OSG_GL_EXTENSION_DISABLE=ATI:GL_SGIS_generate_mipmap is set. Could somebody please try this? I would like to try to replicate it myself, but I'm currently far away from home, without easy access to a computer powerful enough to run a recent version of FlightGear. Cheers, Durk - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] memory leak
My version of fgfs has a rather large memory leak. If I leave the thing parked after a flight, brakes on, simulator paused, it will gobble up about 3 gigabytes of virtual memory overnight. (In contrast, it's only a little over 500 meg after a few minutes of flight.) I'm running the version of fgfs that is bundled with the current Debian etch distribution. The fgfs binary is dated May 17 2006 if that means anything. I'm using it with the /data/ from cvs. - 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.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
From: Torsten Dreyer [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Memory leak Date: Wed, 21 Jun 2006 08:58:31 +0200 If this is of any help - starting with the ufo on the ground and sitting there (no movement, controls untouched) the memory grows at a rate of approx. 50kB-100kB per second. Monitored for about a minute. .fgfsrc is blank and all rendering options unchecked, except display framerate This is on a linux-box monitored with ksysguard. Since the ufo has no panel at all, this is either another leak or the problem is not bound to the 2d panel? Torsten I noticed the same on 098a/win me then I looked at the xml files... the ufo-set.xml file has panel visibilty set to false and there in is no panel specified either in the ufo-set.xml or /model/ufo.xml does this mean that with the ufo, a 2-d panel is loaded but not shown till shftp toggles it on because it is certainly a 2-d panel that shows when shiftp is pressed The ufo-set files lists the author as ET... is this a case of ... ET call Torsten ? ;-) :-D ene _ Find the coolest online games @ http://xtramsn.co.nz/gaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Wednesday 21 June 2006 08:35, dene maxwell wrote: From: Torsten Dreyer [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Memory leak Date: Wed, 21 Jun 2006 08:58:31 +0200 If this is of any help - starting with the ufo on the ground and sitting there (no movement, controls untouched) the memory grows at a rate of approx. 50kB-100kB per second. Monitored for about a minute. .fgfsrc is blank and all rendering options unchecked, except display framerate This is on a linux-box monitored with ksysguard. Since the ufo has no panel at all, this is either another leak or the problem is not bound to the 2d panel? Torsten I noticed the same on 098a/win me then I looked at the xml files... the ufo-set.xml file has panel visibilty set to false and there in is no panel specified either in the ufo-set.xml or /model/ufo.xml does this mean that with the ufo, a 2-d panel is loaded but not shown till shftp toggles it on because it is certainly a 2-d panel that shows when shiftp is pressed The ufo-set files lists the author as ET... is this a case of ... ET call Torsten ? ;-) :-D ene I don't think that just a minute is really long enough to tell. You get some growth as things like the AI a/c get loaded and start flying about so FG legitimately grabs more memory in the few minutes after start-up. The 2D panel you see with the ufo is the C-172 2D panel, which is the default if none is specified. LeeE All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
Dave Perry I have had lock-ups on longer X-C flights with the pa24-250 recently that could be from a memory leak. So I used the system monitor to check on VM growth. The only 2D pannel used in the pa24-250 is the radio stack. So I tried commenting out various components of the radio stack in the file radio-panel.xml. If I comment all the radio stack in this file, the memory leak is gone. I did not try all combinations, but the leak rate seems to get greater the more radios are not commented out. I do not remeber this occurring even on very long X-C flights when I first submitted the pa24-250. System info FC4 Linux updated with yum update last Saturday Plib, SimGear, fgfs source, and base all updated from CVS on Saturday also. AMD Athlon XP 3200+ with 512 MB RAM Nvidia GeForce 7800 GS OC with 256MB GDDR3 Hmm - it's beginning to look as if this problem is long-standing. It only seems to involve 2d panels: those ac with pure 3d panels are unaffected. Some 3d panels have 2d elements - these are also affected. Linux and Windows both seem to be affected, but Melchior cannot reproduce the memory leak on his set-up. A date when you first noticed this effect would perhaps help in tracking it down. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
Hi, I have always noticed this, have commented on it over the last 18 months or so since I first started with FG after about 2.5 hours fps dropped to 1fps and aircraft eventually crashed... I first noticed this on the PA28-161 as it was my aircraft of choice then latterly on the A10-2D... I recently did a long haul using way points from NZWN-NZAA via NZPP, NZPM, NZNP, NZHN and the C172 held up for 3.5 hours...same problem ...low FPS and loss of control even on AP(waypoints)... ...hope this is helpful and not miss-leading. :-D ene From: Vivian Meazza [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: 'FlightGear developers discussions' flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Memory leak Date: Tue, 20 Jun 2006 08:19:03 +0100 Dave Perry I have had lock-ups on longer X-C flights with the pa24-250 recently that could be from a memory leak. So I used the system monitor to check on VM growth. The only 2D pannel used in the pa24-250 is the radio stack. So I tried commenting out various components of the radio stack in the file radio-panel.xml. If I comment all the radio stack in this file, the memory leak is gone. I did not try all combinations, but the leak rate seems to get greater the more radios are not commented out. I do not remeber this occurring even on very long X-C flights when I first submitted the pa24-250. System info FC4 Linux updated with yum update last Saturday Plib, SimGear, fgfs source, and base all updated from CVS on Saturday also. AMD Athlon XP 3200+ with 512 MB RAM Nvidia GeForce 7800 GS OC with 256MB GDDR3 Hmm - it's beginning to look as if this problem is long-standing. It only seems to involve 2d panels: those ac with pure 3d panels are unaffected. Some 3d panels have 2d elements - these are also affected. Linux and Windows both seem to be affected, but Melchior cannot reproduce the memory leak on his set-up. A date when you first noticed this effect would perhaps help in tracking it down. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need a new job? Check out XtraMSN Careers http://xtramsn.co.nz/careers ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Tuesday 20 June 2006 08:19, Vivian Meazza wrote: Dave Perry I have had lock-ups on longer X-C flights with the pa24-250 recently that could be from a memory leak. So I used the system monitor to check on VM growth. The only 2D pannel used in the pa24-250 is the radio stack. So I tried commenting out various components of the radio stack in the file radio-panel.xml. If I comment all the radio stack in this file, the memory leak is gone. I did not try all combinations, but the leak rate seems to get greater the more radios are not commented out. I do not remeber this occurring even on very long X-C flights when I first submitted the pa24-250. System info FC4 Linux updated with yum update last Saturday Plib, SimGear, fgfs source, and base all updated from CVS on Saturday also. AMD Athlon XP 3200+ with 512 MB RAM Nvidia GeForce 7800 GS OC with 256MB GDDR3 Hmm - it's beginning to look as if this problem is long-standing. It only seems to involve 2d panels: those ac with pure 3d panels are unaffected. Some 3d panels have 2d elements - these are also affected. Linux and Windows both seem to be affected, but Melchior cannot reproduce the memory leak on his set-up. A date when you first noticed this effect would perhaps help in tracking it down. Vivian Yeah - it could be long-standing. I hadn't done a long flight, long enough to use all my VM for a long time, but I do remember occasions of FG bogging down like this from quite a while back. Can't be sure of how long ago though:( I always have the 'mini' panel open but I don't include radio instruments on them so I don't think it is _just_ due to the radio instruments. I'll try a completely blank panel to see if the problem is due to the instruments or the panel itself. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Sun, 2006-06-18 at 16:44 +0100, Vivian Meazza wrote: Lee Elliott wrote On Saturday 17 June 2006 20:18, Vivian Meazza wrote: Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian Sounds very much like it - I first noticed under the same conditions. I'll try cvs with Melchior's latest update, but a bit later - I'm of to a birthday now. I have now completed a bit more testing using the Seahawk using cvs-head of this am on Windows XP. With the 3D panel there is no memory leak. When I switch to the 2d panel on the fly, the memory leak starts. When I switch back to 3d, the leak stops. This can be repeated at will. Vivian I can confirm the same thing on AMD64 running Linux (2.6.15 kernel). However, I would need to wait a while to consume the VM on this machine before it crashes due to lack of memory (w/ 2gig of swap). George ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
It was suggested on IRC that I might like to do memory leak tests on 098a/Win Meresults; *Start***Finish* Plane: Time:Mem: Time: Mem: PA28-161 12:34NZST 548.4M13:03 558.4M Hunter 13:04NZST 543.4M13:35 552.3M 172-3d 13:45NZST 542.4M14:12 533.7M hope these figures are useful to someone. :-D ene _ Check out the latest video @ http://xtra.co.nz/streaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
I have had lock-ups on longer X-C flights with the pa24-250 recently that could be from a memory leak. So I used the system monitor to check on VM growth. The only 2D pannel used in the pa24-250 is the radio stack. So I tried commenting out various components of the radio stack in the file radio-panel.xml. If I comment all the radio stack in this file, the memory leak is gone. I did not try all combinations, but the leak rate seems to get greater the more radios are not commented out. I do not remeber this occurring even on very long X-C flights when I first submitted the pa24-250. System info FC4 Linux updated with yum update last Saturday Plib, SimGear, fgfs source, and base all updated from CVS on Saturday also. AMD Athlon XP 3200+ with 512 MB RAM Nvidia GeForce 7800 GS OC with 256MB GDDR3 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
Lee Elliott wrote On Saturday 17 June 2006 20:18, Vivian Meazza wrote: Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian Sounds very much like it - I first noticed under the same conditions. I'll try cvs with Melchior's latest update, but a bit later - I'm of to a birthday now. I have now completed a bit more testing using the Seahawk using cvs-head of this am on Windows XP. With the 3D panel there is no memory leak. When I switch to the 2d panel on the fly, the memory leak starts. When I switch back to 3d, the leak stops. This can be repeated at will. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
* Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
* Vivian Meazza -- Saturday 17 June 2006 21:18: I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. The only recent change to the 2D panel was IIRC my patch to allow other fonts than just Helvetica.txf and led.txf. I'll try to reproduce and check if that's the cause, and fix it if so. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
* Melchior FRANZ -- Saturday 17 June 2006 21:23: The only recent change to the 2D panel was IIRC my patch to allow other fonts than just Helvetica.txf and led.txf. I'll try to reproduce and check if that's the cause, and fix it if so. Can't reproduce. You might want to try with that last change reverted: $ cd src/Cockpit cvs up -r1.40 panel.cxx later, to restore: $ cvs up -AC panel.cxx m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Saturday 17 June 2006 20:18, Vivian Meazza wrote: Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian Sounds very much like it - I first noticed under the same conditions. I'll try cvs with Melchior's latest update, but a bit later - I'm of to a birthday now. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory leak
Hello all, Is anyone else seeing a memory leak in current cvs? After using all my real ram fg starts gobbling through VM at about 1 mb every 5 seconds or so, even when flying around the same area. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
