On Mon, Jul 13, 2015 at 02:40:03PM -0700, Linus Torvalds wrote: > On Mon, Jul 13, 2015 at 2:37 PM, Linus Torvalds > <[email protected]> wrote: > > > > I'm wondering if maybe your "Fix memory handling for taxonomy data" > > commit fixed it. I ended up recompiling due to the debug patch, so I'm > > now running a different version of subsurface than I was when I saw it > > originally. > > That said, the code I suspect hasn't changed at all. > > So I'm wondering if it hit me two days ago because the geolocation > service had issues, and now I can't trigger it at all any more because > the geolocation returns good data. > > Because even day befoer yesterday I could not reproduce it with any > kind of reliability. But today I haven't seen it trigger at all.
I think there were two distinct bugs. I proud myself of being thorough when introducing buggy code and always provide a fallback bug in case the main bug gets found too easily... anyway... a) we didn't clear the pointers in one code path. That could trivially cause us to write past the end of the list. I am somewhat certain that that's what happened in the valgrind output that you sent b) in the scenario described in my last email, if you hit just the right sequence of service timeouts, you can write past the end of the list as well a) was fixed over the weekend. b) was prevented by your patch but I just finished writing what I think is a better patch that tries to use the data that we got back from the service and only gives up if our data structure is truly confused... this is one of these "this should never happen" situations as there are one more slots than useful categories (NONE isn't useful) and no category should be represented more than once... I'm testing this right now (kinda tough to test as the error case requires to create timeouts or failed lookups, so I'm simulating that), but I think I got this right. That said, I would appreciate a code review of that patch once it's pushed. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
