Op zaterdag 3 december 2016 08:05:39 CET schreef John Ralls: > > On Dec 3, 2016, at 7:46 AM, Geert Janssens <[email protected]> > > 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 <[email protected]> wrote: > >>>>> On Dec 2, 2016, at 12:47 PM, Robert Fewell <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
