On Thu, Aug 14, 2008 at 09:38:15PM +0100, Jon Burgess wrote:
> On Thu, 2008-08-14 at 09:43 +0100, Dave Stubbs wrote:
> > On Wed, Aug 13, 2008 at 9:25 PM, Jon Burgess <[EMAIL PROTECTED]> wrote:
> > > Even with a large overlap the squares are still visible at zoom 2. I'm
> > > not sure this is a big problem though. I was going to try running the
> > > code again with DIVISION=1. Last time I tried I got a segv after about 5
> > > hours in SHPDestroyTree(). It looked like a buffer or array overflow.
> > > Perhaps something between 1 and 400 with a larger overlap would work.
> > >
>
> Today I got another segv using DIVISIONS=400, TILE_OVERLAP=10000 on the
> planet dump. It appears to have overflowed the state->seg_list[100].
> Setting this to MAX_SEGS=1000 fixed the crash. I added a counter to
> print the maximum value of state->seg_count and strangely it only seemed
> to hit 97 so I can't quite explain why it crashed with MAX_SEGS=100.
If there is no theoretical limit, I often use something like:
struct seg *seg_list = NULL;
int nsegs_in_list = 0;
int curseg = 0;
if (curseg >= nsegs_in_list) {
nsegs_in_list = nsegs_in_list * 2 + 1;
seg_list = realloc (nsegs_in_list * sizeof (struct seg));
}
seg_list [curseg++] = ....
(the "if" becomes a "while" if curseg can "jump")
The temptation exists to preallocate the "usually not exceeded"
value. This could also work, however it's not a good idea. You'll save
a very small amount of CPU time: In the above case, where "100" seems
to be a limit that worked for years, the "allocate more space" code
then doesn't get tested until years later you apparently first exceed
100. At that point in time you'll have saved a total of about 7 or 8
realloc calls! (on a total of processing at least 100 segments).
If you go that way, say once in a few times you build such a construct
you'll have an error in the "allocate extra space" code, and it will
take ages to find. If you do it this way, You'll alway test the
expansion code, and if there is a problem, you'll still know what you
changed and be confronted with the results immediately.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
