Closed TheGinGear closed 3 years ago
Sorry for the delay in response, I appreciate your message!
Interesting. If you've tried again since, does it crash at a different place? Wondering if it hits a bad file that confuses it.
Thanks for the notification and the additional questions and concerns! You're totally right. Those things make sense and the answer to why they don't really exist can basically be summed up in saying that they'll be implemented in the next version, which is pretty much a full rewrite.
It was still kinda experimental, made to see if I can learn the tools up to this point, but now it's time to make it all nice. :)
Almost the same here with v1.0! I'm on AMS 0.18.0 with FW 11.0.1. In my case the entire system crashes after nearly 9100 files scanned, I will attach here an Atmosphere fatal error report + dump (even though the report seems kinda useless... it just contains 00000000 return addresses) 01612712668_0100152000022000.log 01612712668_0100152000022000.bin.txt
( Rename the last one from .bin.txt to .bin, since Github doesn't want bin files :p )
Thank you! Weeeird. Are you able to run the app from a pc with nxlink? I've compiled a special version and attached it that outputs exactly what it's scanning as it goes. I'm suspecting that maybe there's a filename with unexpected formatting or characters in it? Let me know, thanks again!
Thanks for the response! I tried to run both the version you attached and the standard v1.0 executable using nxlink, but I just can't get them to work through nxlink: everything that's shown is just a black screen after the transmission ends. The console didn't become unresponsive though, so I was able to go to the HOME Screen and close the app.
For the special version you attached, I think it worked! Although it still crashed at ~9100 files, it seems to have handled the error (it showed the classic Switch software error screen instead of crashing the entire system). Moreover, this time the crash report seems a bit more useful :) I'm attaching it here: 01612901716_0100152000022000.log
Sorry, I forgot the dump: 01612901716_0100152000022000_thread_info.bin.txt Hopefully it will be useful to you! (Again, I renamed it to .bin.txt to upload it)
Thanks again! ...Strange. Looks like borealis is getting stuck in a loop somewhere. I'm not sure why it's doing so.
Just to be sure, if you enable debug mode, disable subfolders, and disable / (not subfolders), and restart, does it do better?
nxlink ideally would give you nice info like this if it worked.
Changed the logic a little bit for v1.01. Let me know if that does anything for you! (And logs would be great if it still chokes. Thanks!)
im getting crashes as well. AMS 0.18.1 HOS 10.1.0, typically crashes when it hits 9000 files. Just snagged the 1.01 and using the nsp forwarder as well. tried clearing cache.
Try this on for size. Whipped up a version that outputs the log to 'sdmc:/hbd_debug.log'. Hopefully this means we can just check out the last line of text and see where it gets stuck without nxlink and stuff.
@Chrscool8 Sorry for the belated response. I've enabled debug mode in the app and set up nxlink to display the messages, then I tried both scanning only /switch/ and leaving every option enabled, using both the v1.01 nro and the special test version you attached. All I got were software and system crashes... here I uploaded a zip file where for each test I've copied the nxlink logs, the reports and the dumps. I've also written the result of the test in the test's folder name. Hope it can help you enough, and sorry again for the delay :) HomebrewDetails.zip
No probs! Thank you! That's hugely helpful. Really appreciate the effort.
It does have a hint towards a certain part, which I've torn out of the following attached version. This version totally gimps the cache feature but it'll help us know if the trace is a red herring or not!
Now it works!
By the way, I see strange characters here, probably caused by non-ASCII filenames:
Perhaps it would be good to open a new issue?
Aha!! Thank you very much! This is exactly what I was predicting but had no proof of it until now since I apparently don't have any non-ascii containing files on my Switch.
The singular line of code that was backtraced to was within the script for saving the cache json to a file, within the method that determines encoding. For some reason it seems to be choking on writing those characters to a text file. I'll drill down on that next and see what I can do. Back with a fix soon!
Appreciate you helping me figure this out!
Awesome!
Just for info, that homebrew application I've shown before doesn't seem to contain any app title/author info... I checked from the hbmenu and directly by looking for names in the binary, found nothing. Could it be that the crash is caused by the check not finding any name for the homebrew app?
It should be happy enough with real empty fields. I'm not sure why exactly some apps provide garbage data in place of where the real fields should be, but I put a little extra check on the reading to ensure we have no broken unicode symbols attempting to be saved to a file. See how this attached app treats you!
It works fine! Just a couple of things I noticed: the files scanned are now less than 9000 (how? was it an error in calculations in the previous version that caused the files to be more than 9200?)
And lastly, the characters still display as unreadable text although the caching system doesn't crash the application:
Awesome work anyway, love your piece of homebrew!
Sweet, thanks again!
The app makes an assumption that the nacp section of the nro is valid and typical. It'll just read garbage data from the spots where things are supposed to be if they're not. This is the first I'm seeing apps with missing or broken info so I hadn't found this issue before! In the case of kgdoom, if the makefile in its repo is to believed, they just omit the nacp fields entirely, and the MAME app at least disregards the author field (and perhaps more, I haven't dug in yet).
Let me know if you come across any other garbled apps! It's great to finally have them on my machine so I can actually reproduce and debug lol.
As for the counting, I also recently fixed a blacklisting bug so you may now be successfully skipping those things (I put in the checkpoint saves folder by default).
Voila. Here's a version which (with your confirmation) is ready for the next release. It's got slightly heavy-handed but infinitely more graceful checks when reading wonky nacps from an nro. If any fields are missing or the data doesn't handshake, it'll fill in the name field with the file name and mark the others as unknown. Later, I'll see if I can grab some of the fields if any exist.
It works just fine, no problem so far!
If you want, I can send you the faulty NROs that caused the encoding error in the previous versions
Sweet! Thanks a lot but unless you find a new problematic one, I think we're good. :) I used screenshots to figure out which were bad and downloaded them myself to test it.
Really appreciate your help fixing this! Enjoy the app!
Describe the bug if you enable scanning other than just /switch/, it scans to 3840 files exactly and then crashes
Screenshots Crash screen is the basic "The software was closed because an error occurred."
System Type and Version:
Additional context Why does it scan everything and not just looking for an identical-named .nro file inside the subfolders? Also why is there an autoscan setting but not a setting to skip the scan? or the ability to manually navigate to individual nros