<p dir="ltr">(answering from phone)  I'll take a look at this today, location management is still buggy and I know that, plan is to make it stable today / tomorrow. <br>
</p>
<br><div class="gmail_quote">On Mon, Jun 1, 2015, 19:18 Linus Torvalds <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Current git version of subsurface doesn't work for me at all, and gets<br>
a SIGSEGV in the dive site management code.<br>
<br>
Am I the only one seeing this? SIGSEGV in dive_site_less_then().<br>
<br>
[ Side note, the horrible syntax failure of that function name annoys<br>
me too. "less than", not "less then". It hurts ]<br>
<br>
   Program received signal SIGSEGV, Segmentation fault.<br>
  0x0000000000651f08 in dive_site_less_then (a=0x3cbc340, b=0xc41) at<br>
/home/torvalds/src/subsurface/qt-models/divelocationmodel.cpp:6<br>
  6 return QString(a->name) <= QString(b->name);<br>
<br>
because 'b' is an invalid pointer (that 0xc41 is not valid).<br>
<br>
I'm now running Fedora-22, I'm wondering if that's the issue. New<br>
compiler showing new bugs? The call chain implies this comes from the<br>
sort() function and the iterators, called from<br>
<br>
    LocationInformationModel::update()<br>
<br>
Anybody?<br>
<br>
gdb is being singularly unhelpful, because gdb is a buggy piece of<br>
shit, and we have "struct dive_site_table" and a variable called<br>
"dive_site_table", and when I ask gdb to show "dive_site_table" (no<br>
"struct" anywhere), gdb gets all pissy and thinks I'm asking for the<br>
_type_. Christ, what a horrible nasty piece of software. I've seen<br>
this before, I think it's some gdb C++ name confusion.<br>
<br>
Hackign things up a bit, I see<br>
<br>
   (gdb) p *(struct dive_site_table *)0x0000000000a2b250<br>
   $2 = {nr = 281, allocated = 390, dive_sites = 0x3c009c0}<br>
<br>
so I have 281 of those dive_sites, but I'm wondering whether the issue<br>
is that we've done "beginInsertRows()" earlier, and it has perhaps<br>
already incremented the nr of entries? That would explain the "-1" in<br>
the std::sort() call, and might also explain why it SIGSEGV's (we're<br>
trying to sort things in between the beginInsertRows/endInsertRows, is<br>
the array perhaps not in a stable form there?<br>
<br>
              Linus<br>
</blockquote></div>