Python bindings, Transactions, warnings and crashes

Mark Jenkins mark at parit.ca
Mon Aug 2 15:12:03 EDT 2010


Daniele Varrazzo :
> I have an issue with the transactions creation: if I add splits to the
> transaction before setting the currency I get a few warnings:
> 
>   * 18:04:09  CRIT <gnc.engine> [xaccTransScrubSplits()] Transaction
> doesn't have a currency!
>   * 18:04:09  CRIT <gnc.engine.scrub>
> [xaccScrubUtilityGetOrMakeAccount()] No currency specified!
>   * 18:04:09  CRIT <gnc.engine.scrub> [get_balance_split()] Can't get
> balancing account
> 
> and an empty "imbalance-CCY" account is created. OTOH, if i set the
> currency (or the description) on the transaction, the process
> segfaults
> 
>   * 18:10:07  WARN <GLib-GObject> instance of invalid
> non-instantiatable type `<invalid>'
>   Segmentation fault
> 
> I suspect the problem is known as the scripts in the examples
> directory are careful in setting the transaction details after the
> first split - I can live whit that once I know the problem.

This is a nice co-incidence. I was dealing with the same thing today.

What I used to do was not call any Transaction set functions until the
splits had been assigned; which would only result in critical warnings
and not segfaults.

Today I discovered how to avoid the warnings and crashes entirely
without such a forced order; one should use Transaction.BeginEdit() and
Transaction.CommitEdit() and do everything in between.

I'm going to update all of the
src/optional/python-bindings/example_scripts to do things that way in an
upcoming patch submission.

> Is there a way to avoid the creation of the imbalance accounts too?

There is Transaction.GetImbalance() and Transaction.GetImbalanceValue().
 These are actually what I was working with today and in order to test
them out with the Trading Account feature enabled I discovered that I
had to use Transaction.BeginEdit() and Transaction.CommitEdit() or else
I ended up with the problem of transactions being created to balance my
transaction out, and GetImbalance() not showing an imbalance at all.

So, if you apply the patch I just (re-)submitted, and first use
Transaction.BeginEdit() (see the example in the patch I submitted), you
can check to see if your transaction is imbalanced using
Transaction.GetImbalance() before finalizing with Transaction.CommitEdit().

> In the next days I may have more questions about the python bindings,
> and hopefully some patches to provide back. Is this the best ML to
> talk about the argument or there is something more specific?

I'd say it is. Ultimately, questions about the python bindings come down
to either:
 * how the GnuCash C api (which the python bindings wrap) should be
used. (best answered by developers)
 * requests for python binding enhancements/fixes. (which only
developers can pull off)

As one of the original python bindings contributors, and as someone who
has some funding right now to maximize their chances of making it into
2.4, I personally try to keep an eye out on both gnucash-devel and
gnucash-user for python binding questions. I have specific filters that
look for traffic to those lists with python in the subject line, which
helps me pick them up out from all the other list traffic.

Let me know if my patch for GetImbalance(), GetImbalanceValue(), and the
new example script help.


Mark Jenkins
Member ParIT Worker Co-op

cc Scott
cc fellow members


More information about the gnucash-devel mailing list