On 25 Apr 2012, at 07:04, Renk Thorsten wrote:
> A quick 3 minute test flight with the ufo looks very promising - I didn't see
> any obvious issues with the version pulled 10 minutes ago. I will do longer
> tests later toady.
Thanks Thorsten!
James
--
> What about the mentioned problems? Better? Worse?
A quick 3 minute test flight with the ufo looks very promising - I didn't see
any obvious issues with the version pulled 10 minutes ago. I will do longer
tests later toady.
* Thorsten
---
Hi,
On Tuesday, April 24, 2012 22:51:34 James Turner wrote:
> Okay, I guess I was assuming I can use SGreferenced the same way I use
> release/retain in Cocoa, or addRef/decRef in COM/XPCOM. But it seems as if
> this is not the case, from looking at your commit - I can't use
> SGreferenced as a v
On 24 Apr 2012, at 22:33, Mathias Fröhlich wrote:
> I could by the length of the thread not exactly find what is going wrong and
> how to reproduce this. But jut having a quick look at NasalPositiond.cxx, I
> can see that this does not match the intented use of SGReferenced.
> I have checked in
Hi,
On Tuesday, April 24, 2012 13:39:59 James Turner wrote:
> Okay, then I realise this isn't useful for you, but I'm stumped why it
> crashes for you. In particular, the hashForAirport function is being passed
> something that looks like a valid pointer (I think), and it crashing on a
> line tha
James,
I wasn't affected by a crash until I realized that hashForAirport was never
called. Then I enabled animated jetways and the segfault came, after few
successful calls.
I am not able to tell why though
HTH
-Fred
-
Im assuming my crash is related, but it only happens when i open the
route-manager dialog...
Syd
On Tue, Apr 24, 2012 at 10:24 AM, Curtis Olson wrote:
> On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
>>
>>
>> As far as the FGPositioned Octree is concerned (which is what findClosest
>> use
On Tue, Apr 24, 2012 at 11:09 AM, James Turner wrote:
>
> As far as the FGPositioned Octree is concerned (which is what findClosest
> uses internally), it's holding an owning ref and hence things can't be
> removed from it, for the moment.
>
> So what I guess is happening, is that I'm breaking th
On 24 Apr 2012, at 16:50, Curtis Olson wrote:
> If an FGAirport object was ref-counted and deleted because the ref-count went
> to zero, then why would FGAirport::findClosest() still be returning a
> pointer to it it as the closest airport? Is it not getting fully/properly
> deleted or remov
Hi James,
just a guess here, but in the past, I had to fix issues brought when converting
raw pointers to smart pointers and ending up deleting the pointer given by the
smart pointer explicitly. For example :
SGSharedPtr myPtr = new MyClass;
then
delete myPtr;
or
delete myPtr.get();
afterwar
On Tue, Apr 24, 2012 at 10:35 AM, James Turner wrote:
>
> On 24 Apr 2012, at 16:31, Curtis Olson wrote:
>
> > Based on two runs with out crashing, that seems to prevent the crash ...
>
> Okay, so that's good but leaves me wondering why it doesn't crash on
> Mac the same way. And also, how I'
On 24 Apr 2012, at 16:31, Curtis Olson wrote:
> Based on two runs with out crashing, that seems to prevent the crash ...
Okay, so that's good but leaves me wondering why it doesn't crash on Mac
the same way. And also, how I've got the ref-counting wrong.
James
--
On Tue, Apr 24, 2012 at 10:06 AM, James Turner wrote:
> It's probably a reference counting issue. FGAirport is a FGPositioned and
> hence reference counted. The Nasal Ghost is supposed to deal with this -
> when we create a ghost around the airport, we take a reference
> (SGReferenced::get) and w
On 24 Apr 2012, at 15:57, Curtis Olson wrote:
> I tried running with valgrind and the error didn't happen -- hmmm...
>
> Trying it again, but a valgrind startup is excruciatingly slow ...
It's probably a reference counting issue. FGAirport is a FGPositioned and hence
reference counted. The Nas
Hi James,
Here is a bit more information.
I added some printf's before the call to findClosest(pos, maxRange,
&filter) in f_airportinfo()
The first time through, this seems to work, it returns a valid pointer,
which gets passed to hashForAirport(c, apt) a few lines later.
In hashForAirport() I
See if this makes sense??
(gdb) frame 1
#1 0x0088fb79 in
hashForAirport (c=0x19e62860, apt=0x6a128d0) at
/home/scotth/Download/Flightgear/git-repo/flightgear/src/Scripting/NasalPositioned.cxx:113
113
std::string name = apt->name();
(gdb) print apt
$1 = (const FGAirport
*) 0x6a128d0
(g
On 24 Apr 2012, at 14:39, Curtis Olson wrote:
> For what it's worth, I'm seeing nearly the same thing ... similar back
> trace-- crashing in hashforairport() about 10-15 seconds after the splash
> screen has been removed and the sim presented for use.
Okay, that's good news since it rules out
On Tue, Apr 24, 2012 at 7:39 AM, James Turner wrote:
>
> On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
>
> > It doesn't depend - I got a crash at TNCM as well, also using both c172p
> and the ufo. So this must be something more generic.
> >
> >> Just to check, you have updated simgear as well? T
On 24 Apr 2012, at 12:07, Renk Thorsten wrote:
> It doesn't depend - I got a crash at TNCM as well, also using both c172p and
> the ufo. So this must be something more generic.
>
>> Just to check, you have updated simgear as well? There's a bugfix in
>> there I applied at the same time.
>
>
> Okay, this is my fault, but I don't know why / how it's crashing for
> you. Presumably you have some aircraft or nasal that makes additional
> airportinfo() calls, and you've managed to find a test-case that my
> testing has not encountered. Unfortunately we need to find out the
> relevan
On 24 Apr 2012, at 11:41, Renk Thorsten wrote:
> Here's the output:
>
> (gdb) bt
> #0 0x5e3d9a08 in ?? ()
> #1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
>at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
> #2 0x088ddc29 in f_airportinfo (c=0x13bedd28, m
Oops, missed that part of the instructions *blush*
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
On 24 Apr 2012, at 11:31, Renk Thorsten wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x5e3d9a08 in ?? ()
> Missing separate debuginfos, use: debuginfo-install e2fsprogs.i386 gcc.i386
> glibc.i686 libICE.i386 libSM.i386 libX11.i386 libXau.i386 libXcursor.i386
> libXdmcp.i386 l
>>> Can you get a backtrace?
Okay, following your instructions I did make clean in any of my build folders,
ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and
flightgear, and did
gdb ./fgfs
run --log-level=info --airport=KSFO --disable-real-weather-fetch
--disable-fullscree
> I had similar problem this weekend, and a full rebuild (simgear +
> flightgear) solved the issue. I have the sentiment that changes
> to SGReferenced (in simgear) could have created this instability
I pulled everything fresh and compiled both simgear and flightgear new, so
things shouldn't be o
On 24 Apr 2012, at 09:20, Renk Thorsten wrote:
>> Can you get a backtrace?
>
> I can try if you tell me what I need to do...
(re-)Build fgfs with debug symbols:
-DCMAKE_BUILD_TYPE=Debug
when running cmake, might need to make clean + make again
then run fgfs
gdb fgfs
run --log-level=
Hi Thorsten,
> > Can you get a backtrace?
>
> I can try if you tell me what I need to do...
>
> > I've made a change to the startup sequence,
> > yesterday, but I would expect it to crash later (after scenery
> > loading),
> > ten seconds sounds too early.
>
> Misunderstanding: After scenery l
> Can you get a backtrace?
I can try if you tell me what I need to do...
> I've made a change to the startup sequence,
> yesterday, but I would expect it to crash later (after scenery loading),
> ten seconds sounds too early.
Misunderstanding: After scenery loading and I find myself in the
On 24 Apr 2012, at 09:04, Renk Thorsten wrote:
> I've just pulled and compiled simgear and flightgear and pulled a fresh
> FGData to start package the next lightfield shader version, but it turns out
> the resulting binary is unstable.
>
> I get segfaults about 10 seconds after startup with th
I've just pulled and compiled simgear and flightgear and pulled a fresh FGData
to start package the next lightfield shader version, but it turns out the
resulting binary is unstable.
I get segfaults about 10 seconds after startup with the master branch, no other
errors written to the console, a
30 matches
Mail list logo
