bugsnag/bugsnag-php

BugSnag error monitoring and crash reporting tool for PHP apps

Bugsnag error monitoring & exception reporter for PHP

The Bugsnag error reporter for PHP gives you instant notification of errors and exceptions in your PHP applications. Learn more about automatic PHP error reporting with Bugsnag.

Includes error monitoring and error reporting support for Laravel, Lumen, Symfony, Silex, Magento, Zend Framework, Code Igniter, Wordpress, and other PHP apps.

Features

• Automatically report unhandled exceptions and crashes
• Report handled exceptions
• Attach user information to determine how many people are affected by a crash
• Send customized diagnostic data

Getting started

1. Create a Bugsnag account
2. Complete the instructions in the integration guide for your framework:
   • Laravel
   • Lumen
   • Symfony
   • Silex
   • Magento
   • Wordpress
   • Other PHP apps
3. Relax!

Support

• Read the configuration reference:
  • Laravel
  • Lumen
  • Other PHP apps
• Search open and closed issues for similar problems
• Report a bug or request a feature

Contributing

All contributors are welcome! For information on how to build, test and release, see our contributing guide. Feel free to comment on existing issues for clarification or starting points.

License

The Bugsnag PHP library is free software released under the MIT License. See LICENSE.txt for details.

bugsnag-php's Issues

Users cant set their own userid in metadata

This -> https://github.com/bugsnag/bugsnag-php/blob/master/src/Bugsnag/Error.php#L157 -> can overwrite user id passed through with metadata.

Add support for Silex framework

Add support for headers when using nginx

https://github.com/bugsnag/bugsnag-php/blob/master/src/Bugsnag/Request.php#L34

The function getallheaders is not available when using php-fpm.
https://bugs.php.net/bug.php?id=62596

Maybe the client could define it's own function?
http://php.net/manual/en/function.getallheaders.php#84262

Error.php timeout

In one script of our backend system we got the following error:

Fatal error: Maximum execution time of 120 seconds exceeded in /srv/www/htdocs/inside/xxx/lib/bugsnag/Error.php on line 119

We use the recent PHP Version 2.1.4

Before we hat v. 1.x and there was no Problem.

BR sven

Namespace and PSR-4 tests

Add integration and unicode-safety tests to library

Support For Google App Engine

BugSnag PHP uses curl to post the exceptions but unfortuanely that's not supported on Google App Engine.

Can you consider either switching to using file_get_contents()/fopen() (which would work on all environments) or switching to use urlfetch (https://developers.google.com/appengine/docs/php/urlfetch/overview) on app engine (either by detecting the runtime environment or a config setting)?

Custom error callback function

Hey James,

Really enjoying Bugsnag so far — thanks for your work on it!

With my previous, home-brewed error handling, after logging and notifying myself about the error, I would redirect the user to page saying that an error occurred. Bugsnag obviously takes care of the first part now, but I'm having trouble figuring out how/where to do the redirection.

This is what I came up with: allow a callback function to be registered that's executed when an error is reported...

private static $userErrorFunction;

public static function setUserErrorFunction($userErrorFunction) {
    self::$userErrorFunction = $userErrorFunction;
}

private static function callUserErrorFunction() {
    $isCallable = isset(self::$userErrorFunction) && is_callable(self::$userErrorFunction);

    if($isCallable) {
        call_user_func(self::$userErrorFunction);
    }

    return $isCallable;
}

I had some trouble deciding where to call self::callUserErrorFunction();, but ultimately decided in flushErrorQueue. I don't think it's the best place, but it seems to be where most code paths lead.

So, to my questions: Does this make sense? Am I missing an existing way to handle this? Is this something you see being a part of this package?

Thanks for your help!

Support Throwable

It would be good if notifyException would support Throwable.

Check if host has curl enabled during deployment

Bugsnag can fail during a deployment because even if curl is installed, a host can have it it disabled. I'm not sure the function_exists check is the best option for determining how to submit a notification.

Should cleanup_obj entire payload

At the moment we only run cleanup_obj on the metaData, we should run it against the entire payload.

BugSnag lib is a performance bottleneck

The Client can be very detrimental to performance because it tries to report the error within the same request cycle. This means that if I have an innocuous error, visitors to my site will suffer from delayed page load times -- until the error is reported to BugSnag via curl.

In the best case scenario, this delay is equivalent to the time required to aggregate and report the errors to the BugSnag service. In the worse cases, the BugSnag service can have high latency but still be fast, or have low latency but be slow to respond, or be down altogether in which case the page won't render to the visitors until the BugSnag curl request times out.

Another direct implication is that offline testing is totally messed up because every request must time out before continuing.

I am unable to justify putting this in my production code at the moment. Would have been nice if BugSnag provided support for syslog so this could be done out of band.

Maybe you could check for pcntl_fork support and leverage that for curl_exec?

Dont let top line be [internal]

We sometimes use the top stack line for grouping so it should never be [internal]

PHPDoc All The Functions

Let users configure hostname

Sometimes hostnames are incorrectly determined so it would be good to expose the hostname variable

PHP7 support

The first error I saw after upgrading:

Uncaught TypeError: Argument 3 passed to Bugsnag_Error::fromPHPException() must be an instance of Exception, instance of Error given, called in Bugsnag/Client.php on line 417 and defined in Bugsnag/Error.php:32

Stack trace: #0 Bugsnag/Client.php(417): Bugsnag_Error::fromPHPException(Object(Bugsnag_Configuration), Object(Bugsnag_Diagnostics), Object(Error))
#1 Bugsnag_Client->exceptionHandler(Object(Error))
#2 [internal function]: HandleException(Object(Error))
#3 {main} thrown

Which is an issue caused by this: https://secure.php.net/manual/en/function.set-exception-handler.php#refsect1-function.set-exception-handler-parameters

Make retrieval of server variables pluggable

We're currently using bugsnag on a google app engine application using Laravel.

Unfortunately, the following line is causing us some issues: https://github.com/bugsnag/bugsnag-php/blob/master/src/Bugsnag/Request.php#L62

Now, given that this isn't bugsnag-laravel, I understand that we can't leverage any of the configuration or request/response libraries. Although it would be ideal if the mechanism used to obtain values like these was pluggable. Then, bugsnag-laravel could ship an implementation that retrieves the variables from its own abstraction. Then, bugsnag-php can ship defaults that use the superglobals.

Fatal error in 1.1

The pass-by-reference &$customMetaData doesn't work in PHP 5.4

    if(isset(self::$beforeNotifyFunction) && is_callable(self::$beforeNotifyFunction)) {
        call_user_func(self::$beforeNotifyFunction, &$customMetaData);
    }

Gives a fatal error.

Namespace and PSR-4 src

Get Error ID in Notifier Response

Hi guys,

I was wondering if there's a way to get a unique ID back from the notifier? Presumably the notification is placed in a queue, rather than immediately recorded somewhere, so I appreciate that this may not be immediately possible. It would be useful for us though to generate an error ID and return in an API response for tracking.

Thanks

Refactor our warnings to throw exceptions

This avoids writing garbage to stderror on some systems.

Autoload first load configuration?

I am getting an error when including the autoload.php file, that Client.php needs the Configuration class, this class is loaded after Client.php...

setSendCode significantly slows execution time

Hey guys,

When I recently updated from v2.3.0 to v2.5.0, I found that PHP execution time of my app became significantly slower. It averaged 150ms with v2.3.0, but saw nothing faster than 350ms with v2.5.0.

I think the culprit is setSendCode. When I set that to false, execution time returns to ~150ms. Is that expected? It's easy enough to set it to false, but my feeling is something's off.

This is with PHP v5.3.11.

Thanks!

Lines referencing $_SERVER vars sometimes raise notices

The entries in the $_SERVER array are not always guaranteed to be present. Since undefined indexes raise a notice in PHP, there's a few lines of the bugsnag code that are causing errors.

• line 440, getRequestData() - When the request is a GET request, a Content-Type header is not included.
• line 446, getRequestData() - Misbehaving agents might not specifying a User-Agent header.

There may be more, but these are the ones I have encountered thus far. Simple isset() checks should be sufficient in most situations.

JSON data doesn't populate request if php://input has already been read

In PHP prior to 5.6, you can only read php://input one time. Thus if your code has read it before an exception is thrown, the request parameters will not be filled in.

I'm unsure of good options. In my particular use case (Yii2 framework), I can manually edit Bugsnag_Request:;getRequestMetaData to get the raw post body from Yii::$app->request->getRawBody() since that caches it, but that isn't a general solution.

Unexpected Character

We've some warnings on our productive server:

Warning: Unexpected character in input: '' (ASCII=92) state=1 in /srv/www/htdocs/xx/lib/bugsnag/bugsnag.php on line 27

dev_refactor has been abandoned, then deleted

I was using that!

The refactor was a needed change to your aging code base and I liked your service.

So what happened?
Tom

Option to prevent bugsnag registering shutdown function

Hi again,

I have some custom code that should be run a fatal error is encountered, part of which is to call bugsnag.

However because bugsnag registers its own shutdown function my native code is never called.

I got round this by manually setting private static $registeredShutdown to true rather than false which achieved the required result but having just had to setup my project on another machine i've realised it would be much better if there was a way to set this as when bugsnag is configured, something like:

Bugsnag::register($api_key);
...
Bugsnag::catchFatalErrors(false);

But with a better name.

I might have been completely blind and missed that this already possible but in case i'm not I (and hopefully someone else) would find this helpful.

Thanks, Felix.

ProjectRootRegex should be stripped by default

When using projectrootregex we should strip the matching regex from the filename by default.

Remove version_compare stuff

Add direct support for monolog log handling

Symfony has dependency injection for common logging services:
https://github.com/symfony/MonologBundle/blob/master/DependencyInjection/Configuration.php

Refactor to use guzzle

Ensure certain "fatal errors" are reported correct only older php versions

It looks like older PHP versions (PHP 5.3) give different error codes to certain error types.

Running

<?php

register_shutdown_function('shutdown');

$what->nothing();

function shutdown() {
    print_r(error_get_last());
}

Returns the following on PHP 5.3:

Array
(
    [type] => 8
    [message] => Call to a member function nothing() on null
    [file] => /home/vagrant/test_error.php
    [line] => 5
)

But a different error code (type) on later PHP versions:

Array
(
    [type] => 1
    [message] => Call to a member function nothing() on null
    [file] => /home/vagrant/test_error.php
    [line] => 5
)

We should investigate the impact of this discrepancy on fatal error reporting

[Feature] setMetaData

Hello,

As we can see in the error class when we use setMetaData() the existing meta data gets merged with the one passed as an argument.

Is it possible to implement this feature for the client class here?

The reason that is useful is because sometimes we want to pass different meta data in different places of the app. For example a user_id at the authentication service and some other value at some other place of the code. Calling setMetaData() twice will keep only the latest information.

Thanks for this nice package!

Add "nested" exception support

Exceptions in PHP can be "nested" like:

$exc = new Exception('Something went wrong', 0, new Exception('Nested exception'));
$nested = $exc;
while (($nested = $nested->getPrevious()) instanceof Exception) {
    echo $nested->getMessage();
}

The bugsnag JSON Payload allows to report more than one exception. This is very useful to stack and pass exception information.

Allow `setProjectRoot` to accept an array of project paths

It is common to have code running from multiple locations on your server. Eg:

1. /var/www/
2. /apps/myapp

Both of these paths could be considered inProject but it is currently difficult for people to set multiple project root paths.

I propose we enhance setProjectRoot to accept a PHP array of paths, and to increase the prominence of this setting in the readme.

Bonus points if we can somehow automatically set project roots in a smarter way.

Large request post data causes Bugsnag_Client::notify() to fail

Background:

• My Application imports emails sent to it by Mandrill.
• The emails contain a large encoded excel spreadsheet.
• Stupidly, I wasn't using any sort of queuing system, so Mandrill hit my URL webhook end point, and then the application synchronously tried to import from the spreadsheet, which can take a long time.

Every time that the email was attempted to be imported, the max_execution_time was being hit, causing an PHP Fatal error: Maximum execution time of 60 seconds exceeded error. This has been happening for a couple of weeks, and none of these errors have appeared on my Bugsnag account.

After some debugging, I've worked out that the POST data in the original request by Mandrill is larger than the Bugsnag POST data limit, so when Bugsnag tries to notify about the Maximum execution time of 60 seconds exceeded error I get a 400 (bad request) response, and therefore the error is never logged. The docs state that a 400 bad request indicates that the payload was too large.

You can see here that the Bugsnag library never considers the size of the $_POST variable before adding it to the $requestData.

Do you think it would be sensible to check the size of the post data just before sending the curl request. Then, if the size is larger than the Bugsnag post data limit (which isn't mentioned in the docs so I'm not sure what that is), the POST data (or params to use the term actually used in $requestData) would be truncated sufficiently so that the POST data falls below the Bugsnag limit. Alternatively, the POST data could be excluded all together. Ultimately, given that Bugsnag have set a POST data limit, to me it makes sense to make sure that the Bugsnag library never tries to send a request with POST data larger than that limit.

As I was relying on Bugsnag to notify me of any errors, I was not made aware the imports were failing until a couple of weeks later when the customer alerted me.

(For the record, I'm in the process of implementing a queuing system to handle this, so the original request from Mandrill with the massive post data should very quickly be handled and a job added to the queue. That said, if some other unrelated error occurs during this request, once again that error would never reach Bugsnag).

Pass parameter to setMetaDataFunction

Hi,

I have some meta-data I want to include with bugsnag notifications but I can't figure out how to pass an object to the function nominated bysetMetaDataFunction.

I use the slim framework and store the meta-data I want to send inside an $app object so like this:

function bugsnag_metadata($app) {
    return $app->meta;
}

I tried to pass the $app parameter using the same format as: register_shutdown_function() where I can do this:

register_shutdown_function("fatal_handler", $app);

But setting this:

Bugsnag::setMetaDataFunction("bugsnag_metadata", $app);

Gives the error:

Uncaught exception 'ErrorException' with message 'Missing argument 1 for bugsnag_metadata()'

So that isn't working.

Is there a way to pass the variable or, more ideal, would be being able to say

Bugsnag::setMetaData($app->meta); //in my case the meta array is contained in $app

in a similar way to Bugsnag::setUserId('XXX');

Ability to set timeouts in ms

We should take a look at the timeout configuration to allow ms precision timeouts

New cleanup method fails with a boolean value

Revision [49e5d60] added the new cleanup method but this one fails when dealing with boolean values.

This method basically uses is_array() + is_numeric() + is_string() checks, if no one of these succeed a json_decode(json_encode()) trick is triggered, which fails with a boolean value, causing an infinite loop.

Don't send too many error reports

If you have a PHP-level warn/info error it doesn't stop execution, so you can see hundreds of them per request. We should (client-side) unique the errors, sort the list by severity and take the top 10, or something like that.

Type Hint errors are suppressed

Hey guys,

It seems that Type hint errors are being suppressed. Example:

class a
{
    public function test(a $class)
    {
        echo 'I should never make it here.';
    }
}

$test = new a();
$test->test(new \StdClass()); //This should throw an error

Expected: PHP Error
Result: 'I should never make it here.'

This is happening on the master branch.

Sanitize invalid utf-8

Error in exception handler: json_encode(): Invalid UTF-8 sequence in argument in bugsnag/bugsnag/src/Bugsnag/Notification.php:95

src/Bugsnag/Request.php:35: Error in exception handler: array_merge():

This breaks if $requestData['request']['params']is not an array.

if(isset($requestData['request']['params'])) {
    $requestData['request']['params'] = array_merge($requestData['request']['params'],$params);
}

May I suggest:

if (isset($requestData['request']['params']) && is_array(isset($requestData['request']['params']))) {
    $requestData['request']['params'] = array_merge($requestData['request']['params'],$params);
}

Replace subclass checking with instanceof

PHP Fatal error: Class 'Bugsnag_Error' not found

Ran into a very strange error with v2.0.1 on PHP v5.3.14:

PHP Fatal error:  Class 'Bugsnag_Error' not found

Here's my Bugsnag code:

$Bugsnag = new Bugsnag_Client('REMOVED');
set_error_handler(array($Bugsnag, 'errorHandler'));
set_exception_handler(array($Bugsnag, 'exceptionHandler'));
$Bugsnag->setReleaseStage('development');
$Bugsnag->setErrorReportingLevel(E_ERROR | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR);
$Bugsnag->setBeforeNotifyFunction(function ($error) {
  // ...
});

Autoload.php is being required first, and I've verified with some debug code that the autoloader is being registered. Here's my error log with debug output:

[14-Oct-2013 17:31:32 UTC] loaded
[14-Oct-2013 17:31:32 UTC] /my/path/vendor/bugsnag/Client.php
[14-Oct-2013 17:31:32 UTC] /my/path/vendor/bugsnag/Configuration.php
[14-Oct-2013 17:31:32 UTC] PHP Fatal error:  Class 'Bugsnag_Error' not found in /my/path/file.php on line 190
[14-Oct-2013 17:31:32 UTC] /my/path/vendor/bugsnag/Error.php
[14-Oct-2013 17:31:32 UTC] /my/path/vendor/bugsnag/Stacktrace.php
[14-Oct-2013 17:31:32 UTC] /my/path/vendor/bugsnag/Request.php
[14-Oct-2013 17:31:32 UTC] /my/path/vendor/bugsnag/Notification.php

loaded is when the autoloader is registered, and each subsequent file path is when the require_once is called in Autoload.php.

So, it looks like Bugsnag_Client and Bugsnag_Configuration are being loaded successfully before it errors out on Bugsnag_Error. Oddly enough, Bugsnag_Error is then successfully loaded and the above error is actually sent to Bugsnag.

Any idea what's going on? Thanks!

Limit the number of errors buffered

Some installations of php have fairly low memory limits (128mb) and also a lot of errors. We should limit the number of errors we buffer before sending to bugsnag to ensure that we dont add extra memory pressure to applications.

Magento Notifier

There have been requests for a Magento notifier. Thoughts about creating one?

Reporting of a JSON object request crashes

I have a couple requests where a JSON object is PUTed ({"general":{}} for the simplest possible example).
When that fails and ends up with BugSnag, it passes through the Request::getRequestMetaData() and it gets decoded into an \stdClass instance.

A couple lines farther an attempt is made to array_merge() this \stdClass with the parse_str() version of that same JSON and that causes an exception to be thrown ("Argument #1 is not an array).

Perhaps adding the decode as an array option could help out here?

Remove deprecated code