Retroarch: 3DS cia builds crash after being started (since v1.7.7)

[muxi1]

First and foremost consider this:

• Only RetroArch bugs should be filed here. Not core bugs or game bugs
• This is not a forum or a help section, this is strictly developer oriented

Description

[Description of the bug]

Expected behavior

[What you expected to happen]

Actual behavior

Retroarch does launch, but crashes right after the message:
'Found display server=NULL'

Steps to reproduce the bug

1. Installation cia files (from retroarch/cores folder)
2. Installation cia file (from cia folder)
3. Starting retroach - then crash
   

Bisect Results

[Try to bisect and tell us when this started happening]

Version/Commit

You can find this information under Information/System Information

• RetroArch: 1.7.7 stable and nightly cia builds up to and including 2019-05-10

Environment information

• OS: Luma3DS v9.1 on N3DS XL

[MrHuu]

The last working build was on 04-05-2019.
All .cia and .3dsx builds after 04-05-2019 are affected.

Retroarch does launch, but crashes right after the message:
'Found display server=NULL'

[twinaphex]

@jdgleaver could not reproduce this.

Let's see what the actual issue here is.

[FateForWindows]

Which model does he use for testing? Also, could he send his config? There might be something set in his config differently from the default that doesn't trigger the crash?

[ford12acing]

crash_dump_00000000.txt
i attached this as a txt to attach, but it was pulled as a *.dmp file. this is the dump of the crash when trying to run it on my 3ds xl (new- snes model). i have two identical systems in front of me and they both have the same crash.

[jdgleaver]

I 100% cannot reproduce this.

• I test nightlies on both o3DS and n3DS (XL)

• I have tested the latest nightlies with both my existing config and a fresh install

In all cases, everything works correctly.

I must therefore assume that this is a system configuration issue. RetroArch 3DS has certain minimum requirements:

• Your 3DS must be hacked according to Plailect's guide: https://3ds.hacks.guide/

• System firmware must be 11.9.0-42

• CFW must be Luma3DS v9.1 run via boot9strap

• You must be using SysNAND

• You must have a working DSP dump

Anything else (Gateway/EmuNAND/NinjaHax/frankenfirmware/etc.) is a crapshoot, and we cannot realistically support these things.

So can users please tell me: does anyone with a 'properly' configured 3DS experience this crashing problem?

Having said this, looking at recent commits I can see just one thing that might potentially cause an issue if a 3DS with unsupported/incorrect firmware doesn't properly initialise its RAM (or some such foolishness). I will knock up a quick test build and post it here, and would appreciate it if users with the crash problem could test.

In the meantime (FWIW), here is the retroarch folder that I'm using on my 3DSs, minus bios files (contains latest nightlies) - it is virtually impossible that my config would make any difference, but feel free to test: https://drive.google.com/open?id=1It_UWvkCbVuVHgi0oq60FhlYd_ITXY74

[muxi1]

Oh, I´m on 11.3.0-36 (Luma3DS v9.1, N3DS XL).........but that would be the first time that I would have to update the firmware for homebrew

[jdgleaver]

Well, that's the thing - we have no way of testing with old firmware versions, so I have no idea whether it would work or not (and memory management may well have changed with new firmware versions). Without a level playing field we're hunting in the dark.

I'm still poking around with this test build - I'll post something soon...

[jdgleaver]

Okay, well my hunch turned out to be a bust...

Could you please try the following instead:

• Delete your existing retroarch.cfg file

• Create a new retroarch.cfg file with just the following contents:

log_to_file = "true"
log_to_file_timestamp = "true"

• Copy this CIA to your retroarch/cores directory: https://drive.google.com/open?id=1b8yDczdiuXQ__V7cKQUKi6-kDgMAIsBG

• Install and run the gambatte core

• After it crashes, you'll have a timestamped log file inside retroarch/logs - please post it here

This first-pass test is not actually very useful, but it should help me narrow down where it's crashing...

[jdgleaver]

Just had a thought: when you installed the cias in retroarch/cores did you select 'install and delete'? Because if you deleted the cia files, that's going to cause problems...

[muxi1]

I always install cias via FBI without having to clear the old installation before. Then I leave the data in the folder and do not delete it. I can do that with the cfg later, because I'm on the road.

[jdgleaver]

Okay - that's good to know. It should be fine to install new cias without uninstalling the old ones, as long as the cia files are kept around.

Thanks in advance for running my test :)

[muxi1]

Here is the log file. The gambatte core did not crash after launch

logs.zip

[muxi1]

......but a crash occurred after I wanted to start a game......and a lot of other logfiles have been created
logs.zip
Edit:
please wait, I have probably mistakenly started a game for another system ....

[jdgleaver]

Oh, just saw your edit - I can build a gPSP core for you, if it's easier...?

Edit: Here it is, in case you need it: https://drive.google.com/open?id=1q5vBnj8R58iSf7k2jyhmTqAopDiqmAzZ

[muxi1]

Many Thanks! I'll try it again and then report it

[muxi1]

gPSP works! no crash at start and also not after loading content - and that under FW 11.3.0-36! Enclosed the log file:
logs.zip

[jdgleaver]

Ah, well that's really interesting! This suggests very strongly that the crashing was caused by the same issue that affected the WiiU build, and which was fixed by commit https://github.com/libretro/RetroArch/commit/b270ea6b799e05bf4ffcc2e7108cbe7778380cd6 just this morning.

So the question remains: why does the bug affect FW 11.3.0-36, but not FW 11.9.0-42?

Now I've just checked https://www.3dbrew.org, and there are many exploit fixes between 11.3.0-36 and 11.9.0-42, some of which deal with memory handling. So I think it very likely that an improper free() that causes heap corruption on 11.3.0-36 is managed in a way that is harmless on 11.9.0-42 (Can't really elaborate on this, however, since the inner workings of the firmware are both a closed box and beyond me...)

So I think you'll find that the next nightly (with a build time after ~9:00 this morning) will work properly.

But would you mind testing another 'broken' build for me, just so I can get some more logging info and maybe understand this a little better?

[vaguerant]

@jdgleaver Just FYI, I'm on 11.9.0-42(U) and have been experiencing the same failure of all RetroArch builds since 1.7.7. It doesn't appear to be a 3DS firmware issue.

Your 3DS must be hacked according to Plailect's guide: https://3ds.hacks.guide/
System firmware must be 11.9.0-42
CFW must be Luma3DS v9.1 run via boot9strap
You must be using SysNAND
You must have a working DSP dump

I fit every single one of these requirements. This makes the problem even less obvious.

[jdgleaver]

@vaguerant Okay, thanks for letting me know - this is becoming a real mystery...

Would you be able to test either of the cias I posted above, to see whether commit https://github.com/libretro/RetroArch/commit/b270ea6b799e05bf4ffcc2e7108cbe7778380cd6 fixes the issue for you?

(You can use your existing config for this, or delete it and start with a fresh one - it shouldn't matter)

[vaguerant]

I think you uploaded individual core CIAs, right? I use the 3dsx builds of RetroArch, so I'm not sure how to go about setting up the CIA builds with those. Would I install a standard 1.7.6 RetroArch CIA and one of those core CIAs?

[muxi1]

But would you mind testing another 'broken' build for me, just so I can get some more logging info and maybe understand this a little better?

Is there a specific build to test? Maybe the stable build 1.7.7? - This one has the same issues.

[vaguerant]

Sorry if I'm overstepping, but I think @jdgleaver was suggesting they would build one of the older, broken versions with verbose logging or whatever else is special about the builds in this issue and upload it here for you to test.

[ford12acing]

i did the install+delete of the 3ds retroarch cia. i am deleting the retroarch directory right now via ftp (pulling the microsd is a pain because my ds is in a case). I will try to install without deleting the cia and see what happens. will report back later (does take a long time via ftp)

edit: i am on latest firmware and have latest luma

[jdgleaver]

Hold on a minute, guys - I had to step away for a bit, and while I was doing something else I think I realised what's happening here. If I'm right, then it's a very silly bug (which is indeed fixed by commit https://github.com/libretro/RetroArch/commit/b270ea6b799e05bf4ffcc2e7108cbe7778380cd6)

Just need to do some testing, and I'll report back.

[ford12acing]

didnt delete the cia and re-installed. still crashes. im going to wait for @jdgleaver

[MrHuu]

The gpsp build uploaded by @jdgleaver loads fine on my up-to-date CFW'd new and old 3ds. Like muxi said, it exits to home menu without crash when loading a rom.

[jdgleaver]

Okay, mystery solved.

This was caused by commit https://github.com/libretro/RetroArch/commit/50a57b03a18b52636debae5f4132791ad8a96db2. Basically, this changed the way a certain string was formatted, and because 3DS has a very small PATH_MAX_LENGTH the string was overflowing - causing a segfault.

I never personally encountered this because I only copy the cores I actually use to my sd card (and the fewer the number of cores, the shorter the string - I never exceeded the limit)

The commit has already been reverted, so if you guys wait for the next nightly (probably this evening, or early tomorrow), you should find that the crashes are gone.

Thank you for your patience :)

[ford12acing]

mine crashes when launching retroarch. i've never even seen the menu.

[muxi1]

mine crashes when launching retroarch. i've never even seen the menu.

That's what this is all about. Wait until the next Nighlty Release, then it will probably work again.

[ford12acing]

mine crashes when launching retroarch. i've never even seen the menu.
That's what this is all about. Wait until the next Nighlty Release, then it will probably work again.

i got confused because some are saying it crashes when launching a game, which i couldn't even get to. sorry

[MrHuu]

Removed the cores (.cia) i won't use from the cores folder. Still have about 20 .cia cores available in the folder now.
With this the latest nightly runs fine so far.

Thanks for your insight and effort!

[twinaphex]

We're pushing a new release cycle right now to deal with the 3DS issues.

[alphapepe]

@twinaphex Any plans to fix gpsp? It's been broken forever now. It even crashes with dynarec turned off.

[muxi1]

I can confirm that the cia nightly build 2019-05-11 works again. Thanks for your efforts!

[jdgleaver]

Glad this is working now.

@alphapepe gpsp discussions are continuing here: #8750

[FateForWindows]

At this point it would probably be best to close the issue as it's been fixed for sure.

[orbea]

Since this seems to be reported as fixed I am going to close the issue now, please let us know if there are any more issues.