More dive-site-management goodies.
Dirk Hohndel
dirk at hohndel.org
Mon Jun 1 16:35:50 PDT 2015
On Mon, Jun 01, 2015 at 03:18:03PM -0700, Linus Torvalds wrote:
> Current git version of subsurface doesn't work for me at all, and gets
> a SIGSEGV in the dive site management code.
>
> Am I the only one seeing this? SIGSEGV in dive_site_less_then().
>
> [ Side note, the horrible syntax failure of that function name annoys
> me too. "less than", not "less then". It hurts ]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000651f08 in dive_site_less_then (a=0x3cbc340, b=0xc41) at
> /home/torvalds/src/subsurface/qt-models/divelocationmodel.cpp:6
> 6 return QString(a->name) <= QString(b->name);
>
> because 'b' is an invalid pointer (that 0xc41 is not valid).
>
> 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)
> gdb is being singularly unhelpful, because gdb is a buggy piece of
> shit, and we have "struct dive_site_table" and a variable called
> "dive_site_table", and when I ask gdb to show "dive_site_table" (no
> "struct" anywhere), gdb gets all pissy and thinks I'm asking for the
> _type_. Christ, what a horrible nasty piece of software. I've seen
> this before, I think it's some gdb C++ name confusion.
Yes, we've run into that before. I hate the idea of making all of our
structure names unique just to work around a bug in a tool but that may be
what it takes... :-(
> 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.
Weird.
/D
More information about the subsurface
mailing list