Data corruption when saving dives in win daily 4.2.-457

Dirk Hohndel dirk at hohndel.org
Fri Nov 14 13:16:44 PST 2014


On Fri, Nov 14, 2014 at 10:46:43PM +0200, Lubomir I. Ivanov wrote:
> On 14 November 2014 19:57, Tomaz Canabrava <tcanabrava at kde.org> wrote:
> > Looks like a bug that I should look at. Will see.
> 
> i think i was able to find the cause, but the code is confusing me.
> 
> void MainTab::acceptChanges()
> ...
> // copy the cylinder but make sure we have our own copy of the strings
> free((void*)cd->cylinder[i].type.description); // <---------------
> 
> if the above free() call is removed the memory corruption is gone.
> 
> isn't it sufficient for that loop to simply be?:
> 
> for (int i = 0; i < MAX_CYLINDERS; i++) {
>     cd->cylinder[i] = displayed_dive.cylinder[i];
> 
> perhaps i don't understand the difference between 'current_dive' and
> 'displayed_dive'...

This is my code, not Tomaz'... I'll need to look at what's happening.
There is a bit of magic involved here :-/

The difference between current_dive and displayed_dive is very simple.

current_dive is a pointer to a dive in the dive_table - it's the dive that
is currently selected.

displayed_dive is a separate structure, not part of the dive_table. All UI
operations are supposed to only work on the displayed_dive and then get
either abandoned or copied over to the selected dive(s).

So when we switch dives, current_dive points to the new selected dive and
then that dive is COPIED into displayed_dive and that is shown. When you
then start editing, the edits are reflected in the displayed_dive (and on
the UI), but only copied into the dive_table when yuo acceptChanges()

Makes sense?

Now I'll try and figure out what's broken here...

/D


More information about the subsurface mailing list