dive profile points

Miika Turkia miika.turkia at gmail.com
Wed Mar 11 23:39:27 PDT 2015


On Thu, Mar 12, 2015 at 12:25 AM, Lubomir I. Ivanov <neolit123 at gmail.com>
wrote:

> hey Miika,
>
> this prevents deletion of divepoints on a newly added dive completely
> (Log -> Add dive):
>
> http://trac.subsurface-divelog.org/changeset/4f9705f3f54fc14d6b38123160f07015c41f3519/subsurface
>

It is also related to 6f795a0059f5b1540d62bab30bc62422717420bb


> new bug report:
> http://trac.subsurface-divelog.org/ticket/846
>
> i can't really reproduce what the comment describes:
> * If we end up having divepoints that are not within the dive
> * profile, we need to just skip the removal to prevent
> * crashing due to index out of range.
>
> i always get this for any dive:
> rowCount() == divepoints.count()
> can you provide steps?
>

The bug was not really deterministic. When moving a divepoint around and
releasing it, it was occationally possible to drop the point so it was not
on the profile. Bug 784 might give a better idea of how to reproduce, even
though it was not that obvious.


> but also, shouldn't the check be like so?:
> if (rowCount() > divepoints.count())
>

Sounds about right, if the normal case is they are the same. I do not
recall the exact details and cannot dig into this at the moment.


> i wonder how is it even possible for divepoints to not be a part of
> the dive profile.
>

I couldn't figure out why the bug happened, but it is worth a try to debug
it further/again.


> if there another underlying bug here perhaps we should remove the
> check and fix that instead...
>

Absolutely, if someone is just able to figure out how this can happen in
the first place.

miika
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20150312/7b6473eb/attachment-0001.html>


More information about the subsurface mailing list