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