As those who have been watching the progress of nDoom might have noticed, I've been fighting a bug that triggers a crash/restart (depending on the exact release) upon exit ever since the start of the project.
Before, I thought that it made sense, since I still had unfreed memory lying about when the program finished, and files that weren't getting closed. Today, however, I fixed up all those points, but the crash still remains; It is giving me a different error, but the end effect is the same.

Now, although I've got experience in computer programming generally, as well as in assembly specifically, I am quite a newbie when it comes to C, and so I wish to ask anyone skilled in this language - aside from unfreed memory and files not closed, could there be other causes for a crash that happens after the main() function returns? Or is it more probable that I've missed a free() somewhere? And could some 7 random bytes of unallocated memory somewhere really cause the calculator to restart (consistently, every single time the program exits)?
The Doom source I've based my project on uses some quite ugly hacks, so even outlandish suggestions are welcome, since one of those hacks might be triggering an extremely rare bug somewhere (note: although it uses some interesting hacks, it doesn't use any ASM() statements).

Furthermore, while the errors the emulator gives are extremely useful whilst coding in Assembly, am I correct in thinking that they're absolutely useless when coding in C, as the compiler abstracts most of the register/memory accesses away from the programmer?

Finally, could anyone explain what decides whether the Nspire just freezes, or also reboots, after a program crash? I've seen both, and there doesn't appear to have been much of a pattern.

Can somehow your program and/or WAD file be overwriting a crucial part in memory responsible for displaying stuff on the LCD?

Silver Shadow, I don't think memory's getting overwritten here... it seems to crash independently of whether the wad file is loaded or not.

This might be it! :
A screen buffer is equal to SCREEN_WIDTH*SCREEN_HEIGTH/2, so this would be 320*240/2, not 320*240
Try using the constant "SCREEN_BYTES_SIZE" for the third argument of memcpy!

The screen buffer's that size only if you're in 4bpp mode... I'm using 8bpp (so I don't have to bother with nibble->byte conversion), where the screen buffer is indeed 320*240 (hence using SCREEN_BYTES_SIZE gives you only half the screen in this mode).
I wonder if I've screwed up while setting the display mode...

EDIT: Yup, I seem to have screwed up. Removing the writes to 0xC000001C (LCD configuration), and changing third argument of memcpy() to SCREEN_BYTES_SIZE removes all crashing. I'll see if I can fix this bug before sleeptime...

Well, it's not quite fixed yet, I've had that argument in there for a reason... right now, only the top half of the screen is displayed. However, no crashing, and I'm working on getting fullscreen back.
Also, I've figured out a problem with my palette settings - apparently, it's bits 1-4 that determine the screen brightness, not 0-3... that means I was only using 8 colours out of 16, which I think would explain the low contrast.
Depending on how long it takes to fix this bug, I should have a bugfix release out either tomorrow or Wednesday.

Are you using the normal SCREEN_BASE_ADDRESS for the buffer? Because I don't think there are 320*240 bytes there allocated for screen data alone. You're probably overwriting other data used by the OS.

Good luck with the bug Mraklopaz!

Gotcha, thats what i meant :] Awesome!

Great to see all these bugs being squashed!