Master - saving to xml broken

[Geert Janssens]

Op zaterdag 3 december 2016 08:05:39 CET schreef John Ralls:
> > On Dec 3, 2016, at 7:46 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:> 
> > Op zaterdag 3 december 2016 16:34:13 CET schreef Geert Janssens:
> >> Op vrijdag 2 december 2016 14:30:19 CET schreef John Ralls:
> >>>> On Dec 2, 2016, at 12:53 PM, John Ralls <jralls at ceridwen.us> wrote:
> >>>>> On Dec 2, 2016, at 12:47 PM, Robert Fewell <14ubobit at gmail.com> wrote:
> >>>>> 
> >>>>> Just built master from
> >>>>> https://github.com/Gnucash/gnucash/commit/dd4b8a104d0f7ad2205407e8bf10
> >>>>> f
> >>>>> ee
> >>>>> c364c8127 and I still do not see the errors Geert is having. Added a
> >>>>> Customer and a Vendor and still only have one of each.
> >>>> 
> >>>> Bob,
> >>>> 
> >>>> Yes, I'm also not yet able to reproduce the duplicate vendor issue.
> >>>> Geert
> >>>> mentioned on IRC that he's using Fedora-25 so I'm building a new VM
> >>>> with
> >>>> that to test.
> >>> 
> >>> I can't reproduce it on Fedora-25 either.
> >>> 
> >>> The save problems and crashes on master I *can* reproduce, so I'm
> >>> working
> >>> on that.
> >>> 
> >>> Regards,
> >>> John Ralls
> >> 
> >> John,
> >> 
> >> I  can confirm your commits fix the save problems and crashes. Thanks.
> >> 
> >> As I appear to be the only one experiencing the other part of duplicate
> >> objects, I am digging further locally.
> >> 
> >> Using gdb, I found that all non-core objects are registered twice.
> >> Once they are registered as part of loading the app-utils module, which
> >> in
> >> turn loads the engine module which then loads the business modules.
> >> 
> >> The second time they are loaded because the python bindings load the
> >> engine
> >> module, triggering loading of the business modules again apparently.
> >> 
> >> I have no idea (yet) why this didn't happen before the backend rewrite
> >> was
> >> merged back in.
> >> 
> >> I suppose none of you have the python bindings enabled, which would
> >> explain
> >> why only I'm seeing this.
> >> 
> >> Geert
> > 
> > The easy one-line fix would be to test for engine_is_initialized == 1 in
> > gnc_engine_init_part2 just like in gnc_engine_init_part1.
> > 
> > I wonder though whether we'd want to move this up to gnc_engine_init in
> > general though. Do we want the init hooks to be run each time some code
> > calls gnc_engine_init or should they be called only once also ?
> 
> IMO we want to get rid of all of the dlopening and just link the convenience
> libraries like a normal program. That's a lot of work, though, so for now
> we should be loading only once.
> 
> Is the problem really the python bindings (src/optional/python-bindings) or
> the python console (src/python) that loads the python bindings?
> 
It's the console in src/python that triggers this.

I agree the dlopening should go and also this is for later.

During the introduction of c++ in the backend something changed which causes 
the engine initialization to be allowed to run twice.

I don't immediately find this and frankly I don't really care what it would 
be. In any case the engine should only be initialized once. I'll add the guard 
in the init entry point, being gnc_engine_init.

Geert