New bug/crash from 15 days with new ES release

Hex

@darknior To disable PowerSaver

Settings > Other Settings > PowerSaver Modes > Disabed

darknior

@herb_fargus Yes i know, i think the problem come after, when the keyboard shut down alone, i write it before. It use bluetooth. I don't know i'm like you, and i give the error line code.

@meleu I know that, i use all of that every day at this moment to work on my project.
I want to know how to update bluetooth only like write @pjft . For my part i update nothing. Only ES and core with the Retropi-setup

@Hex Ok thanks i will try this night to see if the pi crash or not. thanks

Because the problem was not only the crash and return to command line, it is that i must reboot the PI because i can never connect back the keyboard :(

Hex

Chances are that the problem stems from Bluetooth keyboard shutting down without informing ES.

Can you try booting into ES and then connecting your Bluetooth keyboard?

darknior

@hex I do it every day, and try it now, it do nothing when i take the keyboard on. It works fine and the PI don't crash.

My PowerSaver Modes was already Disabed ... i forgot this lol
I put it default to try. i don't know what are doing extended and instant options.

pjft

@darknior sorry, I wasn't suggesting you to update it - it was more a question of had you updated it recently, and whether that update would be causing the problems.

As I said, nothing really changed on the ES front that I'm aware of, though I can check tomorrow, so I'm not really sure why you'd only have started to observe this now.

Hex

@pjft Considering that he has PS options I am guessing he is running >v2.5

pjft

@hex I was referring to the Bluetooth drivers or OS, as I don't think anything changed in ES's InputManager, but maybe I'm mistaken.

darknior

@pjft From yesterday i activate the Power Saver option to default, my PI not crashing again.
I'll let it work like that several days to see ...

Hex

@pjft This is the first time that PS enabled solved a problem :)

@darknior The problem is present in ES. PS enabled (default) might just be hiding it due to the wake ups and sleeps. Try reproducing it using PS disabled. If you are able to reproduce it consistently then we have a bug.

ttusoulfan

so i have been having a similar issue,except that when i go to install the roms it gives the a similar error.

darknior

Ok @Hex . Tonight i let it with the option enable, and if it not crash, tomorrow i will disabling it again.
But how to help you to repair it ? Can i have some logs ?

Hex

Do not connect any bluetooth devices while testing. I will not need logs as the error is an assert failing. So I can study it based on if it fails due to PS.

Can you tell me if you have screensaver enabled? and of what type?

ChauncyBlack

I can confirm this freezing during idle is caused by a recent emulation station update. I'm running on a combination of RPi3, Retropie 4.2, a known good SD card, and 2 Logitech wireless Rumblepad 2 joysticks. The system had been running flawlessly until my most recent updates of installed base packages (via apt-get update/upgrade), kernel (via rpi-update, currently at 4.9.45), and Retropie packages (via retropie_setup.sh), about a week ago (around August 20 or so). Previous full system update took place around end of June or beginning of July, and had been running fine. Once this freezing behavior started, I thought maybe the update process had corrupted the file system (as it has happened to me before), so I did a completely clean install using the 7/5/17 raspian lite image (last official Jesse release) and a manual install of the retropie script (git clone, etc.). The problem immediately reappeared.

I am using a wired network connection; wifi is on but unused. Bluetooth is on, but no devices are connected. If left idle after booting into emulation station, the system will soft-hang in about an hour, with video and joysticks becoming unresponsive. If I attempt to log in via ssh, the terminal appears to hang, but I can Ctrl-C out of the hung logon process and get a prompt. A dmesg query returns a number of repeated warning about a hung kworker thread being unresponsive for over 120 seconds. That repeats in the log 4 or 5 times, and then the log ends. The process id of the hung kworker thread changes every time. A query with "journalctl -p 3 -xb" gives similar error messages. I haven't been able to find anything else in the logs. At this point in the process, if I attempt a "sudo reboot", my terminal session terminates, but the RPi never actually reboots.

I have found that if I restart the system and quit out of emulation station to the command line, the system remains responsive and functions as expected (e.g. I can login via terminal normally, I can reboot, and dmesg and journalctl behave and expected) and has done so for about six hours since my last reboot.

Hope that helps.

pjft

The file in question hasn't been changed since April, and it has been only for minor maintenance issues. :/

Unless it'd be related to something with Power Savings (which I'm not clear that it would, given the reports from @darknior ), we might be on the wrong track here.

@ChauncyBlack does this also happen if you disable Power Savings?

Sano

FYI , someone had similar errors 7 months ago (no PS at the time) :
https://retropie.org.uk/forum/topic/7744/repeatable-crash-w-bluetooth-error

Could it be related to SDL ?

pjft

@sano My bet is that it is indeed related to ES input management via SDL or the underlying OS drivers, and has been there for a while now. But without hard evidence it's hard to narrow down what may be affecting this.

Sano

According to @bmn001 post, it was only happening when he powered off his controllers after exiting a game, but before full ES reload.

Just a guess, could be totally wrong but that seems logical :
Without knowing the code, we could assume that the function crashing (AddJostckByDeviceIndex ?) has problem if a BT device disappears right before the call.
If it's right, that could at least tend to prove that 7 months ago this function only was called during ES launch, and is now called on a more regular basis.

Edit : of course this won't narrow the bug reasons, but would prove it was already existing, and explain why it seems to happen more frequently...

pjft

This is only called in Window::init(), specifically in InputManager::getInstance()->init();.

This function is called at launch, and every time returning from a game back into ES (where we re-initialize the Window object).

The code is:

int numJoysticks = SDL_NumJoysticks();
for(int i = 0; i < numJoysticks; i++)
{
	addJoystickByDeviceIndex(i);
}

and then the assertion is

assert(id >= 0 && id < SDL_NumJoysticks());

So, reading the code:

id is always >= 0 (it is the iin the cycle)
so this must be failing because, at some point, id is >= to the SDL_NumJoysticks() returned.

Now, this is an awful thing to test or review, as the cycle by definition on runs for i = 0to i < SDL_NumJoysticks() so it means that sometime during the cycle the number of joysticks being returned by SDL is being reduced.

An extra layer of logging there would certainly help troubleshoot this.

Also, if one of you experiencing this could SSH into the Pi after it crashes and retrieve the content of ~/.emulationstation/es_log.txt (or, actually, after restarting, ~/.emulationstation/es_log.txt.bak should be the backup of the previous session if you're on 2.6.0) it may be helpful.

Hex

@pjft I think this is a one time thing. The bluetooth controller must have disconnected at the exact time when it was processing this loop and caused a crash. If @darknior can reproduce this even once then we might be able to bisect it.

pjft

@hex my suggestion is that this is not really new, though, but certainly keen on hearing more about it.