chrisfu
commented
9 years ago I appear to have fixed this by commenting out the ncch.c:130, which was the line I highlighted earlier. Performing a stack trace highlighted that the romfs.bin.out file had already been closed previously.
stat("tmp/ctrtool/romfs.bin.out", {st_mode=S_IFREG|0664, st_size=1750339584, ...}) = 0
open("tmp/ctrtool/romfs.bin.out", O_RDONLY) = 3
stat("tmp/exefs/banner.bin", {st_mode=S_IFREG|0664, st_size=123144, ...}) = 0
open("tmp/exefs/banner.bin", O_RDONLY) = 4
stat("tmp/exefs/icon.bin", {st_mode=S_IFREG|0664, st_size=14016, ...}) = 0
open("tmp/exefs/icon.bin", O_RDONLY) = 5
stat("tmp/exefs/code.bin", {st_mode=S_IFREG|0664, st_size=6037504, ...}) = 0
open("tmp/exefs/code.bin", O_RDONLY) = 6
stat("tmp/ctrtool/exheader.bin.out", {st_mode=S_IFREG|0664, st_size=2048, ...}) = 0
open("tmp/ctrtool/exheader.bin.out", O_RDONLY) = 7
brk(0x1b09000) = 0x1b09000
...snip...
brk(0x1e5b000) = 0x1e5b000
fstat(3, {st_mode=S_IFREG|0664, st_size=1750339584, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa8d1bde000
lseek(3, 0, SEEK_SET) = 0
read(3, "IVFC\0\0\1\0@\3\0\0\0\0\0\0\0\0\0\0 \236\1\0\0\0\0\0\f\0\0\0"..., 4096) = 4096
mmap(NULL, 1753833472, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa867532000
lseek(3, 4096, SEEK_SET) = 4096
read(3, "(\0\0\0(\0\0\0\224\3\0\0\274\3\0\0\4\36\0\0\300!\0\0\224x\0\0T\232\0\0"..., 1750335488) = 1750335488
close(3) = 0 # <---- tmp/ctrtool/romfs.bin.out being closed
munmap(0x7fa8d1bde000, 4096) = 0
close(4) = 0 <---- tmp/exefs/banner.bin being closed
munmap(0x7fa8d1be2000, 4096) = 0
close(5) = 0 <---- tmp/exefs/icon.bin being closed
munmap(0x7fa8d1be1000, 4096) = 0
close(6) = 0 <---- tmp/exefs/code.bin being closed
munmap(0x7fa8d1be0000, 4096) = 0
close(7) = 0 <---- tmp/ctrtool/exheader.bin.out being closed
munmap(0x7fa8d1bdf000, 4096) = 0
# It's at this point where according to FreeNcchSettings function in ncch.c, it would again attempt to close romfs.bin.out
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x10} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)Unsure as to the impact of commenting out that line, but I can confirm that it doesn't appear to result in a memory leak of any sort. After some further testing, if I can confirm this to be stable I'll create a pull request.
Just out of curiosity, was anybody else suffering from the same issue?
mid-kid
Using head (currently 4fcc4665851c80036e56da5bff5346a788dd4fb5) and building from git, I'm seeing a segfault when trying to build a .cxi using makerom. Interestingly, using a Windows x64 build obtained from an alternate source via wine doesn't have this issue, but then again I can't be sure that it wasn't an earlier build (though it's tagged as makerom 0.13).
Recompiled with debugging symbols and run through gdb so that you can see the back-trace. I'm unsure if the same issue exists when building in Windows with mingw.
This happens consistently regardless of the extracted (and dependant on the source, decrypted) rom that I attempt to rebuild.
The line (and owning function) in question that appears to be causing the segfault in ncch.c is as follows:
I've suspected that memory could potentially be an issue, but considering I'm running 8GB of memory in my machine and that the makerom.exe (x64) build works fine via Wine, I'm guessing that memory limitations are not the cause here factoring in the overhead of Wine.
Finally, here is the size of the decrypted romfs.bin I've been using in this case:
If any more information is required, drop me a message.