From: James T. <zak...@ma...> - 2010-07-21 15:39:41
|
I was testing some refactoring of the reset/reinit code, and found some intermittent crashes, especially when re-positioning several times - so I went through my changes, and eventually discovered the crashes also occur in HEAD, without any of my refactorings applied! (My changes do seem to make the crashes occur more often, though, see below) The crashes appear to be memory corruption - sometime the crash occurs inside OSG with bad scene data, sometimes before the crash, my C library reports non-malloc-ed or free-ed memory being accessed, and the rest of the time the crash is in the AI-traffic code, nearly always accessing bad pointers. 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) I should add, with my refactorings applied, doing re-position at JFK, wait 30 seconds, reposition at SFO, is *almost* guaranteed to crash; with HEAD, that will crash on the 4, 5 or 6th re-position, usually. (You need to move far enough on the reposition, to trigger a tile load, I think - I usually jump around KSFO / KJFK / KLAX ...) Can anyone confirm or deny any parts of this? I'd like to commit my refactorings, but not if they introduce a crashing bug. Ideally I'd like to fix the real crash - I'll try a valgrind run this evening - but I'd welcome any help tracking it down. If other people don't crash at all, that would of course be good to know as well! James PS - I'm well aware there's other bugs relating to reset/re-position, but please don't reply here to discuss them, or things will get very confusing! I only care about a crash during or soon after a reset or re-position, for the moment. |
From: Csaba H. <csa...@gm...> - 2010-07-21 15:44:46
|
On Wed, Jul 21, 2010 at 5:39 PM, James Turner <zak...@ma...> wrote: > > PS - I'm well aware there's other bugs relating to reset/re-position, but please don't reply here to discuss them, or things will get very confusing! I only care about a crash during or soon after a reset or re-position, for the moment. This isn't related to reset, but I do see occasional memory corruption that mostly results in a crash during model loading or during exit. -- Csaba/Jester |
From: Thorsten <br...@go...> - 2010-07-21 17:47:56
|
> 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. Thorsten |
From: Durk T. <d.t...@xs...> - 2010-07-21 18:38:07
|
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 |
From: James T. <zak...@ma...> - 2010-07-21 18:41:44
|
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 |
From: James T. <zak...@ma...> - 2010-07-21 18:43:01
|
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 |
From: Durk T. <d.t...@xs...> - 2010-07-21 19:05:15
|
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 |
From: Dave <dav...@nt...> - 2010-07-21 19:12:53
|
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 |
From: Durk T. <d.t...@xs...> - 2010-07-28 06:36:18
|
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 |
From: James T. <zak...@ma...> - 2010-07-28 07:23:09
|
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 |
From: Erik H. <er...@eh...> - 2010-07-28 07:57:56
|
On Wed, 2010-07-28 at 08:36 +0200, Durk Talsma wrote: > 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: While this probably is a step in the right direction it also means ATC chatter will be missing (for now). Erik |
From: Erik H. <er...@eh...> - 2010-07-28 08:13:21
|
On Wed, 2010-07-28 at 09:57 +0200, Erik Hofman wrote: > While this probably is a step in the right direction it also means ATC > chatter will be missing (for now). Ehm, ATIS that is. Erik |
From: Durk T. <d.t...@xs...> - 2010-07-30 07:38:52
|
On Thursday, July 29, 2010 11:11:39 pm Dave wrote: > Erik Hofman wrote: > > On Wed, 2010-07-28 at 09:57 +0200, Erik Hofman wrote: > >> While this probably is a step in the right direction it also means ATC > >> chatter will be missing (for now). > > > > Ehm, ATIS that is. > > > > Erik > > Yes, I hadn't realised that when I made the suggestion, I mistakenly > thought we were only discussing the attempt at intelligent AI traffic. > > It would be a shame to lose the ATIS, especially now it's working again > following the sound changes. What I propose to do is to remove all the > AI traffic stuff from ATCDCL, leaving just the ATC code, and then > re-enable it at compile time by default. The AI traffic is where all > the crashes originate from, and this would leave the frequency lookup > and ATIS working until they are ported to the new ATC system. I've > discovered that my Wife's laptop has a 3D card, so I should be able to > remove the AI stuff and test it. > As an alternative, I would suggest that we try to port the ATIS feature over to the new system. In my earlier mail, I implied doing that; I'm sorry if that didn't come across. (Having an ATIS that is integrated with the AIModels based system has several additional advantage, such as better integration with the slowly but steadily emerging ATC system for AIModels/Traffic manager traffic, and others). I'll have a look at what I can do this weekend. And, as an aside, but I'm sure everybody is aware of that: only the _default_ compilation behavior is changed. If you compile with --enable-atcdcl, you'll still be able to get ATIS messages. Cheers, Durk |
From: Dave <dav...@nt...> - 2010-07-29 21:11:48
|
Erik Hofman wrote: > On Wed, 2010-07-28 at 09:57 +0200, Erik Hofman wrote: > >> While this probably is a step in the right direction it also means ATC >> chatter will be missing (for now). >> > > Ehm, ATIS that is. > > Erik > > Yes, I hadn't realised that when I made the suggestion, I mistakenly thought we were only discussing the attempt at intelligent AI traffic. It would be a shame to lose the ATIS, especially now it's working again following the sound changes. What I propose to do is to remove all the AI traffic stuff from ATCDCL, leaving just the ATC code, and then re-enable it at compile time by default. The AI traffic is where all the crashes originate from, and this would leave the frequency lookup and ATIS working until they are ported to the new ATC system. I've discovered that my Wife's laptop has a 3D card, so I should be able to remove the AI stuff and test it. The only user-visible feature that would be lost would be the messages to/from ATC and the AI traffic. That however is unavoidable given that that AI system is realistically unmaintainable. Cheers - Dave |
From: Erik H. <er...@eh...> - 2010-07-30 08:06:24
|
On Fri, 2010-07-30 at 09:38 +0200, Durk Talsma wrote: > On Thursday, July 29, 2010 11:11:39 pm Dave wrote: > > Yes, I hadn't realised that when I made the suggestion, I mistakenly > > thought we were only discussing the attempt at intelligent AI traffic. > > > > It would be a shame to lose the ATIS, especially now it's working again > > following the sound changes. What I propose to do is to remove all the > > AI traffic stuff from ATCDCL, leaving just the ATC code, and then > > re-enable it at compile time by default. The AI traffic is where all > > the crashes originate from, and this would leave the frequency lookup > > and ATIS working until they are ported to the new ATC system. I've > > discovered that my Wife's laptop has a 3D card, so I should be able to > > remove the AI stuff and test it. > > > > As an alternative, I would suggest that we try to port the ATIS feature over > to the new system. In my earlier mail, I implied doing that; I'm sorry if that > didn't come across. (Having an ATIS that is integrated with the AIModels > based system has several additional advantage, such as better integration with > the slowly but steadily emerging ATC system for AIModels/Traffic manager > traffic, and others). I'll have a look at what I can do this weekend. I have been thinking about ATIS (and all queued messeges for that matter) but I think that using OpenAL's queueing mechanism would be a good idea since it offloads the burden of compiling message samples from small sound files to OpenAL where you just add another small sound file to the queue. Let me think about it some more an maybe I can come up with a good Queueing extension to the soundmanager. Erik |
From: Frederic B. <fre...@fr...> - 2010-07-31 10:41:10
|
Hi Durk, Le 30/07/2010 09:38, Durk Talsma a écrit : > And, as an aside, but I'm sure everybody is aware of that: only the _default_ > compilation behavior is changed. If you compile with --enable-atcdcl, you'll > still be able to get ATIS messages. > By the way, kln89_page_apt.cxx ( http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/KLN89/kln89_page_apt.cxx ) is still referencing unconditionally ATCDCL(line 29). Changing that line to : #if ENABLE_ATCDCL # include <ATCDCL/commlist.hxx> #else #include <ATC/atcutils.hxx> #endif leads to compilation errors (ATCData not defined, that is a struct, not a class BTW). I commited some changes to fix the MSVC build, but i didn't address that issue. Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos |
From: Durk T. <d.t...@xs...> - 2010-07-31 11:39:49
|
Hi Fred, On Saturday, July 31, 2010 12:40:50 pm Frederic Bouvier wrote: > By the way, kln89_page_apt.cxx ( > http://gitorious.org/fg/flightgear/blobs/next/src/Instrumentation/KLN89/kln > 89_page_apt.cxx ) is still referencing unconditionally ATCDCL(line 29). > Thanks for catching. I just pushed a fix onto gitorious. Cheers, Durk |
From: Erik H. <er...@eh...> - 2010-08-02 08:27:25
|
On Fri, 2010-07-30 at 09:49 +0200, Erik Hofman wrote: > I have been thinking about ATIS (and all queued messeges for that > matter) but I think that using OpenAL's queueing mechanism would be a > good idea since it offloads the burden of compiling message samples from > small sound files to OpenAL where you just add another small sound file > to the queue. > > Let me think about it some more an maybe I can come up with a good > Queueing extension to the soundmanager. Alright, the initial version is now pushed to git. The idea is the following; you'll have to create a new SGSampleQueue class and use the add() function to add samples to the queue: SGSampleQueue *queue = new SGSampleQueue( 8000 ); // frequency queue->add( buffer1, len1 ); queue->add( buffer2, len2 ); queue->play( true ); // play looped All samples added to the queue should have the same frequency and format. The SGSampleQueue class is derived from the SGSoundSample class and reuses most of the code. Erik |
From: Erik H. <er...@eh...> - 2010-08-02 08:32:33
|
On Mon, 2010-08-02 at 10:27 +0200, Erik Hofman wrote: > Alright, the initial version is now pushed to git. > The idea is the following; you'll have to create a new SGSampleQueue > class and use the add() function to add samples to the queue: > > SGSampleQueue *queue = new SGSampleQueue( 8000 ); // frequency > > queue->add( buffer1, len1 ); > queue->add( buffer2, len2 ); > queue->play( true ); // play looped > > All samples added to the queue should have the same frequency and > format. The SGSampleQueue class is derived from the SGSoundSample class > and reuses most of the code. Oh, for clarity; * you will need to add the sample queue to a sample group * the queue can have a position offset, orientation and an audio cone, just like any other sound sample. Erik |