On Mon, Jul 13, 2015 at 3:46 PM, Linus Torvalds < [email protected]> wrote:
> On Sat, Jul 11, 2015 at 4:39 PM, Linus Torvalds > <[email protected]> wrote: > > > > which is just the taxonomy.category writes. Looks like it writes past > > the end of the allocation. > > Ok, looking at this, the problem seems to be pretty clear. > > When the code does the taxonomy lookup in > ReverseGeoLookupThread::run(), it keeps on just adding data to the > taxonomy field. > > IOW, the code that overflows the allocation is this, which just keeps > doing: > > if (ds->taxonomy.category == NULL) > ds->taxonomy.category = > alloc_taxonomy(); > > ds->taxonomy.category[ds->taxonomy.nr].category = TC_OCEAN; > > ds->taxonomy.category[ds->taxonomy.nr].origin = taxonomy::GEOCODED; > > ds->taxonomy.category[ds->taxonomy.nr].value = > copy_string(qPrintable(oceanName["name"].toString())); > ds->taxonomy.nr++; > > and eventually "ds->taxonomy.nr" will grow past TC_NR_CATEGORIES and > we corrupt memory. > > I don't know exactly how it happens, though. Normally I would expect that > the > > ds->taxonomy.nr = ri; > > that happens a bit earlier would reset the taxonomy number to 0 or 1, > but that is all inside that > > if (geoNames.count() > 0) { > > conditional, so maybe there is some situation where that doesn't > happen, and then the later code ends up adding too many entries > because it keeps adding things on top of older data. > > I don't know the code. It looks like both Tomaz started it and Dirk > has been changing code in this area, soo.. > Actually, it's all dirk's code. I moved around when I created a thread so it wouldn't freeze my machine. I'll t ake a look on it as soon as I have some time. just finished a big piece of the UI for Location Management > > Linus >
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
