Error after updating retropie-setup to 4.4.9 (a161774a)

DarishZone

Also got this error, even if i think is not releated to joy2key but a python script i use for bgm (guessing)
Could be useful for someone

mitu

@DarishZone The exception message from the picture was mentioned by @Efriim also and we've talked about this in the topic. If you have another error message you see, please add some info about it.

@psyke83 I did some small tests, it appears in the close_fdsmethod raises the OSError exception, most likely because of the closure of an already closed fd and it's probably during the TERM signal handler (hence the threading module reference).
I re-installed a 4.4 image, updated RP (including the fix from this topic) and the OS only and get this error after the 1st joy2key invocation with just the one SNES iBuffalo controller connected and configured.

psyke83

@mitu said in Error after updating retropie-setup to 4.4.9 (a161774a):

@DarishZone The exception message from the picture was mentioned by @Efriim also and we've talked about this in the topic. If you have another error message you see, please add some info about it.

@psyke83 I did some small tests, it appears in the close_fdsmethod raises the OSError exception, most likely because of the closure of an already closed fd and it's probably during the TERM signal handler (hence the threading module reference).
I re-installed a 4.4 image, updated RP (including the fix from this topic) and the OS only and get this error after the 1st joy2key invocation with just the one SNES iBuffalo controller connected and configured.

Thanks! I finally managed to reproduce the error, but only by running multiple concurrent instances of joy2key. Regardless, I think that this PR should solve the problem: https://github.com/RetroPie/RetroPie-Setup/pull/2655

Please test and let me know if this solves the issue to your satisfaction.

psyke83

@psyke83 said in Error after updating retropie-setup to 4.4.9 (a161774a):

@mitu said in Error after updating retropie-setup to 4.4.9 (a161774a):

@DarishZone The exception message from the picture was mentioned by @Efriim also and we've talked about this in the topic. If you have another error message you see, please add some info about it.

@psyke83 I did some small tests, it appears in the close_fdsmethod raises the OSError exception, most likely because of the closure of an already closed fd and it's probably during the TERM signal handler (hence the threading module reference).
I re-installed a 4.4 image, updated RP (including the fix from this topic) and the OS only and get this error after the 1st joy2key invocation with just the one SNES iBuffalo controller connected and configured.

Thanks! I finally managed to reproduce the error, but only by running multiple concurrent instances of joy2key. Regardless, I think that this PR should solve the problem: https://github.com/RetroPie/RetroPie-Setup/pull/2655

Please test and let me know if this solves the issue to your satisfaction.

In case it helps, this is the script I used to reproduce the error:

#!/bin/bash
SLEEP_TIME=$1
[[ -z "$SLEEP_TIME" ]] && SLEEP_TIME=1

function joy2keystart()
{
    __joy2key_ppid=$$ ~/RetroPie-Setup/scriptmodules/supplementary/runcommand/joy2key.py /dev/input/jsX kcub1 kcuf1 kcuu1 kcud1 0x0a 0x20 &
}

function joy2keystop()
{
    kill $(pgrep -f joy2key.py) 2>/dev/null
}

function joy2keytoggle()
{
    joy2keystart
    sleep "$SLEEP_TIME"
    joy2keystop
}

while true; do
    echo "loop"
    joy2keytoggle & joy2keytoggle & joy2keytoggle & joy2keytoggle & joy2keytoggle
done

Note that my i7 laptop required around 3-5 concurrent instances to trigger the warning, but the Pi could do reproduce it with just two.

DarishZone

@mitu said in Error after updating retropie-setup to 4.4.9 (a161774a):

@DarishZone The exception message from the picture was mentioned by @Efriim also and we've talked about this in the topic. If you have another error message you see, please add some info about it.

@psyke83 I did some small tests, it appears in the close_fdsmethod raises the OSError exception, most likely because of the closure of an already closed fd and it's probably during the TERM signal handler (hence the threading module reference).
I re-installed a 4.4 image, updated RP (including the fix from this topic) and the OS only and get this error after the 1st joy2key invocation with just the one SNES iBuffalo controller connected and configured.

My bad, probably i missed the part of topic where you talk about it.
Ive got only this and the joy2key error at the moment.

mitu

@psyke83 said in Error after updating retropie-setup to 4.4.9 (a161774a):

Please test and let me know if this solves the issue to your satisfaction.

That seems to work - there's no more exception shown on the terminal background. Thank you.

Efriim

Yay. So the fix ended up being on line 134? You don't have to explain, I wouldn't understand.

Unrelated, is there any chance that the runcommand button response will get fixed?
To break it down, it only responds to an input right after the pop-up/launching.png disappears. Making the delay entirely pointless, and just being difficult to invoke.

psyke83

@mitu said in Error after updating retropie-setup to 4.4.9 (a161774a):

@psyke83 said in Error after updating retropie-setup to 4.4.9 (a161774a):

Please test and let me know if this solves the issue to your satisfaction.

That seems to work - there's no more exception shown on the terminal background. Thank you.

Apologies - can you test this PR instead of the previous one? https://github.com/RetroPie/RetroPie-Setup/pull/2656

I think that this is a far more reliable solution that should hopefully clear up all remaining issues, but it needs testing to be sure I didn't overlook something. Thanks.

Efriim

@psyke83
I don't know, I managed to copy the edit on the first one with only a few lines. Is there an easier way to test it?

mitu

@Efriim You'll need to use git:

cd $HOME/RetroPie-Setup
git fetch origin pull/2656/head:test-branch
git checkout test-branch
# install the runcommand to copy files into place
sudo ./retropie_packages.sh runcommand

# test. To go back to normal repo:
git checkout master

EDIT: @psyke83 seems to work fine, the exception is - again - gone and I can see a daemonized joy2key in the list of processes. This is on the same PI, I don't have access to an Ubuntu/PC install at hand.
Did a few runs calling the setup script and also running various modules (esthemes, runcommand config, etc.) and didn't catch any obvious errors.

Efriim

@mitu
I never knew that, It will take some more to learn it.
Thanks for telling me how to set it to normal.
retropie_packages could not find that module, so I installed it using the settings.

And I no longer have the joy2key error, the python2.7 error was harder to get to.

Using the script to reproduce the errors. Did reproduce the error on the second loop.

mitu

@Efriim said in Error after updating retropie-setup to 4.4.9 (a161774a):

retropie_packages could not find that module, so I installed it using the settings.

Yes, the command is a bit wrong

sudo ./retropie_packages.sh runcommand

should work instead.

Efriim

@mitu
Oh I see,
quick question
I downloaded like a 600mb repository
450mb for ffmpeg.
I know my build will fail because I don't know how, but about how much free space will I need in order to make?
If I have ffmpeg already installed should I be able to use that instead?
And
It appears I ran out of virtual memory first.
But that wasn't my only problem, it wanted to compile for x-11vulkan and I didn't have any build target.

DarishZone

Ive noticed on Github they released a fixed version of joy2key script, do you know if that fixed file is already included on update branch? Ive downloaded the script and overwrite over old one, i hope this is legit and not harm my system. Errors seems gone after thuough...

Lolonois

@DarishZone Do follow mitu's advice a few messages above.

This will incorporate this PR and the latest fix.

In any case please provide your findings with the PR as a benefit for all.

Once the PR is accepted you can switch back to github master.

Cheers

mitu

@DarishZone Just wait for a final version to be added to the RetroPie script and you should be able to update as normal.

mitu

@Efriim I assume you're talking about PPSSPP ? I honestly don't know about the space needed, but I assume upwards to 2Gb. I don't know if PPSSPP can use the system's ffmpeg installation, but it's up to their build system.

It appears I ran out of virtual memory first.
But that wasn't my only problem, it wanted to compile for x-11vulkan and I didn't have any build target.

Memory intensive compilation packages have some additional steps that add swap - did you use one of RetroPie's scriptmodule or compiled it on your own ?
There's no Vulkan support for the PI's GPU AFAIK, so it's pointless to try it.

You should start a new topic for these questions if you'd like more details.

DarishZone

@mitu said in Error after updating retropie-setup to 4.4.9 (a161774a):

@DarishZone Just wait for a final version to be added to the RetroPie script and you should be able to update as normal.

Thanks! I just want to say if overwriting old joy2key script with the fixed one from github via ssh is equally effective

psyke83

@Efriim said in Error after updating retropie-setup to 4.4.9 (a161774a):

Yay. So the fix ended up being on line 134? You don't have to explain, I wouldn't understand.

Unrelated, is there any chance that the runcommand button response will get fixed?
To break it down, it only responds to an input right after the pop-up/launching.png disappears. Making the delay entirely pointless, and just being difficult to invoke.

I'm sorry - I missed your reply earlier. The problem turned out to be a combination of issues, one of which being that the script was trying to close already closed fds, yes. The reason for this happening was that the script was receiving multiple signals, this presenting the situation of the signal_handler running several times concurrently, when it's only supposed to be executed one time before exit. That should be fixed by the PR now.

It's possible that runcommand might have been behaving oddly with joy2key before this PR, but might be fixed now. When I have some time I'll check that out and see if it's possible to make the invocation interval more user-friendly (if the PR hasn't improved the situation).

Efriim

@psyke83
It didn't improve the runcommand, it seems like it may have something to do with joy2key running at the end of the script, because using a keyboard it is possible to enter the run-command dialog. I thought since you were in that area, it might be easier to lock on to.

I found a forum post from a few years ago with the same issue, it would be great to have it fixed.