On Fri, Nov 14, 2014 at 10:46:43PM +0200, Lubomir I. Ivanov wrote: > On 14 November 2014 19:57, Tomaz Canabrava <[email protected]> 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 _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
