I noticed the crash appeared to be in "gpc.c". This is the general polygon
clipping library code. I've spent a lot of time in that code and here are
some things for people to be aware of:
1. I believe the code is algorithmically correct.
2. The problem is primarily binary floating point representation, rounding,
and manipulating data values that as real values are unique, but as
represented in a binary IEEE floating point format lead to various
degeneracies.
3. When you process global GIS data, you encounter every possible unwelcome
numerical situation. It is the nature of the beast.
4. A significant portion of the terragear code is dedicated to anticipating
common problems and eliminating them before they proceed down the processing
pipeline. There are many checks and tests and fixups that are run at
various stages of the processing pipeline.
5. The airport generator makes extensive use of the GPC library too.
6. I introduced a "nudge" option to the genapts utility that would adjust
the coordinates by millimeters -- not visually significant, but just enough
to avoid whatever numerical blowup happened on a particular airport.
7. I've spent hundreds of hours if not a lot more investigating these issues
and there's always a new one no matter what you do, and there's always a
"completely unexplainable" one to be wrestled with.
8. Just when you think you've got it handled, someone introduces new GIS
data or changes input data which creates a new numerically degenerate
condition somewhere and we are back to hunting it down.
The tool chain had some allowances for these inevitable numerical issues.
Genapts could be restarted at any point in the database. You could run
individual airports with the --nudge option to try to get past a problematic
airport.
The client-server tile building system carefully logged the output of each
tile that was generated, so if a tile failed (a) you would know about it,
and (b) there was quite a bit of debugging info logged so you could start
investigating.
The terragear-cs fork has had substantial changes from my original terragear
tree. I've seen some cases where I thought some problems might have been
introduced, and changes that maybe I didn't 100% agree with, along with some
misunderstandings of the overall purpose. But the problem from my end is
that the fork divergence happened at an incredibly stressful time of my
life. I had just moved to a new house and taken on a bigger mortgage, a
week later found out I was losing my job, had a horrible poor planning for
taxes that year and came up impossibly short, not to mention some other
family tragedy stuff that took a tremendous amount of our time and energy,
even our dog died (that's maybe not a big thing in comparison, but then it
ended up hitting us much harder than I every thought it would.) So the
point is I let the fork happen, and let others take over management of
terragear, because it was just far far beyond what I could handle thinking
about at the time. Now we are where we are. I keep meaning one of these
days to pull the terragear-cs code and all the newest on Martin's server and
see if I can do a world build, but--- "life seems to always get in the way
of life." ;-)
Anyway, hopefully that gives a little bit of context, and maybe a tip
(--nudge=) to get past a crash in genapts.
Regards,
Curt.
On Sun, Apr 17, 2011 at 9:08 AM, Christian Schmitt wrote:
> Arnt Karlsen wrote:
>
> > ..who's code, F|S|TG, or GCC? Which gcc version(s) did you use here?
>
> Where the problem lies in the code I don't know. But it would be SG or TG.
> My GCC version is 4.4.5, OS is Gentoo.
>
> > Debian has updated gcc-4.4 and gcc-4.6 yesterday and today, may
> > be updating gcc-4.5 now if they didn't earlier this week, so it
> > could well be the bug you've found, is being fixed, or has been
> > fixed by now.
>
> As I never encountered segfaults like this I currently think it's a SG/TG
> issue that was undetected until now. This does not mean that something has
> to be "fixed" as it's very small and can be circumvented by disabling SSE
> in
> the Makefile.
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.edu/~uav/
http://www.flightgear.org - http://gallinazo.flightgear.org
------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
