https://redmine.pfsense.org/https://redmine.pfsense.org/favicon.ico?16780521162015-07-24T02:31:01ZpfSense bugtrackerpfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=194172015-07-24T02:31:01ZKill Bill
<ul></ul><p>Perhaps also this (copied from pfBNG update log) - really cannot see how I'm hitting the 10M limit here.</p>
<pre>
Alias Table IP Counts
-----------------------------
485649 total
443746 /var/db/aliastables/pfB_P2P.txt
29253 /var/db/aliastables/pfB_CUST.txt
4848 /var/db/aliastables/pfB_IBlock.txt
2728 /var/db/aliastables/pfB_PRI3.txt
2101 /var/db/aliastables/pfB_Europe_v4.txt
1498 /var/db/aliastables/pfB_PRI1.txt
514 /var/db/aliastables/pfB_Europe_v6.txt
426 /var/db/aliastables/pfB_SEC1.txt
208 /var/db/aliastables/pfB_SEC2.txt
160 /var/db/aliastables/pfB_PRI2.txt
140 /var/db/aliastables/pfB_PS_v4.txt
27 /var/db/aliastables/pfB_DNSBLIP.txt
pfSense Table Stats
-------------------
table-entries hard limit 10000000
Table Usage Count 485681
</pre> pfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=196922015-07-28T05:33:12ZKill Bill
<ul></ul><p>Well I think I have found something (basically, kernel limits issue), but the hints there are not useful since kern.maxdsiz is 34359738368 B here (~33GiB).</p>
<p><a class="external" href="https://lists.freebsd.org/pipermail/freebsd-pf/2011-May/006139.html">https://lists.freebsd.org/pipermail/freebsd-pf/2011-May/006139.html</a></p> pfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=221972015-11-10T23:54:40ZChris Buechlercbuechler@gmail.com
<ul><li><strong>File</strong> <a href="/attachments/1428">config-bootstrap-test1.pfmechanics.com-20151110235247.xml</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/1428/config-bootstrap-test1.pfmechanics.com-20151110235247.xml">config-bootstrap-test1.pfmechanics.com-20151110235247.xml</a> added</li><li><strong>Status</strong> changed from <i>New</i> to <i>Confirmed</i></li><li><strong>Assignee</strong> set to <i>Luiz Souza</i></li><li><strong>Target version</strong> set to <i>2.3</i></li><li><strong>Affected Architecture</strong> <i>All</i> added</li><li><strong>Affected Architecture</strong> deleted (<del><i>amd64</i></del>)</li></ul><p>this seems to be even easier to replicate on 2.3. Take the attached config, restore it, and on boot it'll throw out:<br /><pre>
"pf_busy";s:6:"notice";s:38:"PF was wedged/busy and has been reset.";s:3:"url";s:0:"";s:8:"category";s:7:"pf_busy";s:8:"priority";i:1;}i:1447221238;a:5:{s:2:"id";s:11:"filter_load";s:6:"notice";s:105:"There were error(s) loading the rules: pfctl: DIOCADDALTQ: Device busy - The line in question reads [0]: "
</pre></p>
<p>post-boot, most of the time upon running /etc/rc.filter_configure_sync you'll end up with: <br /><pre>
"There were error(s) loading the rules: /tmp/rules.debug:42: cannot define table pfB_P2P: Cannot allocate memory - The line in question reads [42]: table <pfB_P2P> persist file "/var/db/aliastables/pfB_P2P.txt"
</pre></p>
<p>adding the following lines for debug in filter.inc: <br /><pre>
@file_put_contents("{$g['tmp_path']}/rules.limits", $limitrules);
$debugtime = time();
mwexec("cp /tmp/rules.limits /root/$debugtime-rules.limits");
mwexec("/sbin/pfctl -Of {$g['tmp_path']}/rules.limits");
unset($rules, $limitrules);
mwexec("pfctl -sm > /root/$debugtime-limits.txt");
</pre><br />shows that the rules.limits it's applying are correct, and 'pfctl -sm' shows the correct limits, before it attempts to load the rules. The limits are well above the size of the table. Later trying to just load the rules may work, or may result in the same.</p>
<pre>
# pfctl -f /tmp/rules.debug
/tmp/rules.debug:42: cannot define table pfB_P2P: Cannot allocate memory
pfctl: Syntax error in config file: pf rules not loaded
# pfctl -f /tmp/rules.debug
#
</pre>
<p>worked fine the second time. Sometimes the second attempt fails as well and a third might succeed. I can't seem to find a sure fire differentiation between when it works and when it doesn't, but it fails frequently with the attached config.</p> pfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=226992015-11-19T04:01:59ZKill Bill
<ul></ul><p>Chris Buechler wrote:</p>
<blockquote>
<p>Later trying to just load the rules may work, or may result in the same. <br />worked fine the second time. Sometimes the second attempt fails as well and a third might succeed. I can't seem to find a sure fire differentiation between when it works and when it doesn't, but it fails frequently with the attached config.</p>
</blockquote>
<p>Very much matches my observation. No clear pattern and sometimes requires more attempts to finally get the table loaded. Should this be filed in FreeBSD bugzilla perhaps? NFC what's this, but it's annoying for sure.</p> pfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=228862015-11-22T14:42:13ZLuiz Souzaluiz@netgate.com
<ul></ul><p>I'm trying to reproduce this, but no success so far (trying with a RCC-VE 4860).</p> pfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=254882016-03-01T12:34:11ZChris Buechlercbuechler@gmail.com
<ul></ul><p>this is still easily replicable with the config I attached. Sent Luiz a system that's running it and still sees the issue.</p> pfSense - Bug #4876: Cannot define table: Cannot allocate memory with large table aliaseshttps://redmine.pfsense.org/issues/4876?journal_id=255882016-03-05T18:39:27ZChris Buechlercbuechler@gmail.com
<ul><li><strong>Status</strong> changed from <i>Confirmed</i> to <i>Closed</i></li><li><strong>Target version</strong> deleted (<del><i>2.3</i></del>)</li><li><strong>Affected Version</strong> changed from <i>2.2.x</i> to <i>All</i></li></ul><p>Luiz tracked down the root cause to actual memory allocation failures. "it uses memory from the uma allocator, the uma tries to be smart and start to deny some bigger allocations under low memory conditions but before it actually exhaust the memory"</p>
<p>It's easily replicable with a big enough config and 256 or 384 MB RAM. But with 512 MB or more, it's not an issue.</p>
<p>In short, you can fail to allocate memory in this situation even if there is some memory or swap available, so huge tables aren't doable with small amounts of RAM.</p>