After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703427 - Memory leaks in Windows version of gnucash
Memory leaks in Windows version of gnucash
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: User Interface General
2.4.x
Other Windows
: Normal critical
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
: 734509 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-07-01 22:31 UTC by Tes
Modified: 2018-06-29 23:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screen shot of runtime crash message (10.95 KB, image/png)
2014-02-13 04:03 UTC, alixi
Details

Description Tes 2013-07-01 22:31:57 UTC
In 2012 I found by chance GnuCash Portable v2.4.11 among "Portableapps" applications (http://portableapps.com/).

I tested and liked it, but in the first tests I noticed the crashes. I did not
bother because I thought it was problem of my system and I planned to format my
PC soon or an update of Gnucash could correct the problem.

After that I've formatted my PC and now came a new versions v2.4.12 and 2.4.13 and when I take the use of Gnucash realized that the crashes still occur. It was when I decides fetch for your help instead of abandoning its use.

I have GnuCash (pt_BR) installed on a Windows XP (pt_BR) and a Seven (es_ES used how a RDP) and both suffer from the same problem that comes to occur with a frequency of several per section, approximately one every five minutes of interface continuous use. The bug does not occur if the GUI be without activity.

In the middle of my work GnuCash crashes and displays a message:

"Runtime Error!

Program: C:\Arquivos de programas\gnucash\bin\gnucash.exe

The application has requested the Runtime to terminate it in an unusual way."

The first attempts to take a screenshot fail displaying a msg saying:

"Not enough memory for this task.
Close one or more programs to Increase available memory and try again. "

After a few attempts I could take a screenshot (See Bug 698094 Attachments):

Screenshot of Crash Message captured in Windows Seven [https://bug698094.bugzilla-attachments.gnome.org/attachment.cgi?id=241616]

Screenshot WinXP Msgs Crash & Attempted to Capture Screen [https://bug698094.bugzilla-attachments.gnome.org/attachment.cgi?id=242477]

GnuCash Tracefiles Win7.rar 
[https://bugzilla.gnome.org/attachment.cgi?id=242297]

GnuCash Tracefiles WinXP
[https://bugzilla.gnome.org/attachment.cgi?id=241767]

I have 1.5GB that normally working at 60%.

Something very curious and suspicious occurs after I click on the Gnucash installer in my current systems WinXP and Win7:

After clicking the Gnucash installer a "Select Setup Language" box, is
displayed, if I click or manipulate the Drop-Down menu language selection or
move this box, it disappears subtly and after that, every time I click the
installer (Tested for 2.4.11, 2.4.12 or 2.4.13) the box appears and briefly
then immediately closes.

Occurred so I can only make the "Select Setup Language" box remains displayed
by running the installer from DOS. With the box displayed and without touching 
anything more, I click on the "OK" button and the installation continues
without further problems. Even run from DOS, if I click on something other than
"OK" button the box also disappears and the problem returns, it does not stays
longer displayed.

Apparently, any gnucash nanipulação that I do the Bug occurs after a certain time. I tested (used) 2.4.10, 2.4.11, 2.4.12 and 2.4.13 (currently in use) on Windows XP and Seven and all occurred Bugs:

After working to edit exchange rates doing right click on a transaction, click "Edit Exchange Rate" on pop-up menu, change the value of "Exchange Rate", click on "Exchange Rate:" button, click the "OK" button and press the "ENTER" key. After a time working the crashes occurred.

After working a bit and save without problems I went on "Content" (F1) read some threads, after some time I closed and open again when I got the lack of memory msg (See attached Screenshot - https://bug698094.bugzilla-attachments.gnome.org/attachment.cgi?id=244860), I clicked on it and Gnucash closed.

On 2013/06/22 I just opened the Gnucash (2.4.13) and went to do an import from a Android Gnucash exported OFX file while I corrected the settings of importing of some three pages of records the crashes occurred before I conclude all correction and prevented me from doing the import.

I also noticed that in the records account window if I keep moving the sidebar
scrolls up and down the memory occupied will increasing at a steep ramp up to
totally exhaust the memory.

I add that in both my WinXP and Win7 systems where occur the crashes I have no
problems with this gravity with no other program. Only Gnucash presents this
sensitivity, this instability and this fatal error. In a damaged system is not
only a program that suffers, is more than one or all, and it is unwise condemn
an entire system due to faulty in a single program.

To keep the report clean I only will add new information if requested.

Is there any solution to this problem?

Thank you
Best regards
Tes.
Comment 1 Geert Janssens 2013-11-26 14:25:48 UTC
Tes, on another bug report (bug 681907) someone pointed out that there were a couple of memory leaks in GnuCash that could quickly consume all available memory in some situations.

Could you test one of the more recent nightly builds and see of the problem happens there as well ?

You can find the nightly builds here:
http://code.gnucash.org/builds/win32/trunk/

To test:
- download a recent nightly build
- run the installer (it will replace gnucash 2.4.x on your system, but won't touch your data)
- run gnucash (this will use your data so make backups before!)

Important: this is still considered beta software, so please make a backup of your data file before you run any tests on it !
Comment 2 alixi 2014-02-13 04:03:09 UTC
Created attachment 268982 [details]
screen shot of runtime crash message
Comment 3 alixi 2014-02-13 04:11:07 UTC
Alixi here;

Regarding runtime crash every 5-7 minutes of use, or thereabouts on ver 2.6.1 

Last line of trace file:

* 18:43:33  WARN <Gdk> gdkpixmap-win32.c:279: CreateDIBSection failed: Not enough storage is available to process this command.

Running on Win 7 on an i5 chip in a Lenovo T510

This is quite frustrating. Thank you for any help.
Comment 4 Geert Janssens 2014-02-14 11:32:11 UTC
Alixi, thank you for your reply.

That log message still seems to suggest you run out of memory. How much RAM does your system have and how big is your data file ?
Comment 5 alixi 2014-02-17 03:38:59 UTC
Geert,

System reports:
2045 MB DDR3-SDRAM: 2.00 GB
1024 MB DDR3-SDRAM: 1.00 GB

Data file is small, I am just getting started setting up the chart of accounts. I did import a bank QIF file to start.  The most recent data file entry is 191 KB.
Comment 6 Tes 2014-02-26 22:30:08 UTC
Hello Geert Janssens,

I came back.
Thank you so much for your reply!

I became aware that v2.6.1 was released and I came here to give one more chance to GnuCash and experiment with this new version when I saw your reply.

Of course, I'll do the test you suggested. Give me a time to return with the results.

Thank you
Best regards
Tes.


(In reply to comment #1)
> Tes, on another bug report (bug 681907) someone pointed out that there were a
> couple of memory leaks in GnuCash that could quickly consume all available
> memory in some situations.
> 
> Could you test one of the more recent nightly builds and see of the problem
> happens there as well ?
> 
> You can find the nightly builds here:
> http://code.gnucash.org/builds/win32/trunk/
> 
> To test:
> - download a recent nightly build
> - run the installer (it will replace gnucash 2.4.x on your system, but won't
> touch your data)
> - run gnucash (this will use your data so make backups before!)
> 
> Important: this is still considered beta software, so please make a backup of
> your data file before you run any tests on it !
Comment 7 Tes 2014-03-03 15:43:11 UTC
Hello Janssens,

Follows the outcomes of the tests.

Crash can be generated just continuously moving the scrollbar up and down in the account register window and it was made for testing.

* Test on W7 with v2.6.1 (gnucash-2.6.1-2014-02-26-git-36853c2 +-setup.exe): 
Crash occurred after 3:39 min.

* Test on WXP with v2.4.13: 
Crash occurred after 3:21 min.

* Test on WXP with v2.6.1 (gnucash-2.6.1-2014-02-26-git-36853c2 +-setup.exe): 
Crash occurred after 4:34 min.

Observed that the issue "Language Checkbox subtly closing in the installation" did not occur anymore.

Observed that when we started testing, the used memory amount starts to climb in a steep ramp until stabilize next maximum and after while it is close to the maximum and continue to move the scrollbar the crash occurs.

Any more suggestions?

Thank You.
Regards
TES.
Comment 8 Geert Janssens 2014-03-08 17:43:08 UTC
(In reply to comment #7)
> Hello Janssens,
> 
> Follows the outcomes of the tests.
> 
> Crash can be generated just continuously moving the scrollbar up and down in
> the account register window and it was made for testing.
> 
> * Test on W7 with v2.6.1 (gnucash-2.6.1-2014-02-26-git-36853c2 +-setup.exe): 
> Crash occurred after 3:39 min.
> 
> * Test on WXP with v2.4.13: 
> Crash occurred after 3:21 min.
> 
> * Test on WXP with v2.6.1 (gnucash-2.6.1-2014-02-26-git-36853c2 +-setup.exe): 
> Crash occurred after 4:34 min.
> 
> Observed that the issue "Language Checkbox subtly closing in the installation"
> did not occur anymore.
> 
> Observed that when we started testing, the used memory amount starts to climb
> in a steep ramp until stabilize next maximum and after while it is close to the
> maximum and continue to move the scrollbar the crash occurs.
> 
> Any more suggestions?
> 
> Thank You.
> Regards
> TES.
Now this is useful information!

The increasing memory suggests a memory leak. And indeed, by simply scrolling up and down the vertical scrollbar in a relatively large register I can see this behaviour as well on my Windows XP test box. Clearly a memory leak. Closing the register page doesn't recover the memory.

A similar leak can be observed by scrolling up and down in the Account Hierarchy page.

I have tried to reproduce this on my Fedora 20 system as well, but it doesn't happen there at all. The memory hardly moves while scrolling up and down. I can't generate an increasing memory trend at all no matter how long I move the scrollbar up and down.

So we'll have to dig into the Windows specific code. I haven't managed to set up any profiling tools on that platform yet unfortunately.
Comment 9 Tes 2014-03-15 20:43:40 UTC
(In reply to comment #8)

Hello Janssens,

Thanks to God for you have succeeded reproduce the issue!  :)

All the windows XP and windows Seven community thanks and looks forward to the solution.

Thank You.
Best Regards
TES.
Comment 10 Geert Janssens 2014-08-09 08:40:50 UTC
*** Bug 734509 has been marked as a duplicate of this bug. ***
Comment 11 Gunter Kramp 2014-12-29 16:56:44 UTC
I tested this behaviour on Windows XP SP3 with Gnu Cash GnuCash 2.6.3 (git Version 166cbb7+ am 2014-04-01 )
Got the same result of a crash after appr. 5 Minutes while scrolling up and down in the accounts overview.
Same while trying to import transactions with aqbanking.

Will try the newest stable GnuCash 2.6.5
Comment 12 Gunter Kramp 2014-12-29 17:23:59 UTC
with GnuCash 2.6.5 (git Version 23d0f79+ am 2014-12-19)
the Bug does not uccur while scrolling the accounts list.
Memory usage shows a flat line instead of an incline in the XP Task manager.

Thanks to all involved in making Gnu Cash and fixing this bug!!

I will now continue my work and hope importing transactions works now again as well.
Comment 13 Tes 2015-01-10 21:33:14 UTC
Hello all,

Solve this Bug is work for developers, but I solved my issue because I learned to work around this bug.

It all seemed dead here and it seemed that nobody was interested in this Bug. The manifestation of someone here encouraged me to share this information here.

I have found that the cause of this bug is the configuration the amount of colors. When for some reason we need to set the amount of colors to 16bit Bug occurs. When set to 32bit Bug no longer occur.

XP allows 16bit color and the XP above OSs (W7, W8, W8.1) do not allow 16bit color. So the CRASH occurs on XP and other OSs accessed via RDP by XP and does not occur in most other OSs.

Sometimes that I tried, I did not find the GNUCash minimum requirements.

Currently I use local (No RDP) W8.1 updated and it does not have this issue, but in my XP, follows everything as before. 16bit Color = CRASH.

Dear Gunter Kramp,

You can thank the developers but not for the solution of this bug because it has not yet been resolved, but we may be optimistic we can continue paying homage to Bug on their birthdays! :)

Thank You.
Best Regards
TES.
Comment 14 Geert Janssens 2015-01-18 15:30:39 UTC
(In reply to comment #13)
> Hello all,
> 
> Solve this Bug is work for developers, but I solved my issue because I learned
> to work around this bug.
> 
> It all seemed dead here and it seemed that nobody was interested in this Bug.

It was not so much a lack of interest rather than a lack of clues on how to fix this :(
My Windows (development) knowledge is very limited as I don't work on Windows natively. The same goes for the single other developer who invests in the Windows build of GnuCash. There is nobody on the development team that uses gnucash natively on Windows which limits what we can do unfortunately.

> The manifestation of someone here encouraged me to share this information here.
> 
> I have found that the cause of this bug is the configuration the amount of
> colors. When for some reason we need to set the amount of colors to 16bit Bug
> occurs. When set to 32bit Bug no longer occur.
> 
This is very valuable information.

> XP allows 16bit color and the XP above OSs (W7, W8, W8.1) do not allow 16bit
> color. So the CRASH occurs on XP and other OSs accessed via RDP by XP and does
> not occur in most other OSs.
> 
> Sometimes that I tried, I did not find the GNUCash minimum requirements.
> 
> Currently I use local (No RDP) W8.1 updated and it does not have this issue,
> but in my XP, follows everything as before. 16bit Color = CRASH.
> 
Do you mean that GnuCash 2.6.5 still leaks memory on Windows XP if colours are set to 16bit ?
Comment 15 Tes 2015-01-20 18:37:07 UTC
(In reply to comment #14)

Hello dear Janssens,

> It was not so much a lack of interest rather than a lack of clues on how to fix
> this :(
> My Windows (development) knowledge is very limited as I don't work on Windows
> natively. The same goes for the single other developer who invests in the
> Windows build of GnuCash. There is nobody on the development team that uses
> gnucash natively on Windows which limits what we can do unfortunately.

I have great respect and great admiration for you and for Stimming and by yours excellent work.

I had to show you my frustration which is also that of any other Reporter which is a long time without any return. If there is no return, neither developers nor nobody else, the feeling we have is abandonment is that there is lack of concern, lack of interest, we do not know what's going there.

I suggest that developers who want to prevent Reporters think wrong thus, to provide periodic returns.

I did not want to offend him but to express my feelings and produce some return, preferably, a good return!

Please, accept my most sincere apologies.

> Do you mean that GnuCash 2.6.5 still leaks memory on Windows XP if colours are
> set to 16bit ?

I said that based on the following facts:

* There was no manifestation yours here saying that something had been done to resolve this bug.
* The last information of yours I have is "I have not managed to set up any profiling tools on que platform yet".
* I still used the v2.6.3 on XP.
* I had not yet tested v2.6.5 on XP.

Therefore, it is concluded that, or the bug was not resolved, or if it was, it was by accident and not intentionally.

Now, I tested the v2.6.5 on XP with 16bit Color for 10 minutes, and, to our delight, THERE WAS NO CRASH!
The memory used showed a flat line.

If the bug was not intentionally resolved, it is possible that it will occur again.

For now, for me this Bug is solved !!! :)

Many, many thanks to everyone who dedicated themselves to resolve this bug especially you dear Janssens.

Thank You.
Best Regards
TES.
Comment 16 Geert Janssens 2015-02-07 16:03:45 UTC
Thanks you for testing this and confirming that the crash is gone. Believe me that's a great relief for me too !

I am pretty sure this fix is a positive side effect of recompiling all the gnome dependencies during the 2.6.4-2.6.5 release cycle. We have been using precompiled libraries for years. It appears now however that these precompiled libraries had all kinds of subtle problems, ranging from poor performance to memory leaks.

Several of these appear to have been fixed by John's effort to recompile the libraries in our own build environment. This way we can be sure the libraries are compiled with the same compiler version and options.

Thanks again for your patience and apologies for all the frustration this has caused over the years.
Comment 17 John Ralls 2017-09-24 22:42:20 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 18 John Ralls 2018-06-29 23:17:09 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=703427. Please update any external references or bookmarks.