Bug #15066: PHP allocation failure in pfsense-utils.inc - pfSense - pfSense bugtracker

Actions

Copy link

Bug #15066

closed

PHP allocation failure in pfsense-utils.inc

Added by Alex Rosenberg 12 months ago. Updated about 1 month ago.

Status:

Duplicate

Priority:

Normal

Assignee:

Category:

PHP Interpreter

Target version:

Start date:

Due date:

% Done:

Estimated time:

Plus Target Version:

24.11

Release Notes:

Force Exclusion

Affected Version:

Affected Architecture:

amd64

Description

Plus 23.09 has been running without issue for some time until this crash report yesterday. No configuration changes of any kind had been made in weeks. Nobody tried to use the dashboard yesterday.

---
Crash report begins. Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT amd64 1400094 #0 plus-RELENG_23_09-n256163-2763857e770: Wed Nov 1 21:18:24 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_09-main/obj/amd64/WrS3lKLo/var/jenkins/workspace/pfSense-Plus-snapshots-23_09-main/

Crash report details:

PHP Errors:
[04-Dec-2023 12:09:03 America/Los_Angeles] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8192 bytes) in /etc/inc/pfsense-utils.inc on line 1772

No FreeBSD crash data found.

Related issues

Actions

Copy link

Updated by Jim Pingle 12 months ago

Status changed from New to Feedback

It's failing on a line in get_interface_info() where it is running a command to get pf statistics:

exec("/sbin/pfctl -vvsI -i {$chkif}", $pfctlstats);

The return result from that shouldn't be anything large enough to cause PHP to run out of memory, so I'm not sure what might be happening in this case.

For example:

: pfctl -vvsI -i igb1
igb1
        Cleared:     Wed Nov  1 09:25:33 2023
        References:  29                
        In4/Pass:    [ Packets: 6887372            Bytes: 299573985          ]
        In4/Block:   [ Packets: 0                  Bytes: 0                  ]
        Out4/Pass:   [ Packets: 6818342            Bytes: 649206522          ]
        Out4/Block:  [ Packets: 0                  Bytes: 0                  ]
        In6/Pass:    [ Packets: 5874446            Bytes: 294491334          ]
        In6/Block:   [ Packets: 0                  Bytes: 0                  ]
        Out6/Pass:   [ Packets: 5864430            Bytes: 292400274          ]
        Out6/Block:  [ Packets: 0                  Bytes: 0                  ]

That function is used in a variety of places, including several dashboard widgets, the interface status page, and in a couple spots when unbound is creating its configuration. So it's possible something else is running PHP out of RAM and this is just the last thing to run.

If you can reproduce it reliably, we'll need to know a bit more about how it happened. If nobody was using the Dashboard then it was probably from Unbound, but I don't see how it would be failing there either unless something else (e.g. pfBlocker/DNSBL) is creating a gigantic Unbound configuration.

Actions

Copy link

Updated by Alex Rosenberg 12 months ago

Jim Pingle wrote in #note-1:

That function is used in a variety of places, including several dashboard widgets, the interface status page, and in a couple spots when unbound is creating its configuration. So it's possible something else is running PHP out of RAM and this is just the last thing to run.

If you can reproduce it reliably, we'll need to know a bit more about how it happened. If nobody was using the Dashboard then it was probably from Unbound, but I don't see how it would be failing there either unless something else (e.g. pfBlocker/DNSBL) is creating a gigantic Unbound configuration.

I've never seen it before, but will look out for it to recur.

I use the DNS Forwarder, not the Resolver which is disabled. I think that means I'm not using Unbound at all. I'm also not using pfBlocker/DNSBL.

Actions

Copy link

Updated by Alex Rosenberg 11 months ago

Happened again. No idea why. Again, no use of the dashboard at the time.

Crash report begins. Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT amd64 1400094 #1 plus-RELENG_23_09_1-n256200-3de1e293f3a: Wed Dec 6 21:00:32 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_09_1-main/obj/amd64/Obhu6gXB/var/jenkins/workspace/pfSense-Plus-snapshots-23_09_1

Crash report details:

PHP Errors:
[28-Dec-2023 04:43:21 America/Los_Angeles] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8192 bytes) in /etc/inc/pfsense-utils.inc on line 1772

No FreeBSD crash data found.

Actions

Copy link

Updated by Alex Rosenberg 7 months ago

Once again, happened while I was out of the country and not interacting with pfSense at all:

Crash report begins. Anonymous machine information:

Crash report details:

PHP Errors:
[07-Apr-2024 12:44:38 America/Los_Angeles] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 8192 bytes) in /etc/inc/pfsense-utils.inc on line 1772

No FreeBSD crash data found.

Actions

Copy link

Updated by Marcos M 6 months ago

Status changed from Feedback to Duplicate
Plus Target Version set to 24.07
Release Notes changed from Default to Force Exclusion

The root issue here is probably #15471. The function get_interface_info() ends up calling get_interface_addresses() which calls the problematic function pfSense_get_ifaddrs(). The original report points to the pfctl line, but the memory allocation there looks normal and is unlikely to be the cause considering the known memory leak.

Actions

Copy link