I have fixed the report – but don’t know why it was broken.  I am idly curious 
why the first approach failed, mostly in case I have drawn away from some 
boundary condition that I will meet again in a few years’ time as the records 
grow!

 

1.       Is there a fixed amount of stack space for a gnucash report on the 
windows 10 platform? (or similar limited system resource)?

2.       Can the code of my report be causing memory leakage, and what steps 
are required to manage this in gnucash/scheme?

3.       Could the autosave thread have interfered with the report thread?

4.       Is autosave delayed while a report is running?

5.       Are queries cached in gnucash using the standard backend - so that 
they are returned faster?

6.       Can any other gnucash thread -  lock a transaction, memory etc. etc.?

 

If you’re interested, here’s the background.

 

Having got deeper I discovered the hang was not caused by destroying splits as 
I first thought (e.g. I commented out the xaccDestroySplit).  It still froze on 
code similar to 

 

(let (      (all_ accs (xaccAccountGetDescendants (root))))

(for-each (lambda (split)

(let* (    (name            “fred”)

(count          (set! count (1+ count)))

(func             (lamda (acc) (equal? (xaccAccountGetName 
(xaccAccountGetParent acc)) name  )))

                (don’t-care    (gnc-warn "before suspect code "))         

                                                (accounts      (filter func 
all-accs))

                                                (don’t-care    (gnc-warn "after 
suspect code"))

                                                (acc                  (find …. 
accounts)…..

 

Etc.

 

It worked as expected for the first 700ish passes of 3000, until it freezes.  
Surprisingly, as I added and removed diagnostic code, the last successful 
loop/split before the hang varied on subsequent runs as did the precise place 
where it freezes.  Most of the time though it freezes between the two warns – 
but not always on the same split.  

 

The apparently inconsistent behaviour makes me wonder about memory management 
issues and thread competition – rather than some particular property of a 
specific split.  

 

The work-around.  I avoided the hang by fetching and  filtering the children of 
a specific account inside the loop, rather than the code as you see it (fetches 
all accounts once outside the loop and filters per pass).   Both code 
strategies achieve the same outcome with different overheads.  With this one 
change the report prints (at least so-far).       

 

Steve

 

 

 

-----Original Message-----
From: John Ralls [mailto:jra...@ceridwen.us] 
Sent: Monday, 7 October 2019 4:42 AM
To: Steven Bruniges <steven.bruni...@gmail.com>
Cc: Gnucash Users <gnucash-user@gnucash.org>; GnuCash Developer 
<gnucash-de...@gnucash.org>
Subject: Re: [GNC-dev] [GNC] custom report freezing - work done gets lost.

 

You mean why does it hang instead of crashing? Possibly because the memory was 
reallocated back to the program for something else and the attempt to free the 
splits is freeing whatever that is and that's resulting in a hang. 

 

But why would a report create or delete splits or transactions? A report should 
be describing the book as it is, not changing it.

 

 

Regards,

John Ralls

 

> On Oct 6, 2019, at 2:36 AM, Christopher Lam < 
> <mailto:christopher....@gmail.com> christopher....@gmail.com> wrote:

> 

> Ok forwarding to people who have better idea.

> 

> ---------- Forwarded message ---------

> From: Steven Bruniges < <mailto:steven.bruni...@gmail.com> 
> steven.bruni...@gmail.com>

> Date: Sun, 6 Oct 2019 at 09:34

> Subject: Re: [GNC] custom report freezing - work done gets lost.

> To: Christopher Lam < <mailto:christopher....@gmail.com> 
> christopher....@gmail.com>

> 

> 

> Have identifies my issue.   Was calling xaccTransDestroy with pointers to

> splits that had been destroyed in an earlier loop.  Not sure why this 

> locks up gnucash.

> 

> Steve

> 

> On Sun, 6 Oct 2019, 22:20 Christopher Lam, < 
> <mailto:christopher....@gmail.com> christopher....@gmail.com>

> wrote:

> 

>> Sorry without specific detail what you're trying to do, we can't help.

>> Moreover this is open-source, including open-source help requests.

>> cc: devel

>> 

>> On Sun, 6 Oct 2019 at 05:58, Steven Bruniges 

>> < <mailto:steven.bruni...@gmail.com> steven.bruni...@gmail.com>

>> wrote:

>> 

>>> Not even sure it’s the session I want to save (hoping for the 

>>> function underlying the save option in the file menu).

>>> 

>>> 

>>> 

>>> Working through a process of elimination.  I’d love to find the 

>>> transaction that’s triggering this behaviour.  If I can reduce the 

>>> 3000 splits to something more manageable I may find the issue?

>>> 

>>> 

>>> 

>>> The report typically hangs and Task manager shows the system is at rest.

>>> If I modify the code to open warning dialogs it crashes after a 

>>> number of loops.  No output in the trace file.  Either way, I get no 

>>> diagnostic feedback.

>>> 

>>> 

>>> 

>>> Its possible I am retaining pointers to a deleted split, or running 

>>> across a temporary split that was never finished, etc, (or both).

>>> 

>>> 

>>> 

>>> On that point, is there any test if a split is deleted?

>>> 

>>> 

>>> 

>>> Steve

>>> 

>>> 

>>> 

>>> *From:* Christopher Lam [ <mailto:christopher....@gmail.com> 
>>> mailto:christopher....@gmail.com]

>>> *Sent:* Sunday, 6 October 2019 6:17 PM

>>> *To:* Steven Bruniges < <mailto:steven.bruni...@gmail.com> 
>>> steven.bruni...@gmail.com>

>>> *Cc:* GnuCash users group < <mailto:gnucash-user@gnucash.org> 
>>> gnucash-user@gnucash.org>

>>> *Subject:* Re: [GNC] custom report freezing - work done gets lost.

>>> 

>>> 

>>> 

>>> qof-session isn't currently accessible to scheme. Why do you think 

>>> you'll need to save session?

>>> 

>>> 

>>> 

>>> It may help to publish your report on Bugzilla or devel mailing list.

>>> 

>>> 

>>> 

>>> On Sun, 6 Oct 2019, 12:53 Steven Bruniges, 

>>> < <mailto:steven.bruni...@gmail.com> steven.bruni...@gmail.com>

>>> wrote:

>>> 

>>> Hi.

>>> 

>>> 

>>> 

>>> Have a custom report that appears to be freezing, so I have to halt it.

>>> It

>>> in a 3000 item loop, and I suspect the overheads are growing as it 

>>> progresses.

>>> 

>>> 

>>> 

>>> I want to save the book periodically, which if nothing else will 

>>> simplify the work in a future run.

>>> 

>>> 

>>> 

>>> Is there a function I can call  that is like "gnc-book-session-save"?

>>> 

>>> 

>>> 

>>> Steve

>>> 

>>> _______________________________________________

>>> gnucash-user mailing list

>>>  <mailto:gnucash-user@gnucash.org> gnucash-user@gnucash.org

>>> To update your subscription preferences or to unsubscribe:

>>>  <https://lists.gnucash.org/mailman/listinfo/gnucash-user> 
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user

>>> If you are using Nabble or Gmane, please see 

>>>  <https://wiki.gnucash.org/wiki/Mailing_Lists> 
>>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.

>>> -----

>>> Please remember to CC this list on all your replies.

>>> You can do this by using Reply-To-List or Reply-All.

>>> 

>>> 

> _______________________________________________

> gnucash-devel mailing list

>  <mailto:gnucash-de...@gnucash.org> gnucash-de...@gnucash.org

>  <https://lists.gnucash.org/mailman/listinfo/gnucash-devel> 
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

 

_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Reply via email to