More dive-site-management goodies.

[Dirk Hohndel]

On Mon, Jun 01, 2015 at 04:35:50PM -0700, Dirk Hohndel wrote:
> > I'm now running Fedora-22, I'm wondering if that's the issue. New
> > compiler showing new bugs? The call chain implies this comes from the
> > sort() function and the iterators, called from
> > 
> >     LocationInformationModel::update()
> > 
> > Anybody?
> 
> I can reproduce it with your dive data. I'll see if anything obvious
> comes up... (it works perfectly fine with my dive data)
> 
> > Hackign things up a bit, I see
> > 
> >    (gdb) p *(struct dive_site_table *)0x0000000000a2b250
> >    $2 = {nr = 281, allocated = 390, dive_sites = 0x3c009c0}
> > 
> > so I have 281 of those dive_sites, but I'm wondering whether the issue
> > is that we've done "beginInsertRows()" earlier, and it has perhaps
> > already incremented the nr of entries? That would explain the "-1" in
> > the std::sort() call, and might also explain why it SIGSEGV's (we're
> > trying to sort things in between the beginInsertRows/endInsertRows, is
> > the array perhaps not in a stable form there?
> 
> It should be - that's a very typical operation to do.

Instrumenting the code some more it's not the end where we go wrong - sort
accesses data 8 byte before the start of the array...???

/D