Atmosphere: Acessing Album (Homebrew Menu) crashes and/or turns off the Nintendo Switch

[lorenzovaquero]

Bug Report

What's the issue you encountered?

Acessing Album (Homebrew Menu) crashes and/or turns off the Nintendo Switch.

How can the issue be reproduced?

Start up Atmosphère from RCM and select the Album app.

Crash report?

When using "vanilla" Atmosphère with hbloader's hbl.nsp (turns off) (it includes a fatal_report)
When using "vanilla" Atmosphère with switch.hacks' hbl.nsp (black screen)
When using "SDFiles" Atmosphère (turns off) (it includes a fatal_report)

Environment?

• For the first case (turns off after opening Album. If I tap the power button, the switch powers on):

  • Bootloader: Official fusee-primary.bin 0.8.2
  • Atmosphère Release: Official release 0.8.2
  • hbmenu Release: Official release 3.0.1
  • hbloader Release: Official release 2.0.1
  • Additional kips: No

• For the second case (black screen after opening Album and need to manually hold the power button for 12 seconds in order to turn off switch):

  • Bootloader: Official fusee-primary.bin 0.8.2 (same as first case)
  • Release: Official release 0.8.2 (same as first case)
  • hbmenu Release: Official release 3.0.1 (same as first case)
  • hbloader Release: File from switch.hacks.guide
  • Additional kips: No

• For the third case (turns off after opening Album. If I tap the power button, the switch powers on):

  • Bootloader: SDFiles' fusee-primary.bin 0.8.2
  • Atmosphère Release: SDFiles' build 0.8.2
  • hbmenu Release: SDFiles' build 3.0.1
  • hbloader Release: SDFiles' build 2.0.1
  • Additional kips: None selected in SDFiles' page, but in SDCARD/modules/required folder are exosphere.bin, fs_mitm.kip, loader.kip, pm.kip and sm.kip

• Additional info about your environment:

  • Nintendo Switch on firmware 2.3.0 (serial XAJ7001280X) in Spanish without a linked Nintendo ID.
  • Also tried launching with Hekate bootloader, but without a difference.
  • Payloads are launched from TegraRcmGui.
  • Also tried with/without airplane mode and with/without joycons, but without a difference.
  • Using a Fat32 29.7 GB SD Card (31,902,400,512 bytes) from SanDisk.
  • Also tried opening album before/after entering sleep mode, but without a difference.

Additional context?

It's the first time that I try to run any CFW on my Nintendo Switch, and I have never managed to open the Album (Homebrew Menu) without crashing. Without CFW, the Album opens normally.

When trying to load ReiNX, it gets stuck in the splash screen. I have never managed to launch ReiNX on this system (I put it in case it can give any more additional information)

Edit: If I use the demo version of SX OS with the official 3.0.1 hbmenu, I can open the Album (holding R) and access the Homebrew Menu.

Edit2: If I try to open the Homebrew Menu using RajNX 0.7.5.1a, it opens normally. And if I try to use Atmosphère 0.8.2 using the hbmenu.nro included in RajNX 0.7.5.1a (whose source I don't know where it is), now opening the Homebrew Menu works. However, there are some homebrew like Tinfoil c.883e3bd that still crashes the Switch, leaving a black screen (crash report).

P.D.: Merry Xmas!

[Skonikol]

I often encounter this problem on Ams on 2xx firmwares. In this case, I use RajNX 0751 (with debugmode) to update via ChoiDujourNX.

[lorenzovaquero]

Wow, you are absolutely right!
If I try to open the Homebrew Menu using RajNX 0.7.5.1a, it opens normally.

And if I try to use Atmosphère 0.8.2 using the hbmenu.nro included in RajNX 0.7.5.1a, now opening the Homebrew Menu works.

(Maybe it is hbmenu's fault? By the way, I couldn't find the source for the hbmenu bundled with RajNX 0.7.5.1a)

From within the Homebrew Menu, now I can launch some applications like RetroArch 1.7.5, Checkpoint 3.5.0 or ChoiDujourNX 1.0.1. However, there are other applications like Tinfoil c.883e3bd that crashes the Switch, leaving a black screen (crash report)

It's certainly a weird behavior, and I would love to know its root cause. Once I feel confident enough to use ChoiDujourNX and know that I will be able to open the Homebrew Menu consistently, I may update the console without burning fuses to version 3.0.0 or so and see if the problem persists.

[Skonikol]

Not all homebrew are optimized to work on earlier versions. In my opinion, the best solution is to create a full backup (boot0 / 1, rawnand, biskeys), upgrade via CDNX to 620 and use AMS 082. For peace of mind, you can make several backups and always be sure that you can return to an early version of the firmware.

[lorenzovaquero]

(Thanks a lot for your fast response!)

I made a (hopefully clean) boot0/1, rawnand and biskeys backup before all this "madness" started, so I should be able to return to firmware 2.3.0 without much problem if I don't burn any fuses.

I'll try updating to firmware 6.2.0 if you say it will provide the best compatibility (BTW, the nogc thing is a pain...), so I'll keep you tuned.

[misson20000]

Most of the ecosystem should work on every firmware version though.

[lorenzovaquero]

I have made a few tests with different releases of hbmenu:

With the same environment as before, with a Nintendo Switch on firmware 2.3.0 (serial XAJ7001280X) in Spanish without a linked Nintendo ID and in airplane mode (payloads are launched from TegraRcmGui):

• Bootloader: Official fusee-primary.bin 0.8.2
• Atmosphère Release: Official release 0.8.2
• hbloader Release: Official release 2.0.1
• Additional kips: No

Results are:

• hbmenu 1.0.0 works.
• hbmenu 2.0.0 works.
• hbmenu 3.0.0 doesn't work (Switch turns off after opening Album. If I tap the power button, the switch powers on). Crash report
• hbmenu 3.0.1 doesn't work (Switch turns off after opening Album. If I tap the power button, the switch powers on). Crash report

So it MAY be a problem with hbmenu?

[misson20000]

Perhaps you could bisect the specific commit of hbmenu that's breaking things?

[lorenzovaquero]

There are way too much commits between versions 3.0.0 and 2.0.0, so it woult take me too much time.

Moreover, note that I am able to run version 3.0.1 using the demo version of SX OS instead of Atmosphère. So I certainly don't know what could be the problem.

And also, I'm not familiar with interpreting Switch crash reports, but couldn't they give any clue about where the fault lies?

[misson20000]

They can, but it's a bit tedious and a lot of the time they don't have quite all the information you might need to debug a crash. I've tracked it down to an abort in a call to nn::psm::IPsmServer::OpenSession, caused either by svcCreateSession failure (handle exhaustion?) or m_pDomain->Register (too many objects?) failure. Unfortunately, the result code is trashed in those reports. I'll be back in a few minutes with a patch to put the result code somewhere it'll be visible in the crash report.

[misson20000]

Try this patch with vanilla Atmosphere, official nx-hbmenu latest release, firmware 2.3.0.
It patches nn::diag::detail::VAbortImpl to include the result code in the break reason, which is normally zeroed out. It also skips over nn::diag::detail::InvokeAbortObserver and nn::diag::detail::InvokeSdkAbortObserver, but that shouldn't cause a problem.
ptm_abort_result_code.zip

[misson20000]

I'm also going to guess that this is the breaking commit in nx-hbmenu: https://github.com/switchbrew/nx-hbmenu/commit/8b86b36393fe6b14d830a3c9d36ae7004f29bdbd

[lorenzovaquero]

Sorry for making you wait.

I will try it right now.

(Also, inside the crash reports folder I have a dump [00315351093_0100000000000010_thread_info.bin], I don't know if it can be useful or not)

And thanks for all the help!

[lorenzovaquero]

Wow, I wasn't expecting something like this to happen.

"Vanilla" Atmosphère, official hbmenu 3.0.1 and your ptm_abort_result_code.zip. And now Homebrew Lauuncher is able to boot!!

However, weird thing. When I press the Home button inside the Homebrew Launcher, the Switch turns off (crash report).
And if I try to launch an app (RetroArch), it also turns off the switch (crash report).

[lorenzovaquero]

By the way. I'm trying to compile the hbmenu repo until commit afa9bd4 (the previous commit to the 8b86b36 you mentioned). However, I'm not used to Windows development, so I'm stuck with pretty a obvious errors that I don't know how to solve:

PS > make
/opt/devkitpro/msys2/usr/bin/make -f Makefile.nx
make[1]: Entering directory '/e/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784'
theme_icon_light.bin
hbmenu_logo_light.bin
folder_icon.bin
theme_icon_dark.bin
hbmenu_logo_dark.bin
invalid_icon.bin
menu-entry.c
aarch64-none-elf-gcc -MMD -MP -MF /e/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/build/menu-entry.d -g -Wall -O2 -ffunction-sections -march=armv8-a -mtune=cortex-a57 -mtp=soft -fPIE  `freetype-config --cflags` -I/e/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/include -I/opt/devkitpro/portlibs/switch/include -I/opt/devkitpro/libnx/include -I/e/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/build -D__SWITCH__ -DVERSION=\"v2.0.0\" -c /e/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/common/menu-entry.c -o menu-entry.o
/bin/sh: freetype-config: command not found
In file included from E:/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/common/menu-entry.c:1:
E:/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/common/common.h:57:10: fatal error: turbojpeg.h: No such file or directory
 #include <turbojpeg.h>
          ^~~~~~~~~~~~~
compilation terminated.
make[2]: *** [/opt/devkitpro/devkitA64/base_rules:19: menu-entry.o] Error 1
make[1]: *** [Makefile.nx:144: build] Error 2
make[1]: Leaving directory '/e/Downloads/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784/nx-hbmenu-afa9bd49d0badae356eec38fe9940a00fefdd784'
make: *** [Makefile:11: nx] Error 2

[misson20000]

I think that homebrew launcher booting here is probably some kind of fluke? Either way, both of those crashes have the same result code (0xcc0b), which indicates that the server is out of session memory. This is probably a case of the sm minimum session limit extension breaking things. Perhaps they raised the server session count in 3.0.0. @yellows8, maybe you have thoughts on this? Seems to me like the best option is to just disable showing battery charge below 3.0.0.

[lorenzovaquero]

Yesterday I opened this issue on the hbmenu repo in order to make them aware of the possible problem.

@yellows8 told me to try and run the Homebrew Menu via a game title application. However, I recently formatted the Switch and all the games I had were eShop ones, so I now depend on a friend lending me any cartridge compatible with 2.3.0 in order to make the test (downloading via eShop is not an option because I would need to update the Switch and connect to Nintendo's servers with a "tinkered" switch).

(Maybe it has to do with this kind of thing?)

[lorenzovaquero]

And I don't know if it's a fluke or what it is. But I'm able to consistently boot the Homebrew Menu using your ptm_abort_result_code.zip.

However, once I do that, I am doomed to forcefully turn off the Switch: Lightly tapping Power in order to enter sleep mode, running any homebrew, running the Homebrew Menu inside the Homebrew Menu, pressing Home, ... I can't get out of the Homebrew Menu without the switch powering off.

[yellows8]

It's a "CFW" issue, hbmenu should not have workarounds for it..... "build errors" hbmenu README

[lorenzovaquero]

Oh nice, now I can compile! The thing was that I never imagined I could use pacman from Windows.
I still get errors because bin2s and as aren't found, but I'm able to create the NRO file.

Aaaand with the same setup as before (vanilla Atmosphère without ptm_abort_result_code.zip), I am able to run without a problem commit afa9bd4.

[lorenzovaquero]

AND as @misson20000 predicted, using commit 8b86b36 turns off the Switch (crash report)

[misson20000]

@yellows8 I'm not sure I agree that this is a CFW issue. Here's what I see is happening:

• nx-hbmenu acquires psm
• nx-hbmenu calls OpenSession
• psm's implementation of OpenSession creates ISession object
• calls msg->SetOutObjects(&info_for_isession)
• SetOutObjects calls SetOutObject(0, &info_for_isession)
• SetOutObject hits a sad path and aborts.

There are only two sad paths in SetOutObject, but they share the same code so we can't tell from stack trace alone. One sad path comes from nn::sf::hipc::CreateSession, which returns what it gets from kernel, or 0x1060B if kernel gave 0xCE01.

The other sad path is m_pDomain->Register(serverSessionHandle, std::move(outObject)).

The patch I gave changes abort to call svcBreak earlier, without clearing x0,1,2, when it has the result code in w0, which reveals the 0xcc0b result code. This doesn't come from kernel and isn't 0x1060B, so m_pDomain->Register must be failing, likely because we've hit the 13 session limit from HipcSimpleAllInOneServerManager's template parameters (<13ul...>).

There are ~9 sysmodules+applets (qlaunch and overlayDisp) that have access to this service, so I don't think it's unreasonable to assume that those plus a few IPsmSession objects are touching the limit.

The only way that CFW could cause this failure is by enabling or contributing to this session exhaustion where stock firmware doesn't, but Atmosphere does neither of these. The psm service is registered with a limit of 13 sessions, with sm does not raise, and Atmosphere does not connect to psm anywhere that stock firmware doesn't. Would you work around a problem that's caused by Nintendo code?

[yellows8]

It works on my v2.x system (non-atmo-derived "CFW") - hence previous comment.

[SciresM]

@yellows8 @misson20000 it's "kind of" an atmosphere issue. Fixing it properly will require changing libnx behavior, then releasing new builds of Atmosphere + nx-hbmenu.

https://github.com/switchbrew/libnx/blob/master/nx/source/services/psm.c unconditionally calls _psmOpenSession, and persists a handle to the IPsmSession. This causes an extra session object to be created by psmInitialize, using up two slots per session instead of one per session. On the relevant sysver, psm only has a margin of one extra session. Atmosphere-fatal calls psmInitialize(), and thus claims the margin session that nx-hbmenu would be using otherwise.

Fix is to update libnx psm code to not unconditionally open an IPsmSession. Instead, it should only do that as needed (it could either open and close one surrounding relevant commands, or require the user to open one themselves).

[yellows8]

https://github.com/switchbrew/libnx/commit/e59036d4c8