search

zhuowei / ryujinx-ios

NOTHING USEFUL HERE; trying to see if Ryujinx's new Apple Silicon port would also runs on iOS
46 stars 10 forks source link

nothing happens #1

Open duckfromdiscord opened 1 year ago

duckfromdiscord commented 1 year ago

When I hit go, nothing happens even with JIT enabled through altstore.

Steps: 1 - Download RyujinxApp on iOS with safari 2 - open it in AltStore and wait for it to install 3 - Open RyujinxApp but don't do anything 4 - Enable JIT for it with AltServer 5 - Successfully enabled 6 - Hit "Go!" 7 - Crash 8 - Re open the app, no JIT 9 - Hit Go! again 10 - ABXY buttons appear and nothing else happens. Rest of the screen stays the same.

zhuowei commented 1 year ago

The IPA of this from GitHub Actions is not currently in a usable state. I'll let you know when I have something useful.

I don't have logging for errors yet. Try running in Xcode which will print error logs to the debug console.

I think AltStore might not be able to sign with the Extended Memory entitlement

duckfromdiscord commented 1 year ago

Thank you for the extremely quick response. Xcode is a good idea, will try that

duckfromdiscord commented 1 year ago

It's going to take me a while to build the app locally but in the mean time the most important things i see in the xcode "console" logs are these: Sandbox: RyujinxApp(...) deny(1) sysctl-read kern.bootargs COSMCtrl applyPolicyDelta unexpected absence of policy on appRecord com.worthdoingbadly.RyujinxApp

In the actual crash logs I am told it is

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0xffffffffffffa8c2
Exception Codes: 0x0000000000000001 0xffffffffffffa8c2

image

duckfromdiscord commented 1 year ago

in the mean time i'm trying to build on my mac

only issues I have had so far:

All of them seem to have been something I have done wrong, and from trying to compile SDL in the past, you have made it much easier :)

MoltenVK is building now. Will let you know how that goes

EDIT: MoltenVk seemed to build fine but dotnet could not be found, so i had to instead run ./makenet/runtime/.dotnet/dotnet tool install --global sfextract --version 1.0.0, and then run the command it provided to add it to PATH. when it actually came to running sfextract it said .NET was not installed. Now i have run out of space so I will have to pause for the time being

EDIT2: Running sfextract again said .NET was not installed. It gave me a link to version 7.0.4. Then when I installed that and ran it again, it crashed again and this time gave me a link to 5.0.17. I think it's kind of silly that dotnet didn't just give me that link the first time. Other than that and me not having 7z somehow it built fine.

duckfromdiscord commented 1 year ago

TLDR: I built it locally on my machine following the same steps the CI uses, but running the commands manually by myself. [One could say I hit step 6 in the issue and then skipped from there to 10.] I can't figure out how to build it from Xcode. Now, the buttons show up even when using JIT. This is a good sign. I don't know how to add the files to the app's Documents folder, so I may have to try with a jailbroken phone where I can access the filesystem.

zhuowei commented 1 year ago

I don't know how to add the files to the app's Documents folder

iTunes (Windows) / Finder (macOS) or iOS's Files app.

zhuowei commented 1 year ago

Here's an ipa I built locally:

For building:

duckfromdiscord commented 1 year ago

I can't get JIT to work because if xcode installs something it won't let me enable JIT from altstore. If i install it on xcode i can see the logs and debug, but no JIT so it doesn't matter. If i install it on altstore i can use JIT, but i can't see what's causing issues so it doesn't matter.

zhuowei commented 1 year ago

If i install it on xcode i can see the logs and debug, but no JIT

Debugging with Xcode already enables JIT (that's how JIT enablers work: they pretend to be Xcode's debugger)

(Note that Xcode's debugger by default pauses on SIGUSR1, which CoreCLR sends often: run process handle -s false -n false in Xcode's lldb console to ignore these signals)

Also, note that I updated the build scripts: the build script now builds xcode/Ryujinx/Ryujinx.xcodeproj instead of the older SwiftPM RyujinxApp project)

duckfromdiscord commented 1 year ago

Oh ok. The issue I was getting I wrongfully assumed was due to not having JIT. I'm getting something about a bad access here https://github.com/zhuowei/ryujinx-ios/blob/main/swiftpkgs/RyujinxKit/Sources/RyujinxKit/RyujinxKit.swift#L186 . I think it'll be much easier to make sense of errors now since I have it running straight through xcode to the phone.

image

zhuowei commented 1 year ago

Do you have the full stack trace (bt in lldb, or the Debug Session panel on the left of Xcode)?

Are you building with the Xcode project? (The swiftpm project doesn't have the correct entitlement to get extra memory)

Which device is this (I'm testing on an iPhone 14 Pro / iOS 16.1)

duckfromdiscord commented 1 year ago

Same ios, iphone 13.

image

zhuowei commented 1 year ago

I have not ran into this myself: do you have the log of what the app printed to Xcode before crashing?

The iPhone 13 has 4GB of RAM; My device has 6GB; however, it should still run far enough with 4GB...

duckfromdiscord commented 1 year ago

The last thing it says is that it's reading prod.keys

duckfromdiscord commented 1 year ago

image

zhuowei commented 1 year ago

Yeah, I've never seen this happen before. At least it shows that it is executing C# code.

All my CoreCLR changes are pushed up, so it shouldn't do something strange: can you confirm that you're building with the Xcode project (with the extended RAM entitlement)? no you're definitely building with the Xcode project otherwise initHookMmap would've failed earlier. ... I don't know what's causing this then.

Also, do you have a preferred way to contact you?

Edit: could you try commenting out all of initHookMmap and make it return true instead, just in case the memory reserve is doing something weird on this device?

duckfromdiscord commented 1 year ago

Yeah i'm using the xcode project and building straight from there with your premade .tar.xz. I am almost certain i have the extended ram entitlement.

Preferred contact: Definitely discord. If you don't have a discord account i suggest making one and making a server for your projects

zhuowei commented 1 year ago

I can reproduce the crash on my iPhone 12 with iOS 14.1 once I added the return true in initHookMmap (otherwise it doesn't even start - iOS 14 doesn't seem to support the extended memory entitlement); I wonder if this is a 4GB RAM device limitation.

You don't happen to have a higher RAM device to test with, such as an iPhone 13 Pro/14/14 Pro or an iPad, do you?

duckfromdiscord commented 1 year ago

Unfortunately not. I checked a couple min ago. Will see if i know anyone that has one. Is it possible to reduce the memory used temporarily just to test some super light games? Perhaps a really small homebrew demo?

duckfromdiscord commented 1 year ago

https://github.com/zhuowei/ryujinx-ios/blob/932ab6d418d080c33a4d389b1a53b50ac630f659/swiftpkgs/RyujinxKit/Sources/RyujinxKit/RyujinxKit.swift#L202 Will change this

duckfromdiscord commented 1 year ago

Yeah changing the reserve size doesn't fix it, i tried c000_0000 and 1000_000 and same issue

zhuowei commented 1 year ago

Can you print out how much RAM is available to the app on your device? Put this in the beginning of startCoreClr2():

  if #available(iOS 13.0, *) {
    print("Total memory available = \(os_proc_available_memory())")
  }

iPhone 12, iOS 14.1 (without Extended Memory entitlement, not available on iOS 14): Total memory available = 2419718104 iPhone 14 Pro, iOS 16.1 (with Extended Memory): Total memory available = 4278630656 iPhone 14 Pro, iOS 16.1 (without Extended Memory): Total memory available = 3204774144

That's the only think I can think of that would differ from my iPhone 12/iOS 14.1 vs iPhone 14 Pro/iOS 16.1. Although iPhone 14 Pro doesn't run into this issue even without Extended Memory, so I'm really not sure what's going on.

For what it's worth, the negative pointer comes from https://github.com/dotnet/runtime/blob/922c75c837fc95092e1d9e433a087ac62082953d/src/coreclr/vm/virtualcallstub.cpp#L1436 so I guess some this object failed to allocate somehow and nothing caught it. I'm not familiar with CoreCLR enough to figure out how or why that would happen though. I suspect the allocation failed not because of the physical memory limit here, but the virtual memory limit. That entitlement raises both though, so if that call logs that the physical memory is extended, that also means the app has virtual memory extended too)

duckfromdiscord commented 1 year ago

total memory available is 2445621504. So it's a bit more than the 12 but not much. image

What could be causing it to be so low?

zhuowei commented 1 year ago

Huh. Then I really don't know.

Limited physical memory shouldn't cause this, anyways: iOS would close the app with a memory exceeded error and not a segfault.

It seems like your device does support extended virtual memory (otherwise initHookMmap would fail) so I have no idea what's going on here.

duckfromdiscord commented 1 year ago

Could i figure out a way to either free up more memory, or try to allocate/require less?

zhuowei commented 1 year ago

I don't think it's a memory usage issue (again, it would've been closed for running out of physical memory, not with a segfault). There might be some other difference between iPhone 14 Pro/iPhone 12/13? I really have no idea.

Maybe we should hook/break on all mmap calls to see if one of them fails or something, or figure out what's causing the this pointer to be corrupted... but I honestly don't know if these would work, and I don't have any good ideas.

duckfromdiscord commented 1 year ago

Sorry I meant virtual memory 😅

Is there a command in lldb to break on all mmaps? If so, what would I look for once that's done? I'm not great with debugging, especially on iOS, but i'm willing to learn some stuff for the greater good of ios emulation

zhuowei commented 1 year ago

Replacing initHookMmap with a single return true would prevent reserving virtual memory early - on my iOS 14.1 (which didn't have the extended virtual memory entitlement) that's required to even get as far as this crash. Doubt it would help though.

You could add a breakpoint in Xcode's debug pane (search for "Xcode symbolic breakpoint"), and add commands to print out its arguments before continuing the program. mmap is called reasonably often and breakpoints are slow, though, so if that makes it hard to debug I might try to hook mmap in code (via e.g. fishhook) instead.

duckfromdiscord commented 1 year ago

Seemingly no effect putting return true right at the beginning of initHookMmap. It sounds like we will have to add breakpoints or hook from code. I only started working with compiled languages recently. I assume we will have to find each use of mmap and step through them to find which turns this null?

duckfromdiscord commented 1 year ago

I set a symbolic breakpoint on mmap that calls po $arg1 and po $arg2. https://gist.github.com/duckfromdiscord/db4d132bed408880532bbf4d8239f20d

1000jw commented 1 year ago

image

I have the same problem. Did you solve it?

duckfromdiscord commented 1 year ago

@1000jw No not yet. I will stay subscribed to this thread to get updates if a fix is found