Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PHP error_reporting level changed?

    2.2 Snapshot Feedback and Problems - RETIRED
    3
    5
    1.3k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      phil.davis
      last edited by

      I notice that now a lot of warning/deprecated sort of messages are now being emitted - which is a good thing and the reasons should be found and fixed. But I don't remember seeing a change that modified the general/default error_reporting settings.
      Did that change a few days ago?

      If so, from what to what?

      (I guess the setting is in pfsense-tools build somewhere - I haven't looked at that)

      It would just be nice to know what default error reporting is on now, so as to give an idea of the range of fussy stuff that might be reported to syslog or pop out accidentally as text on the GUI.

      As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
      If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

      1 Reply Last reply Reply Quote 0
      • F
        fragged
        last edited by

        https://github.com/pfsense/pfsense/commit/be2d7eb7c6de1ecd1034e2a8dc6a8d38e1fc9d03

        Related? :)

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by

          I must be blind - I remember seeing that now!
          At the end of a script that is reporting the last error seen, if the last error is not E_NOTICE.
          I was trying to reproduce the message:

          php-fpm[16262]: /rc.newipsecdns: PHP ERROR: Type: 8192, File: /etc/inc/shaper.inc, Line: 4365, Message: Assigning the return value of new by reference is deprecated

          That is reported in https://forum.pfsense.org/index.php?topic=86448.0
          I could not get it to do it on my system, with a few limiters. Then I took out the "not E_NOTICE" check. Then I started seeing the last error regardless of what it is. There are various E_NOTICE errors that happen on my configuration after the error, like:

          http://php-fpm[18230]: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 4371, Message: Undefined index: queue]php-fpm[18230]: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 4371, Message: Undefined index: queue

          then

          http://php-fpm[47509]: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 3105, Message: Undefined index: burst]php-fpm[47509]: /exec.php: PHP ERROR: Type: 8, File: /etc/inc/shaper.inc, Line: 3105, Message: Undefined index: burst

          After putting appropriate "isset() &&" code before is_array() in those places, I got the code so the last error is that "Assigning the return value of new by reference is deprecated" one, and it then appears in syslog.

          So that error thing is a bit hit-and-miss, because the system is also remembering E_NOTICE stuff along the way, but then not reporting E_NOTICE. That can cause nothing to be reported, even though there was some other reportable-level message earlier in the code.

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            But with E-NOTICE being reported, there are 100s of things - all about unassigned variables… which is just lots of code that does not initialize vars, it lets the PHP default happen, that if a var is not set then that is treated as "empty","false"...
            It would be a huge job to explicitly init every var before it is referenced - the code was just never written in that style.
            It seems to be possible to also use set_error_handler() to have an error handler that can check the error level and log a message if the error is a level we care about, and then return and allow the code to continue (for non-fatal errors). That would get all the interesting error messages reported on-the-fly, rather than just the last one.
            Is it worth looking into that?

            The other way, which I used to quickly gather all the "not E_NOTICE" messages on my test system, was to add to /etc/rc.php_ini_setup:

            error_reporting = E_ALL & ~E_NOTICE

            Then these sort of error/warning/deprecated things come as "crash reports" to the dashboard. It is then easy to see the messages and go and fix the offending files.
            Is it worth having that on in the RC so that everyone will quickly find and report these things as they exercise all the various menu options?

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              That seemed like a good idea at the time, but now I'm wondering. Yeah it's spewing stuff that's not necessarily helpful, sure it should be fixed, but might end up going back and silencing that.

              Thanks for the pull request to fix at least some of that, I merged it.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post