Project

General

Profile

Actions

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.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Traffic Shaper (ALTQ)
Target version:
Start date:
08/06/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4
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.?.

Actions #1

Updated by Anonymous over 5 years ago

  • Status changed from New to 13
  • Assignee set to Anonymous
Actions #2

Updated by Anonymous over 5 years ago

  • Status changed from 13 to Feedback
  • % Done changed from 0 to 100
Actions #3

Updated by Pi Ba over 5 years ago

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..)

Actions #4

Updated by Jim Pingle over 5 years ago

  • 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.

Actions

Also available in: Atom PDF