Feedback Homebrew "Data abort" error when opening homebrew.

[pansy_thoughts]

hey, newbie here

so, I've been tinkering and learning to make DS homebrew, only with libnds and nflib for now.

and when opening one of the things I made on my DS Lite, this error came up:

tried it on my old 3DS, and same.
I have made some programs before, using at most nflib's sprite functions, and they have worked just fine. this one doesn't (it does work on emulator, though).
from what I read, this may have to do with the physical MPU inside the DS, and that I may have screwed up something with the memory.
I only used memory loading functions from nflib (NF_LoadSpriteGfx(), NF_LoadSpritePal() and such).
any advice or help is appreciated, and tell me if you need the code.

Post automatically merged: Mar 12, 2025

if it helps, here's the code of a function I made that could be part of the problem:

void assignSpritesToMemory(){
    for(int i = 0; i < 3; i++){
    NF_LoadSpriteGfx(sprite_dir[i], i, size_x, size_y);//(file, RAM slot, size x, size y)
    NF_LoadSpritePal(palette_dir[i], i);               //(file, RAM slot)

    //Cargar el sprite junto a su paleta de la RAM a la VRAM.
    NF_VramSpriteGfx(screen, i, i, true);//(screen, RAM slot, VRAM slot, copy all frames to VRAM)
    NF_VramSpritePal(screen, i, i);      //(screen, RAM slot, VRAM slot)
    }

I'm not really an expert at coding, in case you were wondering.

 

[AntonioND]

Hi! Are you checking that "nitroFSInit()" returns success? It's possible that it's failing to start and that's why it eventually crashes.

You need something like this:

bool init_ok = nitroFSInit(NULL);
if (!init_ok)
{
    perror("nitroFSInit()");
    wait_forever();
}

Also, there's a debugging guide here if that doesn't help: https://blocksds.skylyrac.net/docs/usage/debugging/

 

[pansy_thoughts]

hey, thanks for replying!
i've checked and nitroFSInit() indeed returns 'true' every time I open the build (which is kinda obvious since it can read the sprite/pallette files just fine, because they show up on screen).

I included defaultExceptionHandler() in my main(), as shown in the debugging guide, and now it shows the ''Guru Meditation Error!''

I don't know if this information could be of any help.

the guide indeed says that the error is most probably caused because the ARM9 chip is trying to access addresses where there's no memory (from what I understand), but, how can these kinds of things happen when using nflib functions?

 

[AntonioND]

Yes, NFlib could have crashes like that one if the user calls NFlib functions with invalid arguments.

The crash handler is only useful to you because you have the source code and ELF file generated during the build. The debugging guide explains how to use addr2line to get the source code line where the game crashes.

 

[plasturion]

But it can be even some unitialized variable/array/pointer or wrong calculated that idicate address above 4MB for DS or 16MB for DSi. Every single attempt to read out of bonduary RAM address result instantly freeze or guru meditation screen, while on emulator can work perfectly fine. (same reason that many bad written romhacks or translations works fine on emus while not on real hardware). addr point on some 300MB+ location, sounds pretty random to me.