Re: [Flightgear-devel] Crashes on reset/re-position
Hi, On Wednesday, July 21, 2010 09:12:43 pm Dave wrote: Yikes - is that ancient code still used? I thought it had been ripped out long ago - I would certainly agree with disabling it by default. I developed that code on Linux (gcc 3.x I think) and I've since discovered with the kln89 code that that compiler would let me write code that wouldn't segfault for me, but which would segfault if compiled and run via. MSVC. I just push a batch of local commits to gitorious flightgear, which changes the default compilation behaviour on automake systems to exclude the compilation of the ATCDCL module. I tested FlightGear for a couple of hours locally, and all seems to run fine. But, please let me know if anything is broken. If you do run into trouble, please try to recompile using: ./configure --enable-atcdcl and this should get the original behavior back. Also note, that the current change comes with a slight regression in functionality: Most notably, the AI/ATC airport frequency look up currently doesn't work, and ATIS is also temporarily gone. In addition, the GUI settings for AI traffic are currently not functional. As a general plan of approach, I'll try to link the AI traffic gui settings to the AIModels system, and then bring back the ATIS and Frequency look up (if still desired). FWIW, I originally wanted to wait until all the replacement code was done, but currently the confusion that arises around AI Traffic, AIModels, and traffic manager code is growing too big to my taste. In addition, Dave's own suggestion to disable this old system was the final incentive that made me decide to push this change onto gitorious. Cheers, Durk -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes on reset/re-position
On 28 Jul 2010, at 07:36, Durk Talsma wrote: As a general plan of approach, I'll try to link the AI traffic gui settings to the AIModels system, and then bring back the ATIS and Frequency look up (if still desired). Frequency lookup and comm station handling should be doable using a new FGPositioned subclass (FGCommStation?) - and with the comm stations accessible from their owning airports if we can do that - i.e extend FGAirport with 'getATISStations', 'getGroundStations' and so on. Once we have that it's easy to extent the NasaySys airportinfo() dict to include the frequency information, and get the GUI functions back in XML/Nasal. FWIW, I originally wanted to wait until all the replacement code was done, but currently the confusion that arises around AI Traffic, AIModels, and traffic manager code is growing too big to my taste. In addition, Dave's own suggestion to disable this old system was the final incentive that made me decide to push this change onto gitorious. Agreed, it's been a source of much confusion for me. Thanks for doing this! James -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes on reset/re-position
Hi James, On Wednesday, July 21, 2010 05:39:08 pm James Turner wrote: My hypothesis is that something in the AI-Traffic code doesn't like being re-positioned; if I reset/re-position very rapidly, I don't usually crash, whereas if I wait 20-30 seconds at a location, before re-positioning, the crash is much more likely. I think this is because this gives the AItraffic code time to 'do something', i.e spawn aircraft. (I think the OSG crashes are due to bad model-placements or similar, relating to the AI failures - though this is a wild guess) Do you mean the old AI Traffic code or the AIModels based one. In case of the former, have you tried compiling using ./configure --disable-atcdcl and see whether that makes a difference? After a couple of recent fixes, this configure option should be able to produce runable code. Cheers, Durk -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes on reset/re-position
On 21 Jul 2010, at 18:47, Thorsten wrote: My hypothesis is that something in the AI-Traffic code doesn't like being re-positioned; Maybe related to issue #133 in bug tracker: http://code.google.com/p/flightgear-bugs/issues/detail?id=133 The AI code corrupts memory when the plane leaves the range of an ATC station. It usually happens when flying. Haven't tested repositioning too much, but I guess it could trigger the same scenario, when the new position is several miles away... I added two patches to the tracker to fix memory corruption in the AI code, but they are not in GIT yet. I guess the tracker is not really used too much. Maybe s.o. could have a closer look at this issue, since this corruption problem happened *really* often to me. I never managed to fly more than 40-50 miles away from an airport when AI was enabled. The patches in the tracker fixed the issues for me. Another workaround is to disable AI traffic right from the start. The back-trace in that bug looks very familiar! I think this is exactly the issue, but I shall do some further testing this evening. Also, for bugs which have patches un-applied, please feel free to poke me, or post here - anything that encourage people to use the tracker is good, I think. James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes on reset/re-position
On 21 Jul 2010, at 19:37, Durk Talsma wrote: My hypothesis is that something in the AI-Traffic code doesn't like being re-positioned; if I reset/re-position very rapidly, I don't usually crash, whereas if I wait 20-30 seconds at a location, before re-positioning, the crash is much more likely. I think this is because this gives the AItraffic code time to 'do something', i.e spawn aircraft. (I think the OSG crashes are due to bad model-placements or similar, relating to the AI failures - though this is a wild guess) Do you mean the old AI Traffic code or the AIModels based one. In case of the former, have you tried compiling using ./configure --disable-atcdcl and see whether that makes a difference? After a couple of recent fixes, this configure option should be able to produce runable code. The old code. I'm going to try Thorsten's patches in #133, but a related question - could we not make --disable-atcdcl the default? (I.e, --enable-atcdcl instead) James -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes on reset/re-position
On Wednesday, July 21, 2010 08:42:49 pm James Turner wrote: The old code. I'm going to try Thorsten's patches in #133, but a related question - could we not make --disable-atcdcl the default? (I.e, --enable-atcdcl instead) I'm actually strongly considering this; however, the current situation is such that we'd still lose a limited amount of functionality that I haven't ported over to the new system (GUI airport radio frequency lookup, and ATIS are the most important ones). If the general consensus is that we can temorarily accept living without those features, I'm inclined to change the default behavior sometime next week. Cheers, Durk -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crashes on reset/re-position
James Turner wrote: On 21 Jul 2010, at 19:37, Durk Talsma wrote: My hypothesis is that something in the AI-Traffic code doesn't like being re-positioned; if I reset/re-position very rapidly, I don't usually crash, whereas if I wait 20-30 seconds at a location, before re-positioning, the crash is much more likely. I think this is because this gives the AItraffic code time to 'do something', i.e spawn aircraft. (I think the OSG crashes are due to bad model-placements or similar, relating to the AI failures - though this is a wild guess) Do you mean the old AI Traffic code or the AIModels based one. In case of the former, have you tried compiling using ./configure --disable-atcdcl and see whether that makes a difference? After a couple of recent fixes, this configure option should be able to produce runable code. The old code. I'm going to try Thorsten's patches in #133, but a related question - could we not make --disable-atcdcl the default? (I.e, --enable-atcdcl instead) Yikes - is that ancient code still used? I thought it had been ripped out long ago - I would certainly agree with disabling it by default. I developed that code on Linux (gcc 3.x I think) and I've since discovered with the kln89 code that that compiler would let me write code that wouldn't segfault for me, but which would segfault if compiled and run via. MSVC. Unfortunately, my ancient PC is no longer really capable of running FGFS, particularly a debug version, so until I've got new hardware I can't really help, even though this bug is probably my fault. Sorry. Cheers - Dave -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
