Invoice ninja desktop app freeze

I’m running v5.7.33-L127 desktop on a Ubuntu Linux computer (snap package 5.0.127), and it seems that the last upgrade (10 days ago) has a bug : the app freezes and does not want to close. In this situation a kill shuts down the app, and before the kill, app mem usage is stable at 2400M (whereas 130M at fresh start, with data cached !) and a cpu is 100% used by the app. I did not have this problem on v5.7.30-L126.
Any test I could run to help ?
Cheers !


Are you able to check if you see the same problem installing with Flatpak?

Also, do you have any ideas action causes the app to freeze?

It may help to disable the PDF preview on Settings > Device Settings.

No clue on why it freezes. It seems quite random. I installed v5.0.136 using flatpack and I’m running it. Initial memory is the same (140M). I’ll let you know if it freezes or not.

Here are the error messages sent when launching from a terminal using the flatpack command:

Gtk-Message: 12:09:45.618: Failed to load module "canberra-gtk-module"
Gtk-Message: 12:09:45.620: Failed to load module "canberra-gtk-module"

(invoiceninja:2): Gdk-CRITICAL **: 12:09:46.796: gdk_window_get_state: assertion 'GDK_IS_WINDOW (window)' failed

** (invoiceninja:2): CRITICAL **: 12:09:47.363: Failed to read XDG desktop portal settings: GDBus.Error:org.freedesktop.portal.Error.NotFound: Requested setting not found

** (invoiceninja:2): CRITICAL **: 12:09:47.368: Failed to read XDG desktop portal settings: GDBus.Error:org.freedesktop.portal.Error.NotFound: Requested setting not found
flutter: POST:

I have to admit I did not restart the session after install, and it may lead to desktop related messages according to flatpack.

Thanks for the info, please keep us posted.

The app is up for one day, the mem is ok (300M but I used docs), and so is the CPU usage. Usually I would have the freeze once a day. Next week will be a better test.

After a paiement from a customer and the creation of a quote sent by email (linked, not attached), no docs used, mem usage jumped from 300M to 930M. Flatpack v5.7.33-L136. I believe that’s a problem. Does this version include the pdf fix ?

The fix for PDFs is in 5.0.138.

It seems like converting a quote in invoice and sending it by email has a cost of about 40 to 50M in mem usage. I’ve done the test a few times.

Is the memory released by the app over time or does the memory increase remain?

It piles up.
Maybe it’s not completely app based, because on stream apps, my computer tends to pile up on memory. But Invoice Ninja is no streaming app, and the app did not consume as much memory before last update ( or I believe so).

OK, so it’s confirmed : two paiements created (already existing invoices), a quote created and a good 150M of added mem usage (1.1G total). I’ll run more tests on the next update.

Just to be clear… are you saying creating payment uses a lot of memory but other actions do not?

No, any activity increases memory usage.
Update for the v5.7.33-L138 version : the flatpack install is up for 10H, then computer goes to sleep mode, then up for another 10H, then sleep, and at wake up this morning mem usage is 1.4G. I shut down the app to put an end at this memory gluttony. Memory usage does not significantly raise when I put the computer to sleep and wake it up.

Any file (log) I could send to help you track the issue ?

I think the problem may be related to this issue.

OK, that would explain why the issue is the same whatever the install, considering flutter is common to both install, isn’t it ? I’m running ubuntu 20.04 on an intel proc. 24.04 should be the next install, we’ll see if flutter still causes problems.

Yes, that’s correct. I’d be curious to know if it helps.

So we can settle that, for now, a workaround is to restart the app if it freezes.

FYI… this issue was reported, maybe it’s the same problem you’re seeing?

This will be fixed in the next release.

Hi Hillel, thank you for the hint, but I’m not sure why it should be related. The mem thing is not a button/email/template problem ? Am I missing something here ?

The bug was trigger by custom HTML in the designs or email templates, I thought it may be related to the problem you’re seeing.