[Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks to timoore on IRC for helping find the cause of this. It seems that a recent checkin broke the build system if osg is installed in a custom location. - --with-osg=/home/anmaster/local/flightgear-osg in my case. I got this from configure: checking osg/Version usability... yes checking osg/Version presence... yes checking for osg/Version... yes ./configure: line 11740: USE_OSGDEBUG: command not found checking for osgViewerGetVersion in -losgViewer... no checking for osgGAGetVersion in -losgGA... no checking for osgTextGetVersion in -losgText... no checking for osgUtilGetVersion in -losgUtil... no checking for osgDBGetVersion in -losgDB... no checking for osgSimGetVersion in -losgSim... no checking for osgGetVersion in -losg... no checking for OpenThreadsGetVersion in -lOpenThreads... no but configure finished successfully. But then I got this at the final linking of the binary: ../../src/Main/libMain.a(renderer.o): In function `fgDumpTerrainBranchToFile(char const*)': renderer.cxx:(.text+0x2bb): undefined reference to `osgDB::Registry::instance(bool)' renderer.cxx:(.text+0x2cd): undefined reference to `osgDB::writeNodeFile(osg::Node const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB:: ReaderWriter::Options const*)' ../../src/Main/libMain.a(renderer.o): In function `fgDumpSceneGraphToFile(char const*)': renderer.cxx:(.text+0x380): undefined reference to `osgDB::Registry::instance(bool)' renderer.cxx:(.text+0x392): undefined reference to `osgDB::writeNodeFile(osg::Node const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB:: ReaderWriter::Options const*)' ../../src/Main/libMain.a(renderer.o): In function `fgDumpNodeToFile(osg::Node*, char const*)': renderer.cxx:(.text+0x439): undefined reference to `osgDB::Registry::instance(bool)' renderer.cxx:(.text+0x44b): undefined reference to `osgDB::writeNodeFile(osg::Node const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB:: ReaderWriter::Options const*)' ../../src/Main/libMain.a(renderer.o): In function `FGRenderer::update(bool)': renderer.cxx:(.text+0x7a5): undefined reference to `osg::FrameStamp::setCalendarTime(tm const)' ../../src/Main/libMain.a(renderer.o): In function `__static_initialization_and_destruction_0(int, int)': And about 6000 lines more like that... After reverting according to timoore's instructions: timoore cvs update -r1.125 configure.ac timoore cvs update -r1.79 src/Main/Makefile.am and re-running autogen.sh the building works again. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHh0J6WmK6ng/aMNkRCgfSAJ9ORAZOIibUKrFjFyGuQ4GtomHmoACZAR5E fROUIZD+pRDWN2RnXlHyOT0= =LICF -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
I just committed a patch that should fix this configure.ac problem. Guys, it looks like no one tested this patch before committing it, or didn't look close enough at the result. It doesn't bother me that mistakes happen once in a while ... this is the dev tree after all, but it makes me nervous ... this wasn't a typo or inadvertant bug, it was a clear misunderstanding of the automake/autoconf system ... and it's hard to imagine this was ever tested, otherwise it should have been clear that it didn't do what was intended. Anyway, it should now be fixed, so on with life ... :-) Curt. On Jan 11, 2008 10:39 AM, Curtis Olson [EMAIL PROTECTED] wrote: Hmmm, ok the author of the most recent patch misunderstands the use of the AM_CONDITIONAL() This does not produce a value that can later be used in the configure script. Instead it ties into the Makefile.am and can activate one set of rules or another. I'll take a look to see if I can unwind the mess. :-( Curt. On Jan 11, 2008 10:25 AM, AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: Are you building on the Mac OSX platform? No. On Gentoo Linux (x86_64) Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHh5iRWmK6ng/aMNkRCq+ZAJwJ2ZtB0M2k2lytUbDWHBk31JOM8QCeLWI4 i+CGSqD5TcpNCzBVcJ78Tg4= =9Xsa -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/http://baron.flightgear.org/%7Ecurt/ -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
Curtis Olson wrote: I just committed a patch that should fix this configure.ac problem. Guys, it looks like no one tested this patch before committing it It worked for me. Probably because my LD_LIBRARY_PATH is set such that the resulting configure-generated programs can run? The genesis of the commit was a complaint on the IRC channel by Hans that the OS X build had been broken for a long time, and that patches to fix that (the whole point here was to use the Apple-specific AC_CHECK_FRAMEWORK macro for the OSG libraries on OS X) had been ignored for weeks. I read it, nodded, tried it and committed. IMHO, it's better to have a little grief on the development list than leave an important user platform broken like that. Andy - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: Are you building on the Mac OSX platform? No. On Gentoo Linux (x86_64) Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHh5iRWmK6ng/aMNkRCq+ZAJwJ2ZtB0M2k2lytUbDWHBk31JOM8QCeLWI4 i+CGSqD5TcpNCzBVcJ78Tg4= =9Xsa -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
Are you building on the Mac OSX platform? Curt. On Jan 11, 2008 4:18 AM, AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks to timoore on IRC for helping find the cause of this. It seems that a recent checkin broke the build system if osg is installed in a custom location. - --with-osg=/home/anmaster/local/flightgear-osg in my case. I got this from configure: checking osg/Version usability... yes checking osg/Version presence... yes checking for osg/Version... yes ./configure: line 11740: USE_OSGDEBUG: command not found checking for osgViewerGetVersion in -losgViewer... no checking for osgGAGetVersion in -losgGA... no checking for osgTextGetVersion in -losgText... no checking for osgUtilGetVersion in -losgUtil... no checking for osgDBGetVersion in -losgDB... no checking for osgSimGetVersion in -losgSim... no checking for osgGetVersion in -losg... no checking for OpenThreadsGetVersion in -lOpenThreads... no but configure finished successfully. But then I got this at the final linking of the binary: ../../src/Main/libMain.a(renderer.o): In function `fgDumpTerrainBranchToFile(char const*)': renderer.cxx:(.text+0x2bb): undefined reference to `osgDB::Registry::instance(bool)' renderer.cxx:(.text+0x2cd): undefined reference to `osgDB::writeNodeFile(osg::Node const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB:: ReaderWriter::Options const*)' ../../src/Main/libMain.a(renderer.o): In function `fgDumpSceneGraphToFile(char const*)': renderer.cxx:(.text+0x380): undefined reference to `osgDB::Registry::instance(bool)' renderer.cxx:(.text+0x392): undefined reference to `osgDB::writeNodeFile(osg::Node const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB:: ReaderWriter::Options const*)' ../../src/Main/libMain.a(renderer.o): In function `fgDumpNodeToFile(osg::Node*, char const*)': renderer.cxx:(.text+0x439): undefined reference to `osgDB::Registry::instance(bool)' renderer.cxx:(.text+0x44b): undefined reference to `osgDB::writeNodeFile(osg::Node const, std::basic_stringchar, std::char_traitschar, std::allocatorchar const, osgDB:: ReaderWriter::Options const*)' ../../src/Main/libMain.a(renderer.o): In function `FGRenderer::update(bool)': renderer.cxx:(.text+0x7a5): undefined reference to `osg::FrameStamp::setCalendarTime(tm const)' ../../src/Main/libMain.a(renderer.o): In function `__static_initialization_and_destruction_0(int, int)': And about 6000 lines more like that... After reverting according to timoore's instructions: timoore cvs update -r1.125 configure.ac timoore cvs update -r1.79 src/Main/Makefile.am and re-running autogen.sh the building works again. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHh0J6WmK6ng/aMNkRCgfSAJ9ORAZOIibUKrFjFyGuQ4GtomHmoACZAR5E fROUIZD+pRDWN2RnXlHyOT0= =LICF -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot controller filter weirdness
Hi all,
I've been experiencing some more weird behaviour from pid
controllers and filters.
I had a pid controller that was working ok (but had some room for
further fine-tuning) but after amending the config and re-loading
the autopilot it seemed to be working randomly. I reverted back to
the original values and re-loaded again but still got the same
random behaviour.
Along with this I was also monitoring a moving-spike filter that was
filtering the output from the pid controller, but which I wasn't
actually using, and saw it appear to start oscillating at around a
value of zero even though the pid controller output, and therefore
the filter input, had swung over and clamped to one of it's max/min
limits. If I disabled the pid controller the filter immediately
started to work correctly and the filter out swung to match the
input. Re-enabling the pid controller resulted in the filter
oscillation resuming even though the pid controller output didn't
seem to change.
Also, as I was thinking about this I noticed that the oscillating
output seemed to be slowly drifting towards the correct value and
couldn't help wonder if re-loading the autopilot was creating new
instances of the pid controller without removing the old ones.
I've had a look at the relevant code but as I'm not up on c++ I'm
not sure about what I'm looking at but at lines 798-802 there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that components.clear()
must be what removes old instances and must be a more generic
function. However, when I grepped through the SimGear FlightGear
source the only occurrence I could find of this function was at
that single point in xmlauto.cxx. I then searched for
components.clear() in C/C++ reference manuals on the web and didn't
find anything there either. Perhaps I just wasn't looking in the
right place though.
In any case, it seems strange to me that if components.clear() is a
generic function, it's only used in this one place in the entire
SG/FG source.
I might be barking up the wrong tree entirely here, but I can't see
what else might be causing the behaviour I'm seeing.
LeeE
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
Hmmm, ok the author of the most recent patch misunderstands the use of the AM_CONDITIONAL() This does not produce a value that can later be used in the configure script. Instead it ties into the Makefile.am and can activate one set of rules or another. I'll take a look to see if I can unwind the mess. :-( Curt. On Jan 11, 2008 10:25 AM, AnMaster wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: Are you building on the Mac OSX platform? No. On Gentoo Linux (x86_64) Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHh5iRWmK6ng/aMNkRCq+ZAJwJ2ZtB0M2k2lytUbDWHBk31JOM8QCeLWI4 i+CGSqD5TcpNCzBVcJ78Tg4= =9Xsa -END PGP SIGNATURE- - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG: FG HEAD fails to compile after recent changes to configure.ac (reverting fixes it)
On Jan 11, 2008 10:57 AM, Andy Ross [EMAIL PROTECTED] wrote: It worked for me. Probably because my LD_LIBRARY_PATH is set such that the resulting configure-generated programs can run? The genesis of the commit was a complaint on the IRC channel by Hans that the OS X build had been broken for a long time, and that patches to fix that (the whole point here was to use the Apple-specific AC_CHECK_FRAMEWORK macro for the OSG libraries on OS X) had been ignored for weeks. I read it, nodded, tried it and committed. IMHO, it's better to have a little grief on the development list than leave an important user platform broken like that. I suspect you got the same error message I did when running configure, but that it didn't kill the overall compile/run. That said, configure dumps a lot of info so it's easy to miss a squawk in there. We definitely want to support the Mac platform. I've been chasing email all day and just getting further and further behind. Hopefully this discussion filters back to whomever originally created the patch so they are able to gain a better understanding of the automake/autoconf system. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot controller filter weirdness
On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote:
On Friday 11 January 2008, LeeE wrote:
I've had a look at the relevant code but as I'm not up on c++ I'm
not sure about what I'm looking at but at lines 798-802 there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that components.clear()
must be what removes old instances and must be a more generic
function. However, when I grepped through the SimGear FlightGear
source the only occurrence I could find of this function was at
that single point in xmlauto.cxx. I then searched for
components.clear() in C/C++ reference manuals on the web and didn't
find anything there either. Perhaps I just wasn't looking in the
right place though.
In any case, it seems strange to me that if components.clear() is a
generic function, it's only used in this one place in the entire
SG/FG source.
Actually it's only the clear() part that it generic. clear() is a method
of
the vector template.
I might be barking up the wrong tree entirely here, but I can't see
what else might be causing the behaviour I'm seeing.
Try commenting out the call to build() from the code that you quoted
above.
build() is called inside init(), so there should be no need to call it
again
after init().
I suspect the build() is there so you can change the autopilot config file
while flying and reload it. That way you don't need to restart the sim to
fiddle with the gains.
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot controller filter weirdness
On Friday 11 January 2008, Curtis Olson wrote: On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote: Try commenting out the call to build() from the code that you quoted above. build() is called inside init(), so there should be no need to call it again after init(). I suspect the build() is there so you can change the autopilot config file while flying and reload it. That way you don't need to restart the sim to fiddle with the gains. Curt. Yes, but there is no need to call build() two times in order to reload. I did a simple test revealing that after an autopilot reload, components contained twice as many elements as before the reaload. As would be expected by calling build() twice. I firmly belive that the call to build() in FGXMLAutopilot.reinit() should be removed. -- Roy Vegard Ovesen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot controller filter weirdness
On Friday 11 January 2008 21:50, Curtis Olson wrote:
On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote:
On Friday 11 January 2008, LeeE wrote:
I've had a look at the relevant code but as I'm not up on c++
I'm not sure about what I'm looking at but at lines 798-802
there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that
components.clear() must be what removes old instances and
must be a more generic function. However, when I grepped
through the SimGear FlightGear source the only occurrence I
could find of this function was at that single point in
xmlauto.cxx. I then searched for components.clear() in C/C++
reference manuals on the web and didn't find anything there
either. Perhaps I just wasn't looking in the right place
though.
In any case, it seems strange to me that if
components.clear() is a generic function, it's only used in
this one place in the entire SG/FG source.
Actually it's only the clear() part that it generic. clear()
is a method of
the vector template.
I might be barking up the wrong tree entirely here, but I
can't see what else might be causing the behaviour I'm
seeing.
Try commenting out the call to build() from the code that you
quoted above.
build() is called inside init(), so there should be no need to
call it again
after init().
I suspect the build() is there so you can change the autopilot
config file while flying and reload it. That way you don't need
to restart the sim to fiddle with the gains.
Curt.
I'll give what Roy suggests a try - build() is called from within
init() and build() creates new controller, predictor and filter
nodes (if I'm interpreting it correctly). If it's being called
twice, after clear() then it might explain something.
No problem to give it a try - I'll post back after re-compiling.
LeeE
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot controller filter weirdness
On Friday 11 January 2008 23:49, LeeE wrote:
On Friday 11 January 2008 21:50, Curtis Olson wrote:
On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote:
On Friday 11 January 2008, LeeE wrote:
I've had a look at the relevant code but as I'm not up on
c++ I'm not sure about what I'm looking at but at lines
798-802 there's:
void FGXMLAutopilot::reinit() {
components.clear();
init();
build();
}
I could find init() build() and thought that
components.clear() must be what removes old instances and
must be a more generic function. However, when I grepped
through the SimGear FlightGear source the only occurrence
I could find of this function was at that single point in
xmlauto.cxx. I then searched for components.clear() in
C/C++ reference manuals on the web and didn't find anything
there either. Perhaps I just wasn't looking in the right
place though.
In any case, it seems strange to me that if
components.clear() is a generic function, it's only used in
this one place in the entire SG/FG source.
Actually it's only the clear() part that it generic.
clear() is a method of
the vector template.
I might be barking up the wrong tree entirely here, but I
can't see what else might be causing the behaviour I'm
seeing.
Try commenting out the call to build() from the code that you
quoted above.
build() is called inside init(), so there should be no need
to call it again
after init().
I suspect the build() is there so you can change the autopilot
config file while flying and reload it. That way you don't
need to restart the sim to fiddle with the gains.
Curt.
I'll give what Roy suggests a try - build() is called from within
init() and build() creates new controller, predictor and filter
nodes (if I'm interpreting it correctly). If it's being called
twice, after clear() then it might explain something.
No problem to give it a try - I'll post back after re-compiling.
LeeE
Spoke too soon - I thought I'd update SG FG from cvs before trying
this and now FG won't get past the 'loading scenery objects' phase.
Setting --log-level=info seems to show FG looping while displaying
lots of:
Processing registration HA-LHA with callsign MAH096/5
type messages, which seem to be repeated over over.
It'll have to wait until the morning now:(
LeeE
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] segfault in recent CVS due to minimal sound configuration file
tower:ch53e$ gdb fgfs --aircraft=ch53e --timeofday=noon
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
Starting program: /usr/local/bin/fgfs --aircraft=ch53e --timeofday=noon
[Thread debugging using libthread_db enabled]
[New Thread 0xb69136e0 (LWP 32353)]
osgDB ac3d reader: could not find texture Untitled
[New Thread 0xb09f8b90 (LWP 32382)]
[New Thread 0xb01f8b90 (LWP 32383)]
Httpd server started on port 5100
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb69136e0 (LWP 32353)]
FGFX::init (this=0xdd52200) at fg_fx.cxx:95
95 for (i = 0; i node-nChildren(); i++) {
(gdb) bt
#0 FGFX::init (this=0xdd52200) at fg_fx.cxx:95
#1 0x086ff8ef in SGSubsystemGroup::init (this=0x8852c9c)
at subsystem_mgr.cxx:124
#2 0x08084e8c in fgInitSubsystems () at fg_init.cxx:1823
#3 0x08067683 in fgIdleFunction () at main.cxx:920
#4 0x080b69dd in FGManipulator::handle (this=0x8852698, [EMAIL PROTECTED],
[EMAIL PROTECTED]) at FGManipulator.cxx:148
#5 0xb7715dda in osgViewer::Viewer::eventTraversal ()
from /usr/local/lib/libosgViewer.so.26
#6 0xb7719c63 in osgViewer::ViewerBase::frame ()
from /usr/local/lib/libosgViewer.so.26
#7 0x080be8ce in fgOSMainLoop () at fg_os_sdl.cxx:248
#8 0x08063b55 in fgMainInit (argc=3, argv=0xbfbd7184) at main.cxx:1077
#9 0x080628d4 in main (argc=247672440, argv=0xecb4798)
at bootstrap.cxx:220
(gdb)
I made this happen by putting this:
sound
pathAircraft/ch53e/Sound/ch53e-sound.xml/path
/sound
in ch53e-set.xml
ch53e-sound.xml looks like this:
?xml version=1.0?
PropertyList
/PropertyList
Reverting the change to ch53e-set.xmlch53e-set.xml makes the segfault go
away. I don't think it should be that easy to make the xml reader choke :)
Last compiled (and updated) 1/9.
Josh
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault in recent CVS due to minimal sound configuration file
Josh Babcock wrote:
tower:ch53e$ gdb fgfs --aircraft=ch53e --timeofday=noon
GNU gdb 6.7.1-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
Starting program: /usr/local/bin/fgfs --aircraft=ch53e --timeofday=noon
[Thread debugging using libthread_db enabled]
[New Thread 0xb69136e0 (LWP 32353)]
osgDB ac3d reader: could not find texture Untitled
[New Thread 0xb09f8b90 (LWP 32382)]
[New Thread 0xb01f8b90 (LWP 32383)]
Httpd server started on port 5100
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb69136e0 (LWP 32353)]
FGFX::init (this=0xdd52200) at fg_fx.cxx:95
95 for (i = 0; i node-nChildren(); i++) {
(gdb) bt
#0 FGFX::init (this=0xdd52200) at fg_fx.cxx:95
#1 0x086ff8ef in SGSubsystemGroup::init (this=0x8852c9c)
at subsystem_mgr.cxx:124
#2 0x08084e8c in fgInitSubsystems () at fg_init.cxx:1823
#3 0x08067683 in fgIdleFunction () at main.cxx:920
#4 0x080b69dd in FGManipulator::handle (this=0x8852698, [EMAIL PROTECTED],
[EMAIL PROTECTED]) at FGManipulator.cxx:148
#5 0xb7715dda in osgViewer::Viewer::eventTraversal ()
from /usr/local/lib/libosgViewer.so.26
#6 0xb7719c63 in osgViewer::ViewerBase::frame ()
from /usr/local/lib/libosgViewer.so.26
#7 0x080be8ce in fgOSMainLoop () at fg_os_sdl.cxx:248
#8 0x08063b55 in fgMainInit (argc=3, argv=0xbfbd7184) at main.cxx:1077
#9 0x080628d4 in main (argc=247672440, argv=0xecb4798)
at bootstrap.cxx:220
(gdb)
I made this happen by putting this:
sound
pathAircraft/ch53e/Sound/ch53e-sound.xml/path
/sound
in ch53e-set.xml
ch53e-sound.xml looks like this:
?xml version=1.0?
PropertyList
/PropertyList
Reverting the change to ch53e-set.xmlch53e-set.xml makes the segfault go
away. I don't think it should be that easy to make the xml reader choke :)
Last compiled (and updated) 1/9.
Josh
Hi
The code was assuming there would be a fx node. The attached patch
fixed it in my tests (and corrects a i++ to ++i in a for loop)
Cheers,
Tiago
Index: fg_fx.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Sound/fg_fx.cxx,v
retrieving revision 1.24
diff -u -p -r1.24 fg_fx.cxx
--- fg_fx.cxx 20 Apr 2007 18:32:43 - 1.24
+++ fg_fx.cxx 12 Jan 2008 02:58:12 -
@@ -92,17 +92,20 @@ FGFX::init()
}
node = root.getNode(fx);
- for (i = 0; i node-nChildren(); i++) {
- SGXmlSound *sound = new SGXmlSound();
-
- try {
- sound-init(globals-get_props(), node-getChild(i),
- globals-get_soundmgr(), globals-get_fg_root());
-
- _sound.push_back(sound);
- } catch ( sg_io_exception e ) {
- SG_LOG(SG_GENERAL, SG_ALERT, e.getFormattedMessage());
- delete sound;
+ if(node)
+ {
+for (i = 0; i node-nChildren(); ++i) {
+SGXmlSound *sound = new SGXmlSound();
+
+try {
+ sound-init(globals-get_props(), node-getChild(i),
+ globals-get_soundmgr(), globals-get_fg_root());
+
+ _sound.push_back(sound);
+} catch ( sg_io_exception e ) {
+ SG_LOG(SG_GENERAL, SG_ALERT, e.getFormattedMessage());
+ delete sound;
+}
}
}
}
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
