This is a consequence of the PHP process itself running out of memory. Because the output is being buffered in an attempt to improve efficiency, I suspect the PHP "out-of-memory" error is getting swallowed during the buffering and not displayed.
There is no stateful function for reading and outputting very large text files in PHP. The only process currently available is to read the entire text file (the Snort active rules in this case) into PHP's allocated RAM space and store it as a string. The content of that stored string is then written out as HTML to the client. No matter how much RAM is in the firewall, there is a fixed limit on the memory PHP will use for string and other variables storage that is set within the php.ini file.
When you have lots of enabled rules, then trying to view the "Active Rules" on the RULES tab in Snort or Suricata is likely to crash. Whether or not that happens is strictly up to exactly how many rules you have enabled. If the file that holds the active rules is too large, it won't fit into the PHP string memory space and you will get the error. Custom Rules are not invovled here other than the act of including them (if there are enough of them) in the list along with all the other rules may be enough to push you over the edge and run out of PHP string memory.
The same kind of error occurs when you try to view very large log files in Snort, Suricata, or any of the other packages (pfBlocker and others). The same thing can happen if you try to open any large text file on pfSense (search the forum for examples of this from certain logs).
The error only impacts the currently active PHP process that is outputting to the client display. It does not interrupt the operation of pfSense nor Snort itself. The binary is still running and offering protection and logging. Only that particular GUI session showing the active rules is impacted. You can simply reload the page or move to another tab and the GUI is instantly recovered.
Using web pages created via PHP to implement a GUI is not the same kind of environment as you have in a C, C#, Java or other program running directly in Windows or Linux. You don't have that same level of two-way back and forth between the pieces. With a web-based GUI, you basically do all the processing on the server and attempt to dump it as HTML to a dumb client (your browser in this case). You have no easy and reliable way to "remember" where you are when reading a large file and dumping it out. That's because each PHP GUI client session is essentially stateless. Once it dumps the current output stream, the process exits. That's different from something like a word processor window in a conventional OS GUI where you can precisely control how you read from a file in chunks and output those chunks to the display. Doing that in PHP with a stateless web session is not the same. I've toyed around with trying to implement a type of "paged output" for this situation and similar ones with large log files. But so far I've not come up with something that seems ideal.
So, the TLDR version is this -- it's a known problem with no easy fix. It is the same issue that impacts many other packages (and even pfSense itself) when trying to read very large text files and output their content to the GUI display
Updated by 
Updated by 
Updated by 
Updated by Ryan Coleman 
Updated by 
