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
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
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
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
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
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
6 matches
Mail list logo
