GameInfo reading out of buffer

PypeBros · 2017-10-27 19:44:05

I encountered a weird panic message while developing new homebrew with desmume. I guess it means my program is accessing something (code?) out of the allowed cartridge area. What puzzles me is why it is killing the emulator so abruptly ?

I've seen other error condition that dumped some registers, and others that could be trapped with the GDB server embedded in the emulator. Nothing alike here? Just because noone has added it yet ? or is there any other reason ?

zeromus · 2017-10-28 22:39:53

Check one:
[ ] I understand that errors have been inconsistently handled by dumping registers, or trapping with the GDB server embedded in the emulator, but I am surprised that still more errors have been inconsistently handled in a 3rd way by terminating the emulator
[ ] I understand that errors have been inconsistently handled by dumping registers, or trapping with the GDB server embedded in the emulator, so I am not surprised that still more errors have been inconsistently handled in a 3rd way by terminating the emulator

PypeBros · 2017-10-29 09:45:38

[x] I understand that errors have been inconsistently handled by dumping registers, or trapping with the GDB server embedded in the emulator, but I am surprised that still more errors have been inconsistently handled in a 3rd way by terminating the emulator.

Especially, before starting to hack the code by adding some calls to emu_halt here and there, I was looking for wisdom from The Builders about why there might be that third way. If i understand your check-one post correctly, there was no reason for not invoking something more elaborate than exit(), just that noone did it so far.

So, would there be a function name I should have a look at that could trap the GDB server instead of exit() ?

zeromus · 2017-10-29 18:47:15

there is no wisdom. there is no reason.

ideally you would figure out what correct emulation should do, and fix it to do that instead of exit.

PypeBros · 2017-10-30 08:50:41

ok.

FYI, the problem appeared while trying to use a --gbaslot-rom=self with a romsize of 302254 (which I note to be not a multiple of 4). The crash occurs when a memcpy starts reading that byte-per-byte, with a position of 302251, where "pos + 4 > romsize" occurs first.

I'm afraid I cannot tell what real hardware would do then, because on real hardware, I have some DLDI code in the play. It could very well be that using memcpy to read from the GameInfo area is a mistake, and that e.g. only 4-bytes-aligned or 2-bytes-aligned reads are allowed. It could also be that my tools are incorrect and that producing a rom that isn't a multiple of (whatever) is a mistake.

I just fixed my problem by adding some unused bits at the end of the "embedded filesystem" area of my .nds file. Not very elegant, but it will do the trick for now.

Thanks for your help.

#1 2017-10-27 19:44:05

GameInfo reading out of buffer

#2 2017-10-28 22:39:53

Re: GameInfo reading out of buffer

#3 2017-10-29 09:45:38

Re: GameInfo reading out of buffer

#4 2017-10-29 18:47:15

Re: GameInfo reading out of buffer

#5 2017-10-30 08:50:41

Re: GameInfo reading out of buffer

Board footer