Emulationstation crashed and Cannot allocate memory on pi4

quicksilver

@ByteThis I havent done any manual edits so I dont think its the same issue.

mitu

Can you also upload the downloaded media from ~/.emulationstation/downloaded_media/psp ? I though they were in your system folder, but they're not. For some reason, trying to scrape the filenames in the gamelist only gets the info for about 1/3 of them.

quicksilver

@mitu I linked that in my above post already

mitu

Sorry, I realized during testing that the images are present in the upload, it's just the gamelist file that references the different location. You can delete the uploaded files.

Unfortunately, I still can't reproduce the crash. Obviously, my games are 'fake' files, but launching them starts PPSSPP. I tried with both themes (Carbon/Nostalgic-Neo).

quicksilver

@mitu thanks for trying. This issue is really puzzling. There must be something else unique to my setup causing the issue. I think I'm going to have to re-image.

rejesterd

This is a memory leak related to launching PSP games from emulationstation. I can't reproduce the crash like you're seeing, but I can definitely see RSS usage increase consistently after repeatedly launch a PSP game. You can confirm this by running..

while :; do ps --sort -rss -eo rss,pid,command | grep emulationstation\/emulationstation$; sleep 1; done

The first column of output is the RSS usage. For me, it consistently keeps going up when I re-launch the same psp game over and over. That doesn't happen with other games (PSX, for example).

Not sure why you're seeing a crash so early, but maybe your ES RSS usage is growing beyond whatever the configured limit is.

quicksilver

@rejesterd Im guessing that is a different issue. I just had another crash, this time launching a dreamcast game. I had gameslist view set to detailed. I cant seem to nail down what is causing this issue. Can you tell me what firmware/kernel version you are on by running:

uname -a

rejesterd

Linux raspberrypi 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux

But yeah, if it's also happening with dreamcast, then the issue is probably not specific to PSP.. maybe it's just that the leak with ES & PSP makes the crash occur faster.

quicksilver

@rejesterd Im on 4.19.97-v7l+. Im going to try rolling back and seeing if that helps. If not I guess Im going to have to re-image...

mitu

@quicksilver - what 4b model do you have ? If it's memory leak related, might not happen so fast on my model (the 4Gb one).
4.19.97-v7l+ is the latest/current Raspbian kernel version, but it was released more than 1 month ago (2020-02-13 was the installation date on my system).

rejesterd

Yeah I'm also using the 4g model, for reference.

quicksilver

@mitu mine is the 2gb version. If you are also on the same kernel then I guess we can rule that out. I guess that makes sense since my pi 3 which was rock stable now has stability issues and its on raspbian stretch. The only two things I changed on my pi 3 were switching to nostalgia-neo and using my latest skyscraper gameslist modifications. So I feel it has to be related to them in some way. I might try restoring skyscraper gameslist default settings and testing that out, maybe its a memory related issue.

rejesterd

Even 2g should be plenty, but I would at least confirm how much RSS emulationstation is using (especially when the crash happens).

Efriim

What is the resolution you have set with runcommand psp and dreamcast? And which display port are you using?

I got 4.5.4 installed over raspbian. Using outer hdmi port. Default runcommands.
Inner hdmi port has got a tty (I'm not so sure about the setup but ES doesn't display here), changing res just doesnt work for me and throws errors.

Did you try rolling back the kernel?

quicksilver

@Efriim PSP runcommand display is set to 720p Dreamcast is set to 1080p. Though I don't see how this would cause any issues. Emulation station crashes randomly on many different systems. Even going into retropie setup it occasionally crashes. I haven't rolled back my kernel yet because it looks like the version I'm using is stable for others. I'm undoing the changes I made in skyscraper as a last test. Everything else I have done, and the crashing continues. If this doesn't work I'm going to have to re-image.

Efriim

@quicksilver
No I don't know why it is either but I learn from your answers. Better to be on the same page. I think maybe it is allocating two buffers, or switches, 1 for each screen, there would be a better solution but maybe it is getting hung up on this.

I notice mine sort of slows down for 4-5 seconds after exiting a game, I don't have a lot of resources to load.

Have you checked the log at /home/pi/.emulationstation/es_log.txt ? This would probably tell you if it is a problem with resources.

quicksilver

@Efriim said in Emulationstation crashed and Cannot allocate memory on pi4:

Have you checked the log at /home/pi/.emulationstation/es_log.txt ? This would probably tell you if it is a problem with resources.

Yes I have checked the log but it doesn't show anything out of the ordinary unfortunately.

quicksilver

Just a quick update. I restored skyscrapers default artwork.xml and regenerated my gameslist.xml files. So far I have not experienced any crashing since yesterday. Im going to leave it this way for a bit before I draw any conclusions and will report back.

quicksilver

I re-imaged RetroPie 4.5.18 and added back the nostalgic-neo theme and my roms (which are on a USB drive) and ES just crashed. Im not sure what to do at this point. I have 36 systems (including favorites, all, and recent custom systems) with tons of games + a graphic heavy theme maybe this is simply too much for ES to handle.

mitu

Let's try to get a full backtrace. Going back to the instructions I posted earlier in the topic:

install gdb with sudo apt install gdb
exit EmulationStation and start a SSH session to your PI.
run from the command line (via SSH)

gdb -q /opt/retropie/supplementary/emulationstation/emulationstation
# at the gdb prompt
(gdb) set logging file /home/pi/es_crash.log
(gdb) run

wait for ES to crash
run from the gdb prompt:

(gdb) bt full #this should dump the crash log to the file
(gdb) q # exit

Post the crash file (/home/pi/es_crash.log) to pastebin.com.