Do you know how much memory the process was using when it crashed? This crash looks like a case of using more resources than allowed for a process in your system (although not in the usual way). It's always possible that the problem is a bug in Racket. I don't think it can be a bug in your program --- unless the bug allows more memory use than intended.
Details: The SIG_SEGV failure is consistent with the reported mprotect() failure, and the mprotect() failure is ENOMEM. Since ENOMEM can be reported when mprotect() is used on an address range that does not belong to the process, the error could reflect a bug in Racket. But the later crash is SIGSEGV_ACCERR, so I don't think that's it: the address appears to be mapped but without write permission, where the failing mprotect() call was intended to add write permission. The other possibly --- the one that's more consistent with the error name --- is that the kernel has run out of resources to perform the mprotect() change. Normally, if a Racket process is using lots of memory, it gets an out-of-memory condition trying to allocate new memory. But the kernel has an additional constraint on the size of the page-mapping table, and ENOMEM from mprotect() is related to that constraint. That is, a process can use less memory than allowed but at a granularity that creates too many page mappings within the process. In my Linux installations, /proc/sys/vm/max_map_count reports 65530. If every page has a different mapping, that limit can be reached with 256MB of memory use, potentially. Since Racket generally changes page properties in 16k chunks, 1GB is a more realistic lower bound. And since it's very unlikely for every 16k chunk to have a different mapping and permissions than its adjacent 16k chunks, you shouldn't expect to hit the mapping limit at around 1GB. If a process is using multiple GBs of memory, though, that could be it. At Sat, 14 Jan 2017 21:50:33 -0500, George Neuner wrote: > Hi all, > > re: Racket 6.5, prebuilt Linux x86_64 distribution > on Centos 6.8 > > > Had a crash in one of my headless webserver/database applications. The > application itself is 100% Racket (no FFI libs), using the webserver > and db modules heavily. The Racket install is default with no added > packages. > > The application has been in use for over a year with with no issues. > The server was restarted last on Dec 3, so at the time of the crash > the program had been running for ~37 days, though it was quiet through > much of the holidays. > > The logs show business as usual up until UTC 21:55h on Jan 9. > > > In the stdout (normal log) I found this: > SIGSEGV SEGV_ACCERR SI_CODE 2 fault on 0x7f20fbd8fd30 > > > And in the stderr (error log), which normally always is empty, I found > this: > mprotect failed: 7f20f4eb8000, 16760832, 1, 12 > mprotect failed: 7f20f8364000, 16777216, 1, 12 > mprotect failed: 7f20fb86c000, 8388608, 1, 12 > mprotect failed: 7f20fc988000, 4194304, 1, 12 > mprotect failed: 7f20fcff8000, 2097152, 1, 12 > Seg fault (internal error during gc) at 0x7f20fbd8fd30 > > > That's all. > > The server administrator restarted the application daemon (not the > server) about a 1/2 hour later. He saw nothing else wrong [with the > DBMS, HTTP server, etc.] and everything appeared to return to normal > as soon as he restarted the application. > > I did check the server's update logs, but there had been no updates > installed in the days prior to the crash. And no restarts for 37 > days. > > So I'm stumped. I can see the seg fault occurred in GC, but unless > somebody can say definitively that it looks like a bug in Racket, I > have to assume my code is somehow at fault. > > Since this problem has never occurred previously, I haven't a clue as > to how to troubleshoot it or prevent it from happening again. The > deployed application was not compiled with debug information. > > Anybody? > > Thanks, > George > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
