Re: [Flightgear-devel] Prime Meridian Crash
On 11 Dec 2009, at 19:32, Csaba Halász wrote: Also, the whole positioned code seems to be ignorant of the fact that buckets don't have the same size. Staying with the spatialGetClosest, it assumes it can just use NxN boxes when in fact a different row (latitude) could have half or double the bucket size. spatialFind() even uses the width/height of the current bucket explicitly. The code isn't 'aware' of it, but I was aware, when I wrote the code - I just opted to ignore the fact, on the basis that the results I got from testing seemed plausible. By the time you're at a latitude where it matters, you're running low on navaids/fixes anyway. In light of this, not even the patch I proposed on IRC is halfway correct, so James please don't commit that. In my opinion, such a low-level and widely used piece of code must work correctly otherwise a lot of things can break. Well, this might surprise you, but it's actually used quite rarely *at the moment* - mostly by the GPS code, and the marker beacon code. The GPS code uses it extensively, of course - and the usage will increase quite a bit more - but most positioned users currently find things by ident or frequency. Thus I consider this a show-stopper for the release and an attitude of the issue of terminating with 'not actually the closest', I know of, but don't really care about isn't acceptable. Fundamentally we need a better algorithm, and probably a new data-structure - Mathias has a potential solution using a hierarchical triangle map, though the code is a bit template-heavy for my liking. Before writing the current algorithm, I experimented with various linear hashes of the lat/lon, but effectively that's what the bucket number from SGBucket gives you - and it doesn't help with 'find me all the buckets within 'x' nm of this lat/lon'. I'll take another read over Mathias' code today, but I don't think I'll like it any more than I did the last few times I read over it. Other suggestions welcome, or proposals for a sufficiently accurate 'all the SGBuckets within a given radius of position P' - allowing for behaviour at the poles and in the Pacific. BTW, it would also be possible to spatially index FGPositioneds by their cartesian position, potentially even using a BSP or similar. (Or an oct-tree). This would avoid all the wrap-around problems at the poles and -180/180 longitude search. Again, this is something I made some algorithmic doodles for, but never developed into working code. Actually, the more I think on it, the more I think the cartesian approach may be a win - assuming you can find the bsp/octree/whatever node that contains your 'search sphere' (sphere of radius set by the cutoff, centred on search location), ordering all the contents by distance is just X^2 + Y^2 + Z^2 and a sort - no geodetic computations at all. I'll think on that some more now. (And it's fairly amenable to the filtering methodology too) James -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Hi!
Alex was kind enough to give me shell access to his machine so I think
I have this beast figured out.
1) The immediate cause of the crash is due to
DistanceOrdering::operator() accessing an invalid pointer
2) The reason for that is std::sort indexing before the array (man, I
hate templates!)
3) In turn, that is because std::sort doesn't do range check instead
assuming the comparison function is consistent
4) the comparison function (the same as in point #1) is apparently not
consistent when compiled with optimization/inlining. This may have
something to do with the 80 bit FPU in x86.
5) the problem arises when comparing the same item to itself
6) the spatialGetClosest is inserting the same item multiple times
into the array, triggering #5.
Tracking down the problem was hard because
* valgrind didn't work
* problem only happened with optimized build
* even debug prints sometimes made the problem go away
Hence, I am not entirely sure about the mechanism involved in #4.
Nevertheless, adding a special case for a==b does seem to fix the
segfault. But that is only symptomatic treatment, so let's have a
little peek at spatialGetClosest:
// base case, simplifes loop to do it seperately here
spatialFilterInBucket(sgBucketOffset(lon, lat, 0, 0), aFilter, result);
for (;result.size() aN; ++radius) {
That's a wrong start. The nearest items need not be in the same bucket
as the reference point. Consider if the point lies at the edge of the
bucket - its closest neighbour may very well be on the other side of
the boundary. I think the same applies to the loop itself - you can't
simply stop due to having the required number of items because they
are not guaranteed to be the nearest ones. Also, I am not entirely
sure that the current cutoff distance checking is sufficient. Let's
suppose a coordinate system centered on the bucket containing the ref
point at the +,- corner. (See attached diagram) Assume bucket size 1,
requested range 1.05. So the ref point is at +0.5,-0.5. Box left
bottom bucket center at -1,-1 left top at +1,+1, distance from ref
point is 1.58 for both. That satisfies the 1.5 * 1.05 = 1.575 cutoff
condition so the code will never look at the bucket centered +2,0
which could contain a point at +1.5,-0.5 with distance 1.
for ( int i=-radius; i=radius; i++) {
spatialFilterInBucket(sgBucketOffset(lon, lat, i, -radius),
aFilter, hits);
spatialFilterInBucket(sgBucketOffset(lon, lat, -radius, i),
aFilter, hits);
spatialFilterInBucket(sgBucketOffset(lon, lat, i, radius), aFilter, hits);
spatialFilterInBucket(sgBucketOffset(lon, lat, radius, i), aFilter, hits);
}
That seems to walk the four edges of the box, but it touches the
corners twice. Which is bad because it inserts duplicates that the
rest of the code doesn't expect.
I have attached the quick fix for the benefit of the people plagued by
the segfault.
--
Cheers,
Csaba/Jester
--- old/src/Navaids/positioned.cxx 2009-12-01 20:37:01.0 +0100
+++ new/src/Navaids/positioned.cxx 2009-12-11 03:23:03.0 +0100
@@ -243,6 +243,7 @@
throw sg_exception(empty reference passed to DistanceOrdering);
}
+if (a == b) return false;
double dA = distSqr(a-cart(), mPos),
dB = distSqr(b-cart(), mPos);
return dA dB;
attachment: bucket.png--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Fri, Dec 11, 2009 at 4:13 PM, Csaba Halász csaba.hal...@gmail.com wrote: are not guaranteed to be the nearest ones. Also, I am not entirely sure that the current cutoff distance checking is sufficient. Let's suppose a coordinate system centered on the bucket containing the ref point at the +,- corner. (See attached diagram) Assume bucket size 1, requested range 1.05. So the ref point is at +0.5,-0.5. Box left bottom bucket center at -1,-1 left top at +1,+1, distance from ref point is 1.58 for both. That satisfies the 1.5 * 1.05 = 1.575 cutoff condition so the code will never look at the bucket centered +2,0 which could contain a point at +1.5,-0.5 with distance 1. Upon closer look, not only that the code won't look at the *next* box (radius=2), it won't even look at the *inner* box (radius=1), because the cutoff check comes before processing. Clearly that is wrong. Also, the whole positioned code seems to be ignorant of the fact that buckets don't have the same size. Staying with the spatialGetClosest, it assumes it can just use NxN boxes when in fact a different row (latitude) could have half or double the bucket size. spatialFind() even uses the width/height of the current bucket explicitly. In light of this, not even the patch I proposed on IRC is halfway correct, so James please don't commit that. In my opinion, such a low-level and widely used piece of code must work correctly otherwise a lot of things can break. Thus I consider this a show-stopper for the release and an attitude of the issue of terminating with 'not actually the closest', I know of, but don't really care about isn't acceptable. -- Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Dont know if this helps. but I compiled SG and FG with and without the CXXFLAGS. It only crashes when CXXFLAGS are NOT on FG, which seems to indicate a FG problem. Also noted is that the crash seems to happen 9 times out of ten to the west of prime, no matter how its approached. Is there anything else I can do ? pete Pete Morgan wrote: Just catching up on the thread (been away). I compiled SG and FG with CXXFLAGS=-g -O0 and its fantastic. For the first time I can fly around London airspace without a segfault. (never tried the dist packages so cant report on that). As far as finding the bug, I tried a lot of areas to try and catch it. Such as: * As Alex reported it happens around 3 west to 1 east, flying both ways. * I've flown in different timezones. * Flows in open sea areas with no scenery * flown with and without autopilot * set navaids to be well away, as well as on same side, opposite side of prime. * tried with all different rendering modes. I can successfully crash the 787, Bravo and MD11, 747*, airbus fleet every time. Concorde and a few others are intermittent with no clear results. I'm gonna compile FG and SG with the CXXFLAGS removed to see if any crash independently. gcc --version gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Is there any other areas I should try? Regards Pete -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Just catching up on the thread (been away). I compiled SG and FG with CXXFLAGS=-g -O0 and its fantastic. For the first time I can fly around London airspace without a segfault. (never tried the dist packages so cant report on that). As far as finding the bug, I tried a lot of areas to try and catch it. Such as: * As Alex reported it happens around 3 west to 1 east, flying both ways. * I've flown in different timezones. * Flows in open sea areas with no scenery * flown with and without autopilot * set navaids to be well away, as well as on same side, opposite side of prime. * tried with all different rendering modes. I can successfully crash the 787, Bravo and MD11, 747*, airbus fleet every time. Concorde and a few others are intermittent with no clear results. I'm gonna compile FG and SG with the CXXFLAGS removed to see if any crash independently. gcc --version gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3 Is there any other areas I should try? Regards Pete -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Sun, 01 Nov 2009 20:35:01 + James Turner zakal...@mac.com wrote: On 1 Nov 2009, at 19:24, Alex D-HUND wrote: At the moment I am out of ideas on what to try out next, I am open for suggestions. I keep forgetting to dig into this issue, apologies for that. I'll add it to my ToDo list now, and take a look this week. Regards, James James, there is really nothing to apologise for, for many reasons! One of those is, the slower the things go, the better I can keep up understanding what I am doing here ;-). Last night Jester picked me up on IRC and had some suggestions on how to continue. I try to make a conclusion of the things we did. ATM I have a simgear build with the VASI not included. To achive this he told me to comment the line 704 of http://cvs.flightgear.org/viewvc/source/simgear/scene/tgdb/obj.cxx?annotate=1.43root=SimGear With this build I am able to run FG with valgrind without problems. Except, FG does *not* crash at the zero meridian then. While without valgrind, or running with gdb, it still crashes 'as usual'. These crashes still occur between 0.2w and 0.03w when heading to the east. I made some gdb bt's and uploaded two of them, but they are the same as before: crashes between 0.2w and approx 0.07w are produceing http://flightgear.pastebin.ca/1652356 and closer to the meridian, 0.05w to 0.03w, the output looks like http://flightgear.pastebin.ca/1652360 Even if FG did not crash at the ZM running under valgrind, here is one of the logfiles: http://flightgear.pastebin.ca/1652335 Another thing we did is uncommenting line 552 in http://cvs.flightgear.org/viewvc/source/src/Navaids/positioned.cxx?annotate=1.24 Unfortunately (?) no 'destroying:' messages where printed. Hopefully I have not forgotten about an important detail, but if so, I am sure Jester will notice ;-) Alex -- Alex D-HUND f...@beggabaur.de -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Mon, 26 Oct 2009 21:54:08 +0100 Alex D-HUND f...@beggabaur.de wrote: In the meantime I have installed valgrind and I am doing my first steps with it. A first trial run turned out to be very good, I already saw the scenery ten minutes after starting it. ;-) Ahoy Guys, beside that mentioned test run I am not able to run fgfs with valgind anymore. It crashes even before I can see the scenery. I ran it often with different settings to figure out what could be different to the first run. I uploaded two of the logs I collected, see links below, they all end with SIGSEGV and complain about 'leaked memory', I hope my RAM isn't broken. At least two hours of memtest printed not a single red line. At the moment I am out of ideas on what to try out next, I am open for suggestions. Alex http://flightgear.pastebin.ca/1651812 http://flightgear.pastebin.ca/1651814 -- Alex D-HUND f...@beggabaur.de -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On 1 Nov 2009, at 19:24, Alex D-HUND wrote: At the moment I am out of ideas on what to try out next, I am open for suggestions. I keep forgetting to dig into this issue, apologies for that. I'll add it to my ToDo list now, and take a look this week. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
James Turner wrote: On 1 Nov 2009, at 19:24, Alex D-HUND wrote: At the moment I am out of ideas on what to try out next, I am open for suggestions. I keep forgetting to dig into this issue, apologies for that. I'll add it to my ToDo list now, and take a look this week. Recently I noticed a tile manager problem around KSFO (near Nasa Ames I think) with metar (real weather fetch) enabled, without it I haven't seen that problem yet. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On 25 Oct 2009, at 21:24, Alex DaHUND wrote: Now I was able to make some backtraces (http://nopaste.org/p/ aPZTtaYYX). Jester pointed out, that this could be a problem of the optimisation during the build process and advised me to configure SG and FG with option CXXFLAGS=-g -O0. He was right, with those binaries I wasn't able to reproduce the crash anymore. At the moment I am using binaries configured with CXXFLAGS=-g -O2 - march=native (which is athlon-xp here) and it seems a bit more stable now. FG still crashed on some testflights across the zero meridian, but at least not on all flights. I will try to collect some more METAR-strings which causes troubles and some more backtraces as well. If it's an optimisation-related bug, tracing it is going to be pretty awful. That said, the crash seems rather widespread for a straight compiler issue. I'm also surprised that a compiler bug would change frequency based on compile options. Assuming you have a set of compiler options which definitely trigger a crash, my advice would be to to a binary CVS search (unfortunately, this has to include both SG and FG, and a clean rebuild each time, probably). Start with a point a year ago and see what happens - then six months forward or back, then three months, and so on. We also need to establish what range of GCC versions might be affected. I hate optimiser bugs :( James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On 26 Oct 2009, at 09:14, James Turner wrote: If it's an optimisation-related bug, tracing it is going to be pretty awful. That said, the crash seems rather widespread for a straight compiler issue. I'm also surprised that a compiler bug would change frequency based on compile options. Speaking to Tim on IRC, I'm sort of swayed back to this some uninitialised data scenario. The key question is, is there a configuration, for some people (as in, compiler version, compile options, FG version, SG version, metar settings, aircraft) that will *always* crash? If we have that, then it's easy to test fixes - without that, we'll always be guessing. Incidentally, -O0 often implies that all values are initialised to zero, which could by why it fixes the problem. Valgrind should catch such an issue, if anyone is able to actually fly FG while running under VG - on Mac the performance is too slow to take off. It would still be interesting to do the CVS binary search if someone has time to spare, just to establish an upper bound on when the problem might have been introduced. James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Mon, Oct 26, 2009 at 10:40 AM, James Turner zakal...@mac.com wrote: Incidentally, -O0 often implies that all values are initialised to zero, which could by why it fixes the problem. Valgrind should catch such an issue, if anyone is able to actually fly FG while running under VG - on Mac the performance is too slow to take off. Luckily we only need the ufo for this test. I have run it under valgrind with no obviously relevant messages. Note, I can't reproduce the crash either. -- Csaba/Jester -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On Mon, Oct 26, 2009 at 4:14 AM, James Turner zakal...@mac.com wrote: If it's an optimisation-related bug, tracing it is going to be pretty awful. That said, the crash seems rather widespread for a straight compiler issue. I'm also surprised that a compiler bug would change frequency based on compile options. In my experience 99.99% of optimization bugs are not the compiler's fault. Usually there is a code problem and for whatever reason, we skate by with one set of options, but not another depending on how the compiler arranges or pads the code. If turning off optimization makes a problem go away, that's a *huge* tip that there is likely a problem in our code. It would be interesting to see what the back trace is with optimization turned on. I hate optimiser bugs :( I have yet to see one in the wild myself. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On 26 Oct 2009, at 17:15, Curtis Olson wrote: It would be interesting to see what the back trace is with optimization turned on. Absolutely - unfortunately, for whatever reason, none of the people who can easily generate a backtrace, have been able to reproduce the crash - I've tried, Jester has tried, and assorted others on IRC. James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
It would be interesting to see what the back trace is with optimization turned on. Absolutely - unfortunately, for whatever reason, none of the people who can easily generate a backtrace, have been able to reproduce the crash - I've tried, Jester has tried, and assorted others on IRC. Hi Curtis and James and others, I am sorry, I was a bit tired last night and might not phrased myself clearly. Also I am not a coder and maybe just don't understand what you mean. But the backtraces I made actually are with optimisation turned on. Well, I built the binaries without any options on this and therefore they are -O2 by default (as far as I was able to follow Jesters explanation). Here the link again: http://nopaste.org/p/aPZTtaYYX In the meantime I have installed valgrind and I am doing my first steps with it. A first trial run turned out to be very good, I already saw the scenery ten minutes after starting it. ;-) My gcc version is: 4.3.2 (Debian 4.3.2-1.1) And enclosed you'll find the .fgfsrc file containing the options I had the day I encountered that problem the first time. Except the change for the METAR, this one replaced the real-weather-fetch. Please let me know if you need more info, as I said, I am not a coder so don't really know what to look for. Thanks Alex -- Alex D-HUND f...@beggabaur.de .fgfsrc.zmcrash Description: Binary data -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Hi Alex, Ok, based on the backtrace, this would implicate something in the gps or perhaps FGPositioned code trying to do some sort of spatial sort? Regards, Curt. On Mon, Oct 26, 2009 at 3:54 PM, Alex D-HUND wrote: It would be interesting to see what the back trace is with optimization turned on. Absolutely - unfortunately, for whatever reason, none of the people who can easily generate a backtrace, have been able to reproduce the crash - I've tried, Jester has tried, and assorted others on IRC. Hi Curtis and James and others, I am sorry, I was a bit tired last night and might not phrased myself clearly. Also I am not a coder and maybe just don't understand what you mean. But the backtraces I made actually are with optimisation turned on. Well, I built the binaries without any options on this and therefore they are -O2 by default (as far as I was able to follow Jesters explanation). Here the link again: http://nopaste.org/p/aPZTtaYYX In the meantime I have installed valgrind and I am doing my first steps with it. A first trial run turned out to be very good, I already saw the scenery ten minutes after starting it. ;-) My gcc version is: 4.3.2 (Debian 4.3.2-1.1) And enclosed you'll find the .fgfsrc file containing the options I had the day I encountered that problem the first time. Except the change for the METAR, this one replaced the real-weather-fetch. Please let me know if you need more info, as I said, I am not a coder so don't really know what to look for. Thanks Alex -- Alex D-HUND f...@beggabaur.de -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
Hi Pete, I can confirm this bug. Problem with it, it does not happen all the time. I encountered it while preparing for the 'Euro Zone Event', taking off at EGLL heading to EHAM with the ufo to prefetch scenery. And it was even possible to reproduce the crash. So, the other day I asked on IRC what to do, and I was told to make a backtrace. But, funny thing, I was not able to crash FG like I did the day before. That reminded me of a METAR related problem I have with the c172p. Starting FG with this METAR-string instead of real weather fetch and the crashes occured again. (--prop:/environment/metar/data=LSZB 301950Z VRB01KT CAVOK 11/11 Q1015 NOSIG) Now I was able to make some backtraces (http://nopaste.org/p/aPZTtaYYX). Jester pointed out, that this could be a problem of the optimisation during the build process and advised me to configure SG and FG with option CXXFLAGS=-g -O0. He was right, with those binaries I wasn't able to reproduce the crash anymore. At the moment I am using binaries configured with CXXFLAGS=-g -O2 -march=native (which is athlon-xp here) and it seems a bit more stable now. FG still crashed on some testflights across the zero meridian, but at least not on all flights. I will try to collect some more METAR-strings which causes troubles and some more backtraces as well. My systems CPU: AMD Athlon(tm) XP 2800+ -- Alex D-HUND f...@beggabaur.de -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Prime Meridian Crash
On 14 Sep 2009, at 00:23, Pete Morgan wrote: Flying the East to West eg from EGLC London City to EGLL Heathrow crashes in a similar fashion. That's weird, I flew from EGLL to EGLC just the other day, and it worked fine. I'll try the route, and aircraft you suggested, in the next couple of days - happy for others to test, though. Regards, James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
