Prevent fatal error in Raven_Stacktrace

[roelsadza]

When a PHP extension has an error, raven tries to load a non-existent file (in our case newrelic/guzzle6), causing SplFileObject to throw a fatal error.
Do not attempt to load the file if it does not exist.

[Jean85]

Thanks for the contribution!
Can you also provide a test that reproduces this case? So we are sure to not regress on this bug!

[stayallive]

Could you tell me on what php version this occurs?

I tested it on my local 5.5 & 7.1 install but get the following:

Psy Shell v0.8.13 (PHP 5.5.38 — cli) by Justin Hileman
>>> $file = new SplFileObject('somerandonfilename.php');
RuntimeException with message 'SplFileObject::__construct(somerandonfilename.php): failed to open stream: No such file or directory'

A RuntimeException is thrown which is caught by the try/catch block around it.

[roelsadza]

@stayallive Thanks for checking it out. We had the issue on PHP 7.0. The filename it tried to open was "newrelic/Guzzle6".

[stayallive]

@rsadza would you happen to have the exact error log entry? I can see how an uncaught runtime exception would turn into a failed error, but that should not happen since we catch it.

Sentry does have a way to make it look like the error came from the Sentry SDK, so would be very interested in the log message so I can investigate a bit deeper.

[samdark]

E_WARNING: SplFileObject::__construct(unknown): failed to open stream: No such file or directory
in SplFileObject::__construct called at /vendor/sentry/sentry/lib/Raven/Stacktrace.php (280)
in Raven_Stacktrace::read_source_file called at /vendor/sentry/sentry/lib/Raven/Stacktrace.php (66)
in Raven_Stacktrace::get_stack_info called at /vendor/sentry/sentry/lib/Raven/Client.php (878)
in Raven_Client::capture called at /vendor/sentry/sentry/lib/Raven/Client.php (564)
in Raven_Client::captureMessage called at x

[samdark]

@stayallive do you need any help with merging this pull request? I'm getting the issue constantly in my newrelic logs.

[Jean85]

@samdark it appears that the issue is due to the fact that SplFileObject::__construct() it raising an E_WARNING. But this doesn't seem to be the default behavior.

Do you have anything in place that alters this?

[stayallive]

@Jean85 I have a test for this now. Let;s see what Travis says and we can merge it.

@samdark Sorry for taking so long. Test is in, after Travis gives it's blessing this will be merged.

[Jean85]

...but SplFileObject::__construct() uses fopen(): https://github.com/php/php-src/blob/e68084780f29a6ed99dc2368a6df8f43b58d4377/ext/spl/internal/splfileobject.inc#L44

Which in turn raises the E_WARNING: http://php.net/manual/en/function.fopen.php#refsect1-function.fopen-errors

If the open fails, an error of level E_WARNING is generated. You may use @ to suppress this warning.

This is the source of the issue.

[Jean85]

Travis build is green! Thanks @stayallive for adding a regression test case!

[samdark]

Do you plan tagging release anytime soon?

[stayallive]

Yes, today if possible 👍

[stayallive]

FYI: 1.8.2 has been released with this PR in it. Thanks!