Re: [Flightgear-devel] GIT as of today unstable
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 -- 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] GIT as of today unstable
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 -- 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] GIT as of today unstable
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 the master branch, no other errors written to the console, apparently independent on what I do or how I set options on startup. Memory consumption in the system monitor looks normal, reverting back to the old version pulled two weeks ago restores stability, so it's not just some fluke of my machine. Can you get a backtrace? 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. James -- 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] GIT as of today unstable
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 loading and I find myself in the cockpit, I have 10 seconds to look around, then comes the crash. 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 Regards, -Fred -- 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] GIT as of today unstable
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=info --airport=KSFO --some-other-options-to-fgfs wait for the crash ... bt copy and paste what gets spewed out into email 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 cockpit, I have 10 seconds to look around, then comes the crash. That's much more likely to be me - does disabling traffic stop the crash? (And does re-winding Git to yesterday morning also stop it?) James -- 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] GIT as of today unstable
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 out of sync... That's much more likely to be me - does disabling traffic stop the crash? The problem does occur despite --prop=/sim/traffic-manager/enabled=false in the commandline. It appears rather regular though, so there's not much scattering in the timescale associated. (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=info --airport=KSFO --some-other-options-to-fgfs wait for the crash ... bt copy and paste what gets spewed out into email I will have a look at that, but that takes more time than I have on my hands right now :-( * Thorsten -- 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] GIT as of today unstable
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-fullscreen --geometry=1200x900 There follows a long log of essentially normal status messages (which I can also get you if your really like), terminating rather suddenly with (...) Loading tile 942040.stg Generating ocean tile Loading tile 942072.stg Loading stg file /home/fgfs/FGData/fgdata/Scenery/Terrain/w130n30/w123n37/942072.stg Loading tile 958424.stg Loading stg file /home/fgfs/FGData/fgdata/Scenery/Objects/w130n30/w122n37/958424.stg 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 libXext.i386 libXfixes.i386 libXrender.i386 libjpeg.i386 libpng.i386 libxcb.i386 mesa.i386 zlib.i386 Not sure that helps... certainly doesn't look very telling to me... Cheers, * Thorsten -- 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] GIT as of today unstable
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 libXext.i386 libXfixes.i386 libXrender.i386 libjpeg.i386 libpng.i386 libxcb.i386 mesa.i386 zlib.i386 Not sure that helps... certainly doesn't look very telling to me... Okay, if you type 'bt' at that point you should get the backtrace, which should help. Although the fact you're getting '??()' is slightly worrying that your fgfs lacks debug information. James -- 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] GIT as of today unstable
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=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 2147
444617}}, argc=0, args=0x13bee934)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:416
#3 0x08c89a55 in setupFuncall (ctx=0x13bedd28, nargs=0, mcall=0, named=0)
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:316
#4 0x08c8ca02 in run (ctx=0x13bedd28)
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:681
#5 0x08c8d4e0 in naCall (ctx=0x13bedd28, func=
{num = nan(0xf6789151a161c), ref = {ptr = {obj = 0x151a161c, str = 0x151
a161c, vec = 0x151a161c, hash = 0x151a161c, code = 0x151a161c, func = 0x151a161c
, ccode = 0x151a161c, ghost = 0x151a161c}, reftag = 2147444617}}, argc=0,
args=0x0, obj=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag = 2147
444617}}, locals=
{num = nan(0xf67891503efc0), ref = {ptr = {obj = 0x1503efc0, str = 0x150
3efc0, vec = 0x1503efc0, hash = 0x1503efc0, code = 0x1503efc0, func = 0x1503efc0
, ccode = 0x1503efc0, ghost = 0x1503efc0}, reftag = 2147444617}})
---Type return to continue, or q return to quit---
at /home/fgfs/CMake/simgear/simgear/nasal/code.c:846
#6 0x088cba4b in FGNasalSys::call (this=0x13f77098, code=
{num = nan(0xf6789151a161c), ref = {ptr = {obj = 0x151a161c, str =
0x151a161c, vec = 0x151a161c, hash = 0x151a161c, code = 0x15
1a161c, func = 0x151a161c, ccode = 0x151a161c, ghost = 0x151a161c}, reftag =
2147444617}}, argc=0,
args=0x0, locals=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec =
0x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, gh
ost = 0x0}, reftag = 2147444617}}) at
/home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:113
#7 0x088cbe27 in FGNasalSys::handleTimer (this=0x13f77098, t=0xa115d1a8)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:879
#8 0x088cbe5d in FGNasalSys::NasalTimer::timerExpired (this=0xa115d1a8)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalSys.cxx:897
#9 0x088cfbb3 in SGMethodCallbackFGNasalSys::NasalTimer*, void
(FGNasalSys::NasalTimer::*)()::operator() (this=0xa115d1e0)
at /home/fgfs/FG/include/simgear/structure/callback.hxx:117
#10 0x08cfd50a in SGTimer::run (this=0xa115d1f8)
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:38
#11 0x08cfdd4a in SGTimerQueue::update (this=0xaca3824,
deltaSecs=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:112
#12 0x08cfe07d in SGEventMgr::update (this=0xaca37f0,
delta_time_sec=0.1)
---Type return to continue, or q return to quit---
at /home/fgfs/CMake/simgear/simgear/structure/event_mgr.cxx:43
#13 0x08d01252 in SGSubsystemGroup::Member::update (this=0x12e496d8,
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:361
#14 0x08d01a18 in SGSubsystemGroup::update (this=0xaca3780,
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:221
#15 0x08cffb94 in SGSubsystemMgr::update (this=0xaca3650,
delta_time_sec=0.1)
at /home/fgfs/CMake/simgear/simgear/structure/subsystem_mgr.cxx:448
#16 0x08577c44 in fgMainLoop ()
at /home/fgfs/CMake/flightgear/src/Main/main.cxx:220
#17 0x0855c69f in fgOSMainLoop ()
at /home/fgfs/CMake/flightgear/src/Main/fg_os_osgviewer.cxx:284
#18 0x08575979 in fgMainInit (argc=6, argv=0xbf8aba94)
at /home/fgfs/CMake/flightgear/src/Main/main.cxx:549
#19 0x08541a33 in main (argc=6, argv=0xbf8aba94)
at /home/fgfs/CMake/flightgear/src/Main/bootstrap.cxx:252
--
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] GIT as of today unstable
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, me=
{num = nan(0xf6789), ref = {ptr = {obj = 0x0, str = 0x0, vec = 0
x0, hash = 0x0, code = 0x0, func = 0x0, ccode = 0x0, ghost = 0x0}, reftag =
2147
444617}}, argc=0, args=0x13bee934)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:416
#3 0x08c89a55 in setupFuncall (ctx=0x13bedd28, nargs=0, mcall=0, named=0)
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 relevant bit of Nasal I
guess.
I can see it's an airportinfo() call with no arguments, which location are you
at? KSFO right? H.
If I launch at KSFO, I get no crash, and I can make airportinfo() calls in the
Nasal console with no problems.
Just to check, you have updated simgear as well? There's a bugfix in there I
applied at the same time.
James
--
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] GIT as of today unstable
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 relevant bit of Nasal I guess. I can see it's an airportinfo() call with no arguments, which location are you at? KSFO right? H. 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. I did pull simgear, when I retry now I get 'Already up-to-date.' and I did recompile both simgear and flightgear after 'make clean' in both build directories using the same procedures I've been using since we migrated to cmake. So to my best ability to tell, my simgear is up to date. * Thorsten -- 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] GIT as of today unstable
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. I did pull simgear, when I retry now I get 'Already up-to-date.' and I did recompile both simgear and flightgear after 'make clean' in both build directories using the same procedures I've been using since we migrated to cmake. So to my best ability to tell, my simgear is up to date. 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 that should only really happen if the pointer is invalid, or there's other memory corruption going on. Again, I realise this doesn't help you, I'm just confused by the failure mode. James -- 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] GIT as of today unstable
On Tue, Apr 24, 2012 at 7:39 AM, James Turner zakal...@mac.com 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? There's a bugfix in there I applied at the same time. I did pull simgear, when I retry now I get 'Already up-to-date.' and I did recompile both simgear and flightgear after 'make clean' in both build directories using the same procedures I've been using since we migrated to cmake. So to my best ability to tell, my simgear is up to date. 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 that should only really happen if the pointer is invalid, or there's other memory corruption going on. Again, I realise this doesn't help you, I'm just confused by the failure mode. 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. Linux, fedora 15, nvidia graphics ... Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] GIT as of today unstable
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 something Thorsten specific. Can you see if the FGAirport* being passed to hashForAirport looks like a valid pointer? James -- 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] GIT as of today unstable
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
(gdb) print c
$2 = (Context *) 0x19e62860
(gdb) print
apt-name
$3 = {const std::string (const FGAirport * const)} 0x6609c0
(gdb) print apt-name()
Program received signal SIGSEGV, Segmentation
fault.0x006609c0 in ?? ()
The program being debugged was
signaled while in a function called from GDB.
GDB remains in the frame
where the signal was received.
To change this behavior use set
unwindonsignal on.
Evaluation of the expression containing the
function(at 0x0x6609c0) will be abandoned.
When the function is done
executing, GDB will silently stop.
(gdb)
S.
On Tue, 24 Apr 2012
14:45:17 +0100, James Turner wrote:
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 something Thorsten
specific. Can you see if the FGAirport* being passed to hashForAirport
looks like a valid pointer? James
--
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/ [1]
___ Flightgear-devel mailing
list Flightgear-devel@lists.sourceforge.net [2]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel [3]
Links:
--
[1]
http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[2]
mailto:Flightgear-devel@lists.sourceforge.net
[3]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
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] GIT as of today unstable
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 also printed the name and id that FGAirport *apt points to. The first time through it prints id = 58Q name = Mazza The crash happens on the second time through this call sequence. The second call to f_airportinfo() seems to follow the same logic and get the same answer. The FGAirport *apt pointer returned by findClosest() is the same value as previously. However when passing this to hashForAirport() it appears that the references it apt-ident() and apt-name() trigger a segfault. I tried running with valgrind and the error didn't happen -- hmmm... Trying it again, but a valgrind startup is excruciatingly slow ... Curt. On Tue, Apr 24, 2012 at 8:45 AM, James Turner zakal...@mac.com wrote: 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 something Thorsten specific. Can you see if the FGAirport* being passed to hashForAirport looks like a valid pointer? James -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] GIT as of today unstable
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 Nasal Ghost is supposed to deal with this - when we create a ghost around the airport, we take a reference (SGReferenced::get) and when Nasal garbage-collects the ghost, the reference count is decremented. (SGReferenced::put) If the reference count hits zero, the airport will be freed, leading to the issue you see. But that would imply there's nothing else holding a reference to the airport, and that's not the case, because the the spatial index (the octree) in positioned.cxx holds a reference to everything at the moment. If I'd screwed up the ref-counting logic completely, I'd expect it to be crashing for me exactly the same, and it's not. Very weird. So likely I have made a subtle screw-up that only affects Linux. You could test this by commenting out the call to SGreferencd::put() in sgrefGhostDestroy - references will be leaked, but if it stops the crash then we can be sure it's a ref-counting bug. James -- 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] GIT as of today unstable
On Tue, Apr 24, 2012 at 10:06 AM, James Turner zakal...@mac.com 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 when Nasal garbage-collects the ghost, the reference count is decremented. (SGReferenced::put) If the reference count hits zero, the airport will be freed, leading to the issue you see. But that would imply there's nothing else holding a reference to the airport, and that's not the case, because the the spatial index (the octree) in positioned.cxx holds a reference to everything at the moment. If I'd screwed up the ref-counting logic completely, I'd expect it to be crashing for me exactly the same, and it's not. Very weird. So likely I have made a subtle screw-up that only affects Linux. You could test this by commenting out the call to SGreferencd::put() in sgrefGhostDestroy - references will be leaked, but if it stops the crash then we can be sure it's a ref-counting bug. Hi James, Based on two runs with out crashing, that seems to prevent the crash ... Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] GIT as of today unstable
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 -- 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] GIT as of today unstable
On Tue, Apr 24, 2012 at 10:35 AM, James Turner zakal...@mac.com 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've got the ref-counting wrong. 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 removed from the list and you just getting lucky on the Mac that it's not segfaulting? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] GIT as of today unstable
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 : SGSharedPtrMyClass myPtr = new MyClass; then delete myPtr; or delete myPtr.get(); afterward, the destructor of SGSharedPtrMyClass does another delete on the same memory and may crash, depending the system and the memory layout Regards, -Fred -- 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] GIT as of today unstable
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 removed from the list and you just getting lucky on the Mac that it's not segfaulting? 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 the ref-counting scheme *somehow*, and hence the Octree is left holding a dead reference as you say. And somehow how I get away with this on Mac. But this feels a little implausible, since in other similar scenarios the Mac crashes quite happily! James -- 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] GIT as of today unstable
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 the ref-counting scheme *somehow*, and hence the Octree is left holding a dead reference as you say. And somehow how I get away with this on Mac. But this feels a little implausible, since in other similar scenarios the Mac crashes quite happily! I've manage to have a run or two on Linux that didn't crash if that makes you feel any better. :-) But I'll give you that it's much easier to fix a problem that you can observe versus one you can't observe. Perhaps the ref counting problem isn't getting triggered on your Mac for some other subtle reason? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] GIT as of today unstable
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 curtol...@gmail.com 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 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 the ref-counting scheme *somehow*, and hence the Octree is left holding a dead reference as you say. And somehow how I get away with this on Mac. But this feels a little implausible, since in other similar scenarios the Mac crashes quite happily! I've manage to have a run or two on Linux that didn't crash if that makes you feel any better. :-) But I'll give you that it's much easier to fix a problem that you can observe versus one you can't observe. Perhaps the ref counting problem isn't getting triggered on your Mac for some other subtle reason? Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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 -- 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] GIT as of today unstable
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 -- 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] GIT as of today unstable
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 that should only really happen if the pointer is invalid, or there's other memory corruption going on. Just stepping into this discussion somehow. 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 what is needed to match how it's intented to be used. Given that you seem to experience dangling pointers and now things are actually deleted when the reference count drops to zero - that did not happen before, I guess that this makes things worse at first. But you might be able to find the real cause of the problem a little better now. Else, I am online again tomorrow evening. Greetings Mathias -- 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] GIT as of today unstable
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 what is needed to match how it's intented to be used. Given that you seem to experience dangling pointers and now things are actually deleted when the reference count drops to zero - that did not happen before, I guess that this makes things worse at first. But you might be able to find the real cause of the problem a little better now. Else, I am online again tomorrow evening. 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 virtual base, and I have to make the delete call by hand. I guess this is to avoid virtual method overhead on SGreferenced? James -- 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] GIT as of today unstable
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 virtual base, and I have to make the delete call by hand.
I guess this is to avoid virtual method overhead on SGreferenced?
Yes.
SGReferenced should exactly *not* contain any virtual table. This is supposed
to be the helper class for reference counting, but it should be as lightweight
as possible. Imagine we want at some time have a variable size mathematical
vector container that works with a copy on write semantics, I definitely want
to use SGReferenced there and have no vtable at all.
If you want something that you can just use a general base class for
heavyweight stuff, invent a class derived from SGReferenced or better
SGWeakReferenced that introduces this vtable stuff. And since we are looking
then for something more heavy, I would tend to use SGWeakReferenced as base
class for an SGObject
class SGObject : public SGWeakReferenced {
public:
virtual ~SGObject() {}
}
The weak referenced class provides the ability to have weak pointers to such a
WeakReferenced derived class. That are pointers that know about when the last
reference to the instance it points to is deleted and provides a
SGSharedPtrT SGWeakPtrT::lock() method that atomically and thread safe
returns either a valid shared pointer to the still alive object or a null
pointer since the objects reference count was already zero and the object is
at least being deleted or already dead.
If you want the destructor protected, I need to backport something more from
OpenRTI and stuff to simgear.
What about the mentioned problems? Better? Worse?
Mathias
--
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
