On Sat, Jul 11, 2015 at 4:39 PM, Linus Torvalds <torva...@linux-foundation.org> 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.. Linus _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface