Apps: SubGhz Playlist: Out of memory when playing large playlists

[laurazard]

Describe the bug.

Flipper crashes due to running out of memory if playing a playlist with 3k+ items (I haven't been able to get the exact number, but it crashes around file no. 649 afaict).

The actual behaviour is, the playlist gets loaded (takes a couple of seconds to load the playlist, while in the "no files" view, and then behaves appropriately) and then, at some point while running the playlist, the device crashes with an out of memory message.

Trying to load a large .sub file also causes a crash, which is why I resorted to generating a playlist for a bruteforce I'm doing on some of my own hardware – so maybe this is due to some memory leak with loading the .sub files, but I haven't confirmed one way or the other.

I'd expect to be able to play an arbitrarily higher number of files, as long as each of them are small enough that can be loaded/transmitted, which these are.

Reproduction

1. Open subghz playlist app
2. Load playlist with ~3k items (takes a couple of seconds)
3. Play
4. Wait...

Target

No response

Logs

https://gist.github.com/laurazard/ba2109091298f7997aae6878c30b66b5

Anything else?

No response

[Willy-JL]

Memory is already quite limited, and the subghz app saturates most of it by itself. I'm not entirely sure how the playlist app loads things, I will have to double check.

If it loads the whole list into ram, this makes sense as it's behavior, but it could be made to stream in from file rather than ram, like the badkb app does.

It is weird that in some cases it loads fine, but then crashes after playing for a while... if you found that behavior at the edge of what causes a crash just by loading, it might be a difference by a mere few bytes in the files that the playlist loads so then it can fit some of them but not others.

[laurazard]

If it loads the whole list into ram, this makes sense as it's behavior, but it could be made to stream in from file rather than ram, like the badkb app does.

It seems like this isn't the issue I'm running into, as (at least for ~3k) items playlists, as it loads the playlist fine even if it takes a couple of seconds. This will probably break at some point though, but only for larger playlists.

Re:

It is weird that in some cases it loads fine, but then crashes after playing for a while... if you found that behavior at the edge of what causes a crash just by loading, it might be a difference by a mere few bytes in the files that the playlist loads so then it can fit some of them but not others.

The files are generated by me, they all have the same number of bytes :( I've ran it again a couple of other times and it always crashed around the same item (649 the first time, 657 after, 653 after). I wonder if the files loaded aren't being free'd after being played and that's the limit at which the flipper runs out of RAM. I'm uploading the files I'm currently using to reproduce this issue, but to test this hypothesis:

I wonder if the files loaded aren't being free'd after being played and that's the limit at which the flipper runs out of RAM

I'll make a playlist with 10 files that amount to the same size as these ~650 put together and see if that replicates it.

---

Repro resources:

flipper_playlist_repro.zip

That contains a playlist and a bunch of .sub files which the playlist expects to be at /ext/subghz/repro_oom/

[Willy-JL]

also got the crash myself, but on a short playlist (4 items) after about 30 minutes of runtime, this prompted me to finally have a decent look at it

d034d72 fixes 2 missed free's in the app, hopefully thats the full extent of the issue and we wont need to look even deeper

let me know how it goes, ill test myself aswell

[Willy-JL]

i havent had any more issues thus far, issue seems fixed to me. let me know if thats not the case or you find more issues. marking as complete.