-
Notifications
You must be signed in to change notification settings - Fork 823
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Bug 799528 - Crash on account deletion (edit)
New function xaccAccountDeleteAllTransactions. Delete all transactions before deleting the account; simply deleting the splits during account destruction isn't safe. In the particular case of an imbalance account the transaction commit after deleting a split just makes a new one.
- Loading branch information
Showing
3 changed files
with
28 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bc7fafd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as per irc... how about the following? I think
priv->splits
will always be trimmed from the end properly when the last trans is destroyed?bc7fafd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has
the same UAF probleman invalidated iterators problem (because we can't trust the compiler to optimize that in a safe way) if there are two splits from the same transaction. I think the only way short of rewriting all of the QofInstance memory management (we'll get there one of these years…) is to deduplicate the transactions. Two easy ways are to use astd::unordered_map<GUID, Transaction*> transactions;
orstd::unique(std:sort(transactions.begin(), transactions.end())); //pseudocode, that wouldn't compile
. I was setting those up for profiling when I got distracted with bug 799565.bc7fafd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bc7fafd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, that's the dedupe approach. I think that
std::sort(transactions.begin(), transactions.end())
is sufficient: It will sort based on the pointer addresses. Since the only reason for the sort is to get the duplicates adjacent so thatstd::unique
will work there's no need to resort toxaccTransOrder
or evenxaccTransGetGUID
(which is a lot cheaper thanxaccTransOrder
).bc7fafd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deduplicating the vector took no measurable time with several thousand transactions, so no point in bothering with other methods.