Hi,
In priorities.cxx, the function is written as -
static area_type_descriptor& get_area_descriptor( AreaType area ) {
if ( 0<=area || area < area_types.size() ) {
return area_types[area];
} else {
SG_LOG(SG_GENERAL, SG_ALERT, "unknown area code = " << (int)area);
exit(-1);
}
}
But this 'OR' (||) does NOT seem right! Should it not be an
'AND' (&&), thus correctly range checking the value passed?
If yes, which I am sure it must be, then of course other changes
follow. In running fgfs-construct, in clipper.cxx, there is,
in the TGClipper::merge_sliver function :-
for ( area = 0; area < TG_MAX_AREA_TYPES && !done; ++area ) {
if ( is_hole_area( area ) ) {
and similarly in TGClipper::clip_all, with -
for ( i = 0; i < TG_MAX_AREA_TYPES; i++ ) {
if ( is_landmass_area( i ) && !m_ignore_landmass ) {
and in some other places, and the functions like -
bool is_hole_area( AreaType area ) {
return get_area_descriptor( area ).kind==Hole;
}
bool is_landmass_area( AreaType area ) {
const AreaKind kind = get_area_descriptor( area ).kind;
return (kind==Landmass);
}
That means potentially the area value can range from 0 to 127,
while not 'done', which will put the value beyond the 'size'
of the vector area_types, which is filled from the contents
of the parsing of -
--priorities=priorities.txt
file the user provided, or the default if none... which puts
the area_types vector at only about 61, or so elements...
SOMEHOW, the unix std vector implementation seems to let
the out-of-range vector value continue without a problem,
although I am sure what is returned is 'undefined', but
not necessarily a NULL...
That is, the returned 'undefined', in is_hole_area(area),
for example -
return get_area_descriptor( area ).kind==Hole
does _NOT_ generate a segfault (SIGSEGV), as I think it
should, but it will if you try to access the string part
of such a non-existing out-of-range vector...
Of course in Win32, it will generate an abort dialog
if an out-of-range value is attempted to be extracted on
a std vector, which I think is what should happen...
My 'fix' for this was to return the 'Unknown' descriptor
when 'area' was out of vector range, which works, but I
do not know if this is the 'right' solution...
There are other solutions, like even when the priorities
text file is completed, the area_types vector is filled
out with 'Unknown' repeated, until it has a size of
TG_MAX_AREA_TYPES, which is 128 in the current build.
Or this use of a fixed (defined) TG_MAX_AREA_TYPES is
abandoned, and the loops are maximized to the
area_types.size()... priorities.cxx could provide a
function to return this vector 'size'...
Below is the set of data I ran into this on, the
priorities file, and the full command used...
Seek help from other who may know the code better, to
fix this out-of-vector-range problem in the tg-cs
git repo...
Regards,
Geoff.
The data set used on this test was (1184511 bytes) :-
http://geoffair.org/tmp/work.tar.gz
The priorities text file used :-
http://geoffair.org/tmp/priorities.txt
The full command used, in the /work folder :-
fgfs-construct --priorities=priorities.txt \
--output-dir=Terrain --work-dir=. --tile-id=2892641
SRTM-30 Beach GrassCover MixedCropPastureCover Stream \
DeciduousBroadCover Lake MudFlat ShrubCover Town \
DryCropPastureCover Landmass Road Verge
in both XP Win32, and Ubuntu 64-bit...
PS: Fred, I also tested with your fgfs-construct.exe
from Win32 20101002 zip, and it also aborted, but not
sure this is the 'same' problem... although the abort
is at the same place - after the output -
loaded 2925 total polys
clipping polygons
Running master clipper
(-3.75,51.5) (3.5,51.625)
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
