Bug #435642: Fix crash when editing results of a find

I finally got around to looking into this some more.  I think the problem is a
result of an interaction between gnc_split_register_redraw and
gnc_split_register_find_split when called from gnc_split_register_move_cursor
in split-register-control.c.  As the comment says, "redrawing the register can
muck everything up".  In particular calling gnc_split_register_redraw may
change the "transaction split" for some or all of the transactions if the
register is a "ledger" style register such as the one for find results.  This
causes the subsequent call to gnc_split_register_find_split to find the wrong
register row if the cursor class being found is CURSOR_CLASS_TRANS.  Whether
this causes a crash seems to depend on circumstances I haven't quite figured
out, but I have one test file that crashes 100% of the time in r17804.

This patch changes the way gnc_split_register_find_split works when asked to
find the transaction split for a transaction.  It assumes that any transaction
can only have one such split and returns as soon as it finds a row containing
it.  If you think this is wrong, let me know and I'll try something else.

Patch by Mike Alexander.
BP

git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash/trunk@17853 57a11ea4-9604-0410-9ed3-97b8803252fd
This commit is contained in:
Christian Stimming 2009-01-28 21:08:44 +00:00
parent 2d851151df
commit 6cc9146e13

View File

@ -221,10 +221,20 @@ gnc_split_register_find_split (SplitRegister *reg,
cursor_class = gnc_split_register_get_cursor_class (reg, vc_loc);
if (t == trans)
{
found_trans = TRUE;
if ((cursor_class == CURSOR_CLASS_TRANS) && (s == trans_split))
if (cursor_class == CURSOR_CLASS_TRANS)
{
found_trans_split = TRUE;
if (find_class == CURSOR_CLASS_TRANS)
{
if (vcell_loc != NULL)
*vcell_loc = vc_loc;
return TRUE;
}
}
}
if (found_trans && (s == split) && s)
{