Book Closing in HEAD kills objects in a "bad" order, corrupts
warlord at MIT.EDU
Wed May 26 09:26:16 EDT 2004
Linas, thanks for the affirmation. I'll add some code to handle this
case, in which case we don't really need to worry about the order
anymore (at least for book_end().
We may still need to worry about it for book_begin(), but I'm not sure
how to handle that in the current QOF Object code. The order seems
somewhat dependent on the order-of-registration of the object modules,
linas at linas.org (Linas Vepstas) writes:
> On Tue, May 25, 2004 at 11:52:08AM -0400, Derek Atkins was heard to remark:
>> I'm not 100% convinced it's the order that matters... I'm thinking
>> that during book_end() the various objects should just free() themselves
>> of memory and not worry about keeping themselves balanced. In other
> Yes. I agree.
>> >> As you can see from the following trace this causes a memory access
>> >> failure because transactions are kept in balance even when we're
>> >> destroying the book, so it's trying to scrub against an
>> >> already-destroyed commodity.
> That's a bug
>> > Why do we need to scrub things we're just trying to get rid of?
> Don't need to that's a bug.
> It would be nice to do them in order too. The order should be:
>> > * Business objects / SX templates
>> > * Lots
>> > * Splits / Transactions
>> > * Accounts / Price-DB
>> > * Commodities
>> > * Book
>> > * Session state
> pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord at MIT.EDU PGP key available
More information about the gnucash-devel