BUG: most likely XN tries to hog memory, and checks whether it got the memory (like (malloc(blah)!=0), so far good). But if it doesn't get the memory, it destroys the image in memory (sets to 0x0 pixel), instead of refusing to complete, and throwing a suitable message.

Q: does XN backup the complete image for every edit? How many undo-backups does it keep?
SUGG: add [0] "disable saving undo-backups" option and [1] "clear existing undo-backups" possibility - this will allow to edit bigger images faster or at all.
Still the "0x0-pixel-problem" is a BUG, the optimal way to reproduce it reliably is low RAM (<= 512 MiB) and a small fixed-size swap file (<=128 MiB) (believe or not, I still use my good old 64 MiB laptop).
IIRC long ago I had reported bad behaviour on huge images in NC too, no undo here, still not able to deal reasonably with the fact that a memory allocation failed.