Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On Mon, Aug 1, 2011 at 5:41 AM, Ove Kåven o...@arcticnet.no wrote: If there are no other references, the prop_root is automatically destroyed when sgLoad3DModel_internal returns, causing the memory to be freed. So, later on, when OSG wants to do something with these particles, the freed memory is referenced and causes a crash. Indeed, I have been unable to run FG with particles enabled since a long time due to random crashes in the particle code. Call stack frequently included functions your description mentions, so I hope this patch will fix that issue. Thank you. -- Csaba/Jester -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On 1 Aug 2011, at 12:30, Csaba Halász wrote: Indeed, I have been unable to run FG with particles enabled since a long time due to random crashes in the particle code. Call stack frequently included functions your description mentions, so I hope this patch will fix that issue. Can anyone think of a reason particles are fine for some (many?) people without this patch? Of course the patch should be applied, I'm just wondering what would affect the ref-counting logic to hide the problem in some machines / environments. James -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
James wrote: On 1 Aug 2011, at 12:30, Csaba Halász wrote: Indeed, I have been unable to run FG with particles enabled since a long time due to random crashes in the particle code. Call stack frequently included functions your description mentions, so I hope this patch will fix that issue. Can anyone think of a reason particles are fine for some (many?) people without this patch? Of course the patch should be applied, I'm just wondering what would affect the ref-counting logic to hide the problem in some machines / environments. Particles work fine here - Windows/MSVC9 Vivian -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On Mon, Aug 1, 2011 at 2:24 PM, James Turner zakal...@mac.com wrote: Can anyone think of a reason particles are fine for some (many?) people without this patch? Of course the patch should be applied, I'm just wondering what would affect the ref-counting logic to hide the problem in some machines / environments. Deleted memory is not immediately overwritten, so maybe for lucky people the contents stay there longer. There are ways to force freed memory to be overwritten by some marker (such as 0xdf using dmalloc), could be worth a try. -- Csaba/Jester -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup crash in SimGear (with patch?)
On 01.08.2011 14:24, James Turner wrote: On 1 Aug 2011, at 12:30, Csaba Halász wrote: Indeed, I have been unable to run FG with particles enabled since a long time due to random crashes in the particle code. Call stack frequently included functions your description mentions, so I hope this patch will fix that issue. Can anyone think of a reason particles are fine for some (many?) people without this patch? Of course the patch should be applied, I'm just wondering what would affect the ref-counting logic to hide the problem in some machines / environments. The issue only shows when particles are enabled and an aircraft is actually using them - which already reduces the number of users ;-). I actually had it disabled for a long time. After enabling it recently, I also started having memory issues - on shutdown though. So that patch comes handy. The particular code has been there since the beginning of the module. Another, similar issue was fixed a while ago (http://www.gitorious.org/fg/simgear/commit/29aad066f0e57a04649b92083c4be7c6d490de31) but the property reference issue was overlooked. My guess is that there's usually no problem since the referenced property would still be part of the main property tree (?) - and have a reference there. Only when the property is dropped from the tree, should an issue occur (which would well explain my shutdown issues - but not necessarily the startup issues...). cheers, Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] startup crash in SimGear (with patch?)
It seems there's a memory management issue in SimGear that may cause a crash under certain conditions. (Actually I'm not totally sure why it ever works at all, but that's another matter.) In the routine sgLoad3DModel_internal (scene/model/SGReaderWriterXML.cxx) there's a prop_root variable of type SGSharedPtrSGPropertyNode. At some point, it may be passed to Particles::appendParticles. appendParticles (scene/model/particles.cxx) implicitly copies the value into a newly allocated GlobalParticleCallback's field modelRoot, of type SGPropertyNode*. So, when appendParticles return, there's a persistent non-reference-counted pointer to this structure. If there are no other references, the prop_root is automatically destroyed when sgLoad3DModel_internal returns, causing the memory to be freed. So, later on, when OSG wants to do something with these particles, the freed memory is referenced and causes a crash. I didn't see a fix for this in your git, so I've attached a quickfix, but perhaps you prefer other solutions. And perhaps it's not the only issue of this kind (especially since I see fgfs still crashes at exit), but this is all I have time for right now. Ove Index: simgear/scene/model/particles.hxx === --- simgear/scene/model/particles.hxx (revisjon 138) +++ simgear/scene/model/particles.hxx (revisjon 148) @@ -99,7 +99,7 @@ private: static osg::Vec3 gravity; static osg::Vec3 wind; -const SGPropertyNode* modelRoot; +SGSharedPtrconst SGPropertyNode modelRoot; static SGConstPropertyNode_ptr enabledNode; static bool enabled; }; -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
