Last version 2.5.0 often crashes with huge memory usage

[schluckspecht]

Hi

in the past AbracaDABra worked without any problems, neither with the RTL-SDR dongle nor via rtl_tcp. System = Windows 11.
But since the last update to 2.5.0 often the Windows freezes with "no memory available", although my system has 16 GByte. (Intel i9 on a Lenovo Tiny PC) . The last time I saw this I could see via task manager, that the AbracaDABra consumed nearly 30 GByte of memory that caused the Windows to swap the memory on the SSD and then to crash.

[KejPi]

That is very bad, thanks for reporting.
For sure I do not have this problem on macOS and nobody else has reported it so far. I have few questions:

1. How long does this take to happen? Is it after hours of listening or within tens of minutes? Could you please try to monitor memory consumption from the start? Does it start to grow immediately? I do not have W11, but on Windows 10 it uses typically < 200MB.

2. Are there specific steps to reproduce this behaviour?

3. Does it happen with all ensembles of with specific one?

4. Could you please try to disable SPI application is setting to see if it still happens.

EDIT: I am just thinking if it is related to #136. If you are interested, I can share development version with fix on #136 to see if it helps for you too. Send me an email if you want to try.

[andimik]

I can't confirm it. In the past days I was working on Win 11 for several hours without problems.

[KejPi]

I am afraid there is some hidden problem on W11, issue #136 was also reported by one user while other stated it does not happen.

[schluckspecht]

It seems to happen for all ensembles and in the mode with USB SDR dongle directly or using rtl_tcp on an raspberry remotely.
If you could share the deployment version I would try it again.

[KejPi]

I can share the development version by email. I do not want to make it publicly available yet. My email address is in About dialog of the application.

[schluckspecht]

I wrote you an email.

Regards

[KejPi]

Lasted development build shared, please report the status here.

[schluckspecht]

Thank you. I am now several days not at home, I will test it when l'm back.Regards Friedhelm Von meinem iPhone gesendetAm 04.07.2024 um 08:51 schrieb KejPi ***@***.***>: Lasted development build shared, please report the status here. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[schluckspecht]

The problem is still there. Even the fixed version is still running after closing the application and consuming 10 GBytes of memory, and raising and raising. To prevent that the PC crashes I killed this process with the tast manager.

[KejPi]

Thanks for the test.
Unfortunately I do not know how to fix it because I cannot reproduce any problem under Windows 10.
This is how it looks like on Windows 10 after 7 hours of continuous reception:

What was the last working version?
Can you disable SPI application to see if it happens too?

[schluckspecht]

What is the " SPI application" ?

[KejPi]

[schluckspecht]

It did not help. As long as Abracadabra is running, everything is fine. Before closing it the foreground process (mentioned as "App") in the German windows is running fine, using only about 80 KByte. After closing the app it becomes a background process using more and more memory. At the end the PC will crash if you do not kill this background process manually.

IMG_0992.MOV

[schluckspecht]

The official and you developer version behave the same way, but the developer version has an additional bug: It often does not start or it takes about 10 seconds to start. the official last version starts immediately, but both a suffering from this memory consuming zombie process after stopping the application.

[KejPi]

OK, so we finally move forward. So to sum it up: Application runs without problems but when yoiu try to stop it, it is not stopping but instead it keeps running and eating memory. But the window disappears, correct?

And the problem happens when you decode from RTL-SDR USB stick directly connected to W11 PC as well as when application processes data from RTL-TCP source, correct?

Could you please try to make some recording and then try to play the recording and exit the application while it plays from the recorded file? Is the problem happening too?

Windows 11 behaves somehow inconsistently - there was another user stating that official version starts exteremly slowly
(issue #136) while it was fixed by development version :-(

What is the last application version that works without problems?

[schluckspecht]

Yes, you are right, the windows of the application closes correctly, but often, not always, this "zombie" will be created. Therfore, the first time I saw this I had started Abracadabra, then stopped it, did sonething different, started it again and then when the PC crashed I did not recognize, that the problematic background process is not caused by the actual running process but by the process started and stopped BEFORE. See this example in the screenshot: I started Abracadabra, stopped it, stated it again and you can see zombie and the running app in parallel. And of course you might think, the background process WAS the child process of the application, but is is not. It came from the last time before Abracadabra was running. But obviously this does not happen using the dongle directly, only with the tcp method. Using the dongle direct method the process becomes a background process after closing it and then it dies correctly. I tested it now several times.
Because I often switched between with dongle and with tcp I THOUGHT it would happen in both cases, but OBVIOUSLY the zombie was created in THOSE cases I started it with tcp_rtl. After terminating you can not distinguish how the process was started simply with the task manager.

Example: Zombie and app running in parallel.

[KejPi]

Another interesting information, thank you! This narrows the problem. What was the last version working correctly?

EDIT: Do you have access to rtl-tcp server log? If yes, could you please share it to see what is happening when zombie runs?

[KejPi]

I have shared another development version by mail, please try and provide feedback. Thanks!

[schluckspecht]

The same behavior, using tcp_rtl the zombie is created after stopping the application. Where do you have older versions to check when the problem started?

[KejPi]

This is strange, I was somehow able to reproduce the issue on company laptop with Windows 10 and in high CPU load condition (but not on my build machine) and after the fix I did, I was no longer able to reproduce it. I was able to track the issue back to 2.3.5 so it is there for very long time. I have also fixed the the issue that app was sometimes not starting.
Older versions are available on Github release page (https://github.com/KejPi/AbracaDABra/releases)
Maybe I did a mistake when building the app, I will share updated build, if this is not helping then I do not know what to do next. I will check again on Monday.

If you have MinGW shell (or any terminal application that shows the output log), you can try to run the app from that shell to see the output log. In the case of zombie I saw endless output of single errror message.

[schluckspecht]

Now it works perfectly. :-) I tested both modes: tcp_rtl and dongle USB mode. Both is working. And the application seems to start much quicker and needs less memory during running: only about 45 MByte in case of tcp_rtl and about 55 Mbyte in case of USB dongle mode. After closing the application no zombie remains any more.

[KejPi]

That's a good new finally! Thanks for your feedback. I am closing the issue.