PHP Errors – Enables sensor for alerts generated from PHP.

The dump seems to contain every single WordPress function, Server variables, system variables, all plugin and theme data and variables. You get the picture – massive dump of info, which ends up being around 20MB of data. ?? Still looking for the source of the issue.

[07-Jul-2014 02:15:43 UTC] WordPress database error MySQL server has gone away for query REPLACE INTOodkh36_wsal_metadata(id,occurrence_id,name,value`) VALUES (0,107,'Trace','\"#0  WSAL_Sensors_PhpErrors->EventError(8, Undefined index: settings-updated,
 C:\\\\xampp\\\\htdocs12\\\\demo5\\\\wp-content\\\\plugins\\\\bulletproof-security\\\\admin\\\\php\\\\php-options.php, 1267, Array ([_GET] => Array ([page] => bulletproof-security\\/admin\\/php\\/php-options.php),[_POST] => Array (),[_COOKIE] => Array ([wordpress_0b1c224cdaf32e4c3569fe4e42563ee1] => ED5000|1404869207|f1480fd1f4d69a419dacb3b122da3dac,[wp-settings-1] => editor=tinymce&hidetb=1,[wp-settings-time-1] => 1403978898,[wordpress_test_cookie] => WP Cookie check,[wordpress_logged_in_0b1c224cdaf32e4c3569fe4e42563ee1] => ED5000|1404869207|de1356f7cc4b28bf97a5444793f8bc14),[_FILES] => Array (),[_SERVER] => Array ([SERVER_SOFTWARE] => Apache\\/2.4.9 (Win32) OpenSSL\\/1.0.1g PHP\\/5.5.11,[REQUEST_URI] => \\/wp-admin\\/admin.php?page=bulletproof-security\\/admin\\/php\\/php-options.php,[MIBDIRS] => C:\\/xampp\\/php\\/extras\\/mibs,[MYSQL_HOME] => \\\\\\\\xampp\\\\\\\\mysql\\\\\\\\bin,[OPENSSL_CONF] => C:\\/xampp\\/apache\\/bin\\/openssl.cnf,[PHP_PEAR_SYSCONF_DIR] => \\\\\\\\xampp\\\\\\\\php,[PHPRC] => \\\\\\\\xampp\\\\\\\\php,[TMP]
`

Ok isolated it to this file/code below.

commenting out debug_print_backtrace() keeps the problem from happening. If I have some spare time I will dig deeper.

File: /classes/Sensors/PhpErrors.php
Line: 27

public function EventError($errno, $errstr, $errfile = 'unknown', $errline = 0, $errcontext = array()){
		if($this->_avoid_error_recursion)return;

		ob_start();
		//debug_print_backtrace();
		$errbacktrace = ob_get_clean();

		$data = array(
			'Code'    => $errno,
			'Message' => $errstr,
			'File'    => $errfile,
			'Line'    => $errline,
			'Context' => $errcontext,
			'Trace'   => $errbacktrace,
		);

Hi,

Thank you for reporting this. We are looking into the issue today. Should we need any further information we will get back to you. If not we should release a fix later on this week.

Just starting to dig deeper on this, but wanted to give you some more general info on the what, when and where of the issue.

It is not isolated to just my plugin or the php error log in BPS Pro. Using the Apache Server’s default php error log and accessing another plugin’s settings page that has a minor php error occurring causes the identical massive dump of data issue.

So the condition is – if a php error is detected/occurs in any plugin then the debug_print_backtrace() function is dumping everything it can find. Probably some kind of loop restriction would need to be added or something similar to the concept of “only return X instead of X, Y and Z”.

Also what is then causing a plugins page to not load is the server runs out of memory during the dump.

This option seems to do the trick, but unfortunately it was introduced in 5.3.6 so you would need some sort of fallback / alternative for older versions of PHP.

debug_print_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS);

https://www.php.net/manual/en/function.debug-print-backtrace.php

or maybe get off easy by doing a PHP version check. ?? if php version < 5.3.6 don’t do anything. if php version >= 5.3.6 do something.

Hi,

Thank you for posting the ticket.

We are including a new option in the next plugin update to make capturing of strack trace optional, thus avoiding such situations. Having said that, as a developer you should / would be typically aware that when enabling such developer options, all data will be logged, including the 20MB of data your plugin generated.

While I trust the above addresses your issue, do not hesitate to get in touch should you have any further queries.

It is already an optional thing so not sure what you mean by that. Anyway my Dedicated Server is not capable of handling 20MB of data dumped all at one time so no way a Shared server would be able to handle that dump size. At least not in that format. ?? Possibly outputted as HTML might work, but not a 20MB string ha ha ha.

Either way I was just pointing something out. Not really a problem or a ticket and just a heads up. It is documented in our KB now so if someone has these symptoms we know what to ask and how to “fix” it. ??

Just a friendly heads up and not an issue or problem – resolved.
FYI – yep the 20MB dump in HTML format worked great – server had no problems handling that. ??

…and the file contents was viewable in a few milliseconds as opposed to hanging Notepad++ while trying to view a 20MB string. ??

Thanks for the detailed feedback. We are looking into different ways of improving the handling of such files, so stay tuned with us ??