More dive-site-management goodies.

[Dirk Hohndel]

On Mon, Jun 01, 2015 at 04:53:52PM -0700, Dirk Hohndel wrote:
> 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...???

And the fix is pushed. Can you check that it's correct, Linus? Works here
with your data file. I'll admit that the fix is non-sensical to me, I just
corrected this after studying the man page for std::sort... I have no idea
how this change could cause it NOT to read the 8 bytes before "first"...
or more precisely, why without this fix for your data file it DOES read 8
bytes before the array. Something is odd there...

Anyway, I also fixed the spelling of the compare function.

Just to make you happy.

Do I get a remote git push / update in return?

/D