pfSense

Normally I'd say we could just change the lines there to cast to int but I'm curious why it fails to automatically convert for them. It implies it was getting back some kind of non-numeric/nonsense value or other bad data at some point.

Even if I do something that would normally break or act weird (like the same operation on 32-bit ARM but with a value > PHP_INT_MAX), it still doesn't generate that PHP error.

That error implies the function would need some other kind of error checking beyond type casting but it's not clear what would be sufficient given that when they run it by hand the data looks OK.

The large gap between the errors implies it isn't happening constantly, too. Since this is coming from the system info dashboard widget code path I'd expect it to happen every time it polls data unless there is some other factor that contributes to it getting back bad data.

I also get similar error:

PHP ERROR: Type: 1, File: /etc/inc/util.inc, Line: 2479, Message: Uncaught TypeError: Unsupported operand types: string / int in /etc/inc/util.inc:2479
Stack trace:
#0 /etc/inc/pfsense-utils.inc(2013): get_memory()
#1 /usr/local/www/includes/functions.inc.php(104): pfsense_default_state_size()
#2 /usr/local/www/includes/functions.inc.php(46): get_pfstate(true)
#3 /usr/local/www/getstats.php(40): get_stats(Array)
#4 {main}

hw.physmem: 16878309376
hw.realmem: 17179869184

It happens randomly. If anything you want me to collect or look for plz let me know. This only started after upgrading to 23.05.1-RELEASE (amd64)

Testing I have done:
1st did remove widgets and add them
- no resolve

2nd tried differ ddr5 memory (went through 3 sticks/ N200 cpu so single channel)
- no resolve

3rd resintalled pfsense on a new NVMe
- Didnt have error for 1 week and just returned this morning.

HW im using:
CPU; N200
Memory: CORSAIR Vengeance SODIMM DDR5 RAM 16GB
mobo: cant tell since its a NUC with 4 x i226 intel ports

var_dump(""/1000); produces the same error

the empty string does not cleanly cast automatically to an int.

get_single_sysctl returns the empty string

Yeah that's what I figured but what I can't figure out is why it would ever come back blank for that OID. I can't make that happen here and it isn't clear why it would happen some times and not others.

I never could reproduce the error condition but I added several safety belts to ensure the values are sane coming out of that function now. Commit is coming momentarily.

Got a slightly different variant (havent changed anything):

PHP ERROR: Type: 1, File: /etc/inc/util.inc, Line: 2479, Message: Uncaught TypeError: Unsupported operand types: string / int in /etc/inc/util.inc:2479
Stack trace:
#0 /etc/inc/pfsense-utils.inc(2013): get_memory()
#1 /etc/inc/filter.inc(510): pfsense_default_state_size()
#2 /etc/rc.filter_configure_sync(32): filter_configure_sync()
#3 {main}
thrown @ 2023-08-10 17:39:11

rash report begins. Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 plus-RELENG_23_05_1-n256108-459fc493a87: Wed Jun 28 04:26:04 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/obj/amd64/f2Em2w3l/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/sources/

Crash report details:

PHP Errors:
[10-Aug-2023 17:39:11 America/New_York] PHP Fatal error: Uncaught TypeError: Unsupported operand types: string / int in /etc/inc/util.inc:2479
Stack trace:
#0 /etc/inc/pfsense-utils.inc(2013): get_memory()
#1 /etc/inc/filter.inc(510): pfsense_default_state_size()
#2 /etc/rc.filter_configure_sync(32): filter_configure_sync()
#3 {main}
thrown in /etc/inc/util.inc on line 2479

I have now patched with 054c25418f28bd0afeb1e4a3f07075db76f8f61b.

Those are the exact same errors as above. You can try the patch above and see if you can reproduce it after.

At this point additional error reports are not necessary unless you can figure out how to reproduce it reliably.

It happens in my case after logging into the system based on the time stamp as its the same time as my login.
not sure if helps but I will update if it occurs again

Hi
I received the error again

Crash report begins. Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 plus-RELENG_23_05_1-n256108-459fc493a87: Wed Jun 28 04:26:04 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/obj/amd64/f2Em2w3l/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/sources/

Crash report details:

PHP Errors:
[13-Aug-2023 11:26:28 America/New_York] PHP Fatal error: Uncaught DivisionByZeroError: Division by zero in /usr/local/www/includes/functions.inc.php:219
Stack trace:
#0 /usr/local/www/includes/functions.inc.php(33): mem_usage()
#1 /usr/local/www/getstats.php(40): get_stats(Array)
#2 {main}
thrown in /usr/local/www/includes/functions.inc.php on line 219

No FreeBSD crash data found.

Error looks little different than before

Michael Clews wrote in #note-12:

Hi
I received the error again

Is that with the patch applied or without it?

Jim Pingle wrote in #note-13:

Michael Clews wrote in #note-12:

Hi
I received the error again

Is that with the patch applied or without it?

Ok, this happened a week or a bit more after applying the patch 054c25418f28bd0afeb1e4a3f07075db76f8f61b.

Crash report begins.  Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 plus-RELENG_23_05_1-n256108-459fc493a87: Wed Jun 28 04:26:04 UTC 2023     root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/obj/amd64/f2Em2w3l/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/sources/

Crash report details:

PHP Errors:
[18-Aug-2023 13:21:31 Etc/UTC] PHP Fatal error:  Uncaught DivisionByZeroError: Division by zero in /usr/local/www/includes/functions.inc.php:219
Stack trace:
#0 /usr/local/www/includes/functions.inc.php(33): mem_usage()
#1 /usr/local/www/getstats.php(40): get_stats(Array)
#2 {main}
  thrown in /usr/local/www/includes/functions.inc.php on line 219

No FreeBSD crash data found.

I don't even know what is triggering that, something in the background of pfsense does, but dunno how to trigger it.
Why not do a patch against that function to dump everything, env and what not? At least maybe dump the systctl values on error? Since that's what is causing the problem.

Or maybe just give me a small php script that invokes the function that fails. Then I can throw it in a loop, running every second and monitor it for failures.

Suika Ibuki wrote in #note-16:

Why not do a patch against that function to dump everything, env and what not? At least maybe dump the systctl values on error? Since that's what is causing the problem.

That could end up generating so much data it might be hard to sort through, but it may come to that.

Or maybe just give me a small php script that invokes the function that fails. Then I can throw it in a loop, running every second and monitor it for failures.

Could start with a simple PHP script that checks this:

var_dump(get_sysctl("hw.physmem"));

Or a shell script that checks:

sysctl -iq hw.physmem

If either of those is empty or 0, then it would help to see:

sysctl -a

Hi

For the last 2 hrs been running script to keep getting that output every 1 second..
It hasn't come up blank or 0 once.

Will keep running for the next week and will update

Okay,

So I have been running sysctl -iq hw.physmem for every 10 seconds and it has NEVER returned 0 but today i have had my system crash over 12 times:

Crash report begins. Anonymous machine information:

amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 plus-RELENG_23_05_1-n256108-459fc493a87: Wed Jun 28 04:26:04 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/obj/amd64/f2Em2w3l/var/jenkins/workspace/pfSense-Plus-snapshots-23_05_1-main/sources/

Crash report details:

PHP Errors:
[14-Oct-2023 17:43:32 America/New_York] PHP Fatal error: Uncaught DivisionByZeroError: Division by zero in /usr/local/www/includes/functions.inc.php:219
Stack trace:
#0 /usr/local/www/includes/functions.inc.php(33): mem_usage()
#1 /usr/local/www/getstats.php(40): get_stats(Array)
#2 {main}
thrown in /usr/local/www/includes/functions.inc.php on line 219

No FreeBSD crash data found.

Is there anyworkaround to this? as to me without functioning workaround all my things stop working during this crash (increase latency)

Reviewing this it appears everyone hitting this is running an Intel Nxxx CPU. Is anyone hitting it on something else?

Steve Wheeler wrote in #note-25:

Reviewing this it appears everyone hitting this is running an Intel Nxxx CPU. Is anyone hitting it on something else?

Yeah sure, I'm getting these crashes on a Intel(R) Core(TM) i5-6400T CPU