Closed Leseratte10 closed 4 years ago
well, there goes my idea of it being a stable version...
ill investigate this later
before i investigate further : is it possible to reduce space on the hack? were are pushing the limit on memory usage here a bit :/
also : don't run this on a wii. youre writing to an address space not meant to be accessed , specially not with random data
You mean it's just running out of memory and crashes? I would have assumed that there's proper handling for running out of memory ...
I can try to make the patches a bit shorter, but then won't it just freeze for the end user when maybe more than these two hacks are enabled?
If I remember correctly, Priiloader loads all the enabled hacks into an array, and the loader that loads the system menu then applies these hacks, right? And the priiloader gives a ptr to that array to the loader.
What if Priiloader would store that array to the NAND (would only need to be done when the user changes the hack settings) in the proper, parsed binary format, and the System Menu loader could then read that file in parts? Meaning, load one hack, copy it to its destination, then load the next hack? Then you wouldn't need a large enough RAM buffer for all hacks.
well, i too would have expected it to give an error, but yes, its allocating memory around 0xE182E260 , something that most certainly is not normal memory ranges afair.
storing the array on nand would be stupid. we already have the hacks file on the nand. its better to load the hacks in the loader then. problem with that is that would increase loader size and complexity and make the loader basically a full on application instead of a ~3KB stand alone binary.... that is embed into priiloader.
im going to look into doing the allocation differently/way more efficiently but i suggest you look into if you can make the hacks smaller if possible too. welcome to embed device programming xD
Are you sure it is allocating memory there? If it allocated memory at that RAM address and tried to load the system menu to there, then how come the first two patches applied correctly, and for the second hack, A) only one of the two patches was applied and B) for the offset 0 instead of the correct one?
Also, maybe that "running out of memory" (if that is actually what causes the bug) is what caused the problems with the Wiimmfi patch for @Debs305 in the other issue (#222).
because the second hack is the final push it needs to start writing to the other address and all other allocations afterwards are even more bogus than the last. yes im sure. i checked the addresses after each hack it adds to the list. it does a reallocate to add the new size of the allocated memory, and this is what is causing it to go to far.
imagine having a box of 15 items. you want to add 5 new items but can't, its full. you need a bigger box, so you get a box of 20. yay! fits! but what happened to the previous box? well, its disregarded somewhere in a corner, not really taking space but we aren't going to look at it again cause remember? it was to small. but shit, now we need even more. a NEW bigger box! yuy, fits again! but you know, eventually you'll run out of space for all the boxes so you start placing them elsewhere
and this keeps going and going with every offset hack. this is how it ends up allocating memory that isn't mem2. sadly i didn't write the memory manager and this behaviour (disregarding previous boxes and not reusing that space) is not what i expected of it tbh. i can fix it by first looking at how large the box needs to be, and i will, but eug. another for each loop...
EDIT : and no, i don't think his issue is related. if it failed to allocate the hacks or the loader (which is allocated after the hacks) system menu wouldn't even load
I mean, even if you have to add another for loop, I imagine that will still be way more performant than having to call realloc all the time to get a larger blob of memory, no? Maybe you could include that in any of the existing loops? I mean, when you parse the ini file you are going to go through the entire line of code anyways, might as well add a counter there.
could you give this a try? https://upload.dacotaco.com/boot_hacks_fix.dol
should have it fixed. and no, the counter can't be added as is because you don't know if you have to include the master hacks or not until later when actually applying them. you could always assume they are enabled and count them in, but that sounds like a recipe for disaster imo
Thanks for fixing, this version works. I will make a new PR with the changes to the Wiimmfi patch (as mentioned in my email in April) as soon as I ported it to the other regions.
On 4.3U, the following two hacks work just fine:
and results in the following log during boot:
Adding another patch to the MASTER hack, making the first hack look like this ...
results in a crash, and the following log:
so apparently, adding that second patch to the MASTER hack causes the other hack to no longer apply correctly; and also the address for the sys menu is wrong.
Do you have any idea why that happens? It can't be the contents of the patch, as that code isn't even running at that point yet, so I'm suspecting another bug in the hack system ...