Luma3ds: Crash when i boot the dev version after starupdater update

[OneEyeDoll]

Processor:Arm11
Exception type:data abort
Current process:loader

R0 00000000 R1 FFF2BDD0
R2 001044B4 R3 00000001
R4 10000000 R5 10000000
R6 00104468 R7 0FFFFED8
R8 1FF83000 R9 00000000
R10 1FF83000 R11 0FFFF3D8
R12 10000000 SP 001016A0
LR 001016A0 PC 001016A0
CPSR 60000010 FPEXC 00000000

[Mrrraou]

which version is it exactly ?

[cheatfreak47]

This was a known bug with Star Updater, I think Astro is working on it. Something about the build environment on his server being outdated, possibly? I honestly just forgot what the issue really was, I was tired yesterday. @astronautlevel2 did the solution you found also fix the latest dev build or?

[astronautlevel2]

First of all, please report StarUpdater issues to the StarUpdater repo.

Second, @cheatfreak47 is correct, there was an issue with my build server using an outdated ctrulib. I forgot to rebuild the dev branch after updating ctrulib, though, which is why you're getting the data abort.

This issue can be closed, and instead opened on either the StarUpdater repo or the Luma3DSDev build site repo.

[Mrrraou]

@astronautlevel2 I understand the OP posted the issue here, as they probably thought it was Luma-related. It seemed like an issue with the stack growing over the code.

[astronautlevel2]

Actually, upon testing it seems like this happens when I build the latest commit manually. This might be a bug with Luma itself and not StarUpdater, if anyone would like to build the latest commit on the dev branch and confirm.

[OneEyeDoll]

The 6.1.1 stable.

[DHall243]

Luma Updater 6.1.1 is Stable, Latest Hourly D6F66D24 is not.

[Petraplexity]

I'm having the exact same issue using both the latest hourly and the latest dev hourly. :neutral_face:

[DHall243]

download the release of 6.1.1 and put the arm9loaderhax.bin on the root of your SD card delete and bin.bak you have also

[TuxSH]

Try this one maybe: out.zip

[Petraplexity]

@TuxSH That works just fine, thanks.
It's just commit DEV-dca612f though. Something done in a commit after it must have caused this, I guess.

[TuxSH]

Yeah, and changes in master branch weren't merged.

[Petraplexity]

My 3DS still won't boot either of the latest hourlies, I've tried everything I could think of. :|

[TuxSH]

All the the latest hourlies are broken, but not when I build it myself :/

[Petraplexity]

I'm still using the version in the out.zip you posted here yesterday. It's all that works (besides the stable release).

[TuxSH]

Yeah, building on Windows give correct builds.

[astronautlevel2]

Copying the contents of our discussion on discord here for documentation's sake:

[4:28 PM] astronautlevel: @TuxSH compiled 2dd64b8a9, boot fine
[4:28 PM] astronautlevel: Let me try 356268ea
[4:31 PM] astronautlevel: Okay, 356268ea doesn't boot
[4:31 PM] astronautlevel: So 356268ea is the offending commit

Here's the output of make on that commit: http://www100.zippyshare.com/v/edJ4DZTm/file.html

[Petraplexity]

I get the feeling that we don't need a 1.25s faster boot
:neutral_face:

[TuxSH]

it isn't the problem itself... the bug will have appeared sooner or later, I think...

[astronautlevel2]

[4:39 PM] Supster131: reverting to that patcher.c works
[4:40 PM] TuxSH: '_>'
[4:41 PM] astronautlevel: Can confirm, reverting the changes to patcher.c in 356268e fixed it

It seems like we found the source of the problem :P

[Petraplexity]

So adding "BOOTCONFIG(5, 1) && " did it.
(dunno what this implies, i'm a noob)
EDIT: But from the sound of it, it takes into account some user-defined options in the config menu in addition to what it already considered, breaking the SD card initialization.

[TuxSH]

It's to prevent bugs... it's likely a deeper bug...

[TuxSH]

Fixed.