CTGPDX crashes when SaltyNX runs

[masagrator]

Since few people reported it to me privately, I will create this issue.

From evidence I got it must be somehow related to mod using skyline plugin. SaltyNX tries to be as less invasive as possible which is possible to see that 64-bit games work fine with SaltyNX even with skyline and exlaunch plugins AS LONG as they didn't disable "allow_debug" in npdm (there is no good reason to disable it and enable force_debug in retail game)

This issue will be closed when fix will be found or it will be determined that mod requirements are too strict for SaltyNX to run simultaneously.

Edit: SaltyNX fixed everything.

Now it's purely skyline's fault that is included with CTGPDX mod.
Solution:
#60 (comment)

[VorgonBattlecruiser]

Can confirm, took me ages to figure out what was causing it after an update,

[Kowken]

Starting 1.0.0 (adding 32-bits support), SaltyNX also make Sitbar’s CT Pack (a MK8 mod using skyline) crash on startup.

EDIT: Can confirm that removing the Skyline parts of the mod did solve the crashing issue and that said issue is still present on 1.0.3

EDIT 2: Strange, according to MetaTool, it has already the right permissions. Oh and sorry I did not realize this issue was already dealing with MK8DX.

EDIT 3: Same result with CTGPDX npdm file

[masagrator]

Can confirm that removing the Skyline parts of the mod did solve the crashing issue and that said issue is still present on 1.0.3

This is not an issue that can be randomly fixed. Requires looking up which function is responsible for it. And I have tied hands for the rest of working week. With Core32 we have ton of legacy code from 64-bit Core that probably can be removed without affecting compatibility, but not removed may affect mods. So that's why it's important to look up the root of cause, crash reports don't point to skyline directly.

[Kowken]

Can confirm that removing the Skyline parts of the mod did solve the crashing issue and that said issue is still present on 1.0.3

This is not an issue that can be randomly fixed. Requires looking up which function is responsible for it. And I have tied hands for the rest of working week. With Core32 we have ton of legacy code from 64-bit Core that probably can be removed without affecting compatibility, but they may affect mods. So that's why it's important to look up the root of cause, crash reports don't point to skyline directly.

No worries, I was just trying to report what I found to help solving the issue. Let me know how I can help if possible.

[FourHawk]

Ok so it wasn't a me issue, good. for now i've added MK8D to SaltyNX's exceptions.txt so i can keep SaltyNX installed, just disable it when MK8D is running

[masagrator]

Stripping Core to the bare minimum didn't help. So it is something that cannot be fixed in Core. I will try to find the most probable issue with all informations I will leave this thread as nonfixable on my part.

[masagrator]

So first issue was that skyline plugin is hardcoding svcSetHeapSize and svcGetInfo, and because skyline plugin is in modules list before nnSDK, Core was patching skyline itself. This was fixed with latest commits.

Now I have different error that I need to investigate

[masagrator]

Yup, now it segfaults inside skyline plugin.

Start + 0x26c4

So it actually fails at function

result = sub_60003AA8((int)&dword_6001A448, 0xA000, 0x18000);

Going further, it turns out that their template for reserving heap is pretty bad

.text:60003ADC                 LDRD            R2, R3, [R3] ; addr
.text:60003AE0                 ADD             R1, SP, #0x68+pageinfo ; pageinfo
.text:60003AE4                 ADD             R3, SP, #0x68+info
.text:60003AE8                 MOV             R0, R3  ; info
.text:60003AEC                 BL              svcQueryMemory

.text:60003B2C                 MOV             R1, R2  ; a2
.text:60003B30                 MOV             R0, R3  ; result
.text:60003B34                 BL              svcSetHeapSize

Breakpoint 26, 0x0d531b34 in ?? ()
=> 0x0d531b34:  eb0026c8        bl      0xd53b65c
(gdb) p/x $r0
$56 = 0x27575f48
(gdb) p/x $r1
$57 = 0x244000
(gdb)

It returns 0xca01 (invalid size)
This is bad. (Ignoring size not aligned to 0x200000) It checks how big is the allocated heap size without taking into account that there could be already more than one heap region reserved, and in this case SaltyNX Core has one heap, MK8DX has another heap.

Layout:
  Alias: 0x0046c00000 - 0x0046bfffff
  Heap:  0x0055200000 - 0x00d51fffff
  Aslr:  0x0000200000 - 0x00ffffffff
  Stack: 0x0000200000 - 0x003fffffff
  
  0x0055200000 - 0x0055243fff --- Normal           L--- [0, 0] << SaltyNX Core
  0x0055244000 - 0x00d1dfffff rw- Normal           ---- [0, 0]

And I don't want to dwell further into that as it seems now this is purely an issue with skyline framework not taking into consideration other scenario than one linear heap region. Poke whoever is responsible for 32-bit skyline framework to fix their code.

I'm leaving this open so people can see this issue.

[busmanl30]

Possible to port exlaunch to x32? if this is the case and something you can provide, the team can possibly move things over to support it better as skyline is old, and the x32 bit build is kinda janky

[masagrator]

Actually this heap reserving code is not a standard Skyline thing, it was added by whoever ported it to Mario Kart 8.

Skyline framework by default doesn't take any heap, only uses .bss as fake heap.

This seems to be not hard to fix if this will turn out to be the only issue. If you want to reserve whole remaining heap:

• Read total memory size using svcGetInfo with InfoType_TotalMemorySize
• Read used memory size using SvcGetInfo with InfoType_UsedMemorySize
• calculate (total - used) & 0xFFE00000
• pass it to svcSetHeapSize

It will be definitely faster than porting exlaunch to 32-bit, and then porting code from skyline to exlaunch

[busmanl30]

Aware of this, just wondering if this was something you were up for anyways, id love to see exlaunch on 32 bit games, and skyline is kind of old/deprecated.

[masagrator]

Currently there is nothing that would motivate me to port exlaunch to 32-bit games, so I'm not the right guy to ask.

[VorgonBattlecruiser]

can we update SaltyNX now? Will Mario Kart CTGPDX run?

[masagrator]

can we update SaltyNX now? Will Mario Kart CTGPDX run?

You have answer for that for over a month...

this is purely an issue with skyline framework not taking into consideration other scenario than one linear heap region. Poke whoever is responsible for 32-bit skyline framework to fix their code.

[VorgonBattlecruiser]

can we update SaltyNX now? Will Mario Kart CTGPDX run?

You have answer for that for over a month...

this is purely an issue with skyline framework not taking into consideration other scenario than one linear heap region. Poke whoever is responsible for 32-bit skyline framework to fix their code.

oh okay, who should i contact then?

[Rodrig0Almeida]

This works!

All credits to the ctgpdx Discord community, I'm just uploading the information to the topic

Saltynx itself is atmosphere/content/0000000000534C56.
If you want to keep salty then add mk8d to saltysd/exceptions.txt.

;MK8D
R0100152000022000

[VorgonBattlecruiser]

Thats awesome, i had no idea. Thank you so much!

[masagrator]

Found the solution. Thanks to ~Rafa10 for sending me link.

CTGPDX is using this source code as base for their loader
https://gitlab.com/Rafa10PT/skyline-mk8dx

It has the same issue
https://gitlab.com/Rafa10PT/skyline-mk8dx/-/blob/3953de3bb1e0950e095f8c0ba7f46ab3b7978016/source/skyline/inlinehook/trampoline.cpp#L50-L62

This can be fixed easily with this code

    Result TrampolineJIT::create(size_t insns_jit_sz, size_t inline_hook_jit_sz) {
        Result rc = 0;
        MemoryInfo mem_info;
        u32 dummy;
        u32 address_check = utils::g_MainHeapAddr;
        size_t final_size = 0;
        while(true) {
            rc = svcQueryMemory(&mem_info, &dummy, address_check);
            if (R_FAILED(rc) || (mem_info.addr != address_check) || (mem_info.type != MemType_Heap))
                break;
            final_size += mem_info.size;
            address_check += mem_info.size;
        }
        final_size = ALIGN_UP(final_size, 0x200000);
        if(R_SUCCEEDED(rc)) {
            void *heap;
            rc = svcSetHeapSize(&heap, final_size +
            ALIGN_UP(insns_jit_sz + inline_hook_jit_sz, 0x200000));

            if(R_SUCCEEDED(rc)) {
                const auto cur_addr = utils::g_MainHeapAddr + final_size;

And updating expected game version to 3.0.3 because that source code expects 1.7.1

Unpack zip, put file "subsdk1" to atmosphere/contents/0100152000022000/exefs replacing original file. And done
DOWNLOAD: subsdk1.zip

---

Issue in skyline loader was fixed in one hour and 10 minutes which includes finding the issue, fixing the issue and debugging, but it took almost two months because nobody directly affected by issue that knew where is their Discord server bothered to ask authors for source code. I got that link randomly when somebody asked on Discord where Rafa10 was sitting how CTGPDX ported skyline to 32-bit.

And it's not like they don't have it. They needed to modify it to be compatible with 3.0.3 version because original source code is for 1.7.1 version of game.