Bug #8757
closed
PHP Warning: A non-numeric value encountered in /etc/inc/shaper.inc on line 467
Added by Pi Ba over 5 years ago.
Updated over 5 years ago.
Category:
Traffic Shaper (ALTQ)
Affected Architecture:
All
Description
Crash report begins. Anonymous machine information:
amd64
11.2-RELEASE
FreeBSD 11.2-RELEASE #51 cd0e4c8cf25(RELENG_2_4_4): Mon Aug 6 09:03:00 EDT 2018 root@buildbot3:/builder/crossbuild-ce-master/obj/amd64/FWJoMRHc/builder/crossbuild-ce-master/pfSense/tmp/FreeBSD-src/sys/pfSense
Crash report details:
PHP Errors:
[06-Aug-2018 23:55:14 CET] PHP Warning: A non-numeric value encountered in /etc/inc/shaper.inc on line 467
No FreeBSD crash data found.
If further info is needed i can try and provide some. Its a kinda large config, so not easy to pinpoint the root cause for a reproduction.. Perhaps the fix is easy though.?.
- Status changed from New to 13
- Assignee set to Anonymous
- Status changed from 13 to Feedback
- % Done changed from 0 to 100
The error no longer happens on 2.4.4-DEVELOPMENT (amd64) built on Wed Aug 08 12:58:30 EDT 2018
So in that regard it could be closed, the thing i wonder about though, is it the 'proper' fix.? Shouldn't the calling function already provide a number for that bw parameter.?. And as such could it be indicative of a bigger problem?
( Also as a side note, why does a patch to fix a problem on line 457 contain white space changes to line 5286 ? It seems to invite merge conflicts.. and rebasing PRs isnt a hobby of mine..)
- Status changed from Feedback to Resolved
Pi Ba wrote:
The error no longer happens on 2.4.4-DEVELOPMENT (amd64) built on Wed Aug 08 12:58:30 EDT 2018
So in that regard it could be closed, the thing i wonder about though, is it the 'proper' fix.? Shouldn't the calling function already provide a number for that bw parameter.?. And as such could it be indicative of a bigger problem?
It could be, but it could also mean that it's an empty string that would have always resulted in PHP casting to 0 in previous versions of PHP. So if there is a bug, it's not directly related to this change, but a larger issue in what's calling this. This fix will preserve existing behavior though, so from a user perspective it should be consistent with previous versions.
( Also as a side note, why does a patch to fix a problem on line 457 contain white space changes to line 5286 ? It seems to invite merge conflicts.. and rebasing PRs isnt a hobby of mine..)
Probably a change made by the text editor and not 100% intentional. Usually we try to avoid mixing whitespace and other changes in a single commit but sometimes they sneak by.
Also available in: Atom
PDF
Updated by Anonymous 
Updated by 
Updated by