php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #76274 FatalExceptions don't include variables and stack traces under some conditions
Submitted: 2018-04-26 22:57 UTC Modified: 2018-05-02 22:31 UTC
From: archon810 at gmail dot com Assigned:
Status: Suspended Package: Scripting Engine problem
PHP Version: 7.2.5 OS: Linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: archon810 at gmail dot com
New email:
PHP Version: OS:

 

 [2018-04-26 22:57 UTC] archon810 at gmail dot com 
Description:
------------
Hi,

This is a follow-up directly with the PHP team regarding https://github.com/getsentry/sentry-php/issues/582, a Sentry issue about capturing variables and stack traces for PHP.

The problem is, after certain fatal exceptions, like out of memory or maximum execution time exceeded, Sentry is unable to capture stack traces and variables.

The conclusion in the thread is that error_get_last (http://php.net/manual/en/function.error-get-last.php) does not provide them to Sentry in such cases, so I'm here to facilitate a discussion around the subject and find a possible fix because it's extremely valuable to be able to see the variables and stack traces for such fatal failures.

If the problem is that PHP's limitation, such as bumping into the memory max, prevents this extra info from being passed, perhaps we can introduce a configurable buffer which can help house this data?

Please discuss.

Thank you.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-04-26 23:02 UTC] hanskrentel at yahoo dot de 
you can do in PHP userland, at the beginning of your app (and before the error handler is triggered), reserve some memory (e.g. by assigning a larger string to a global variable), then when the error is triggered and w/ the problems you talk about, free that buffer.
 [2018-04-26 23:13 UTC] archon810 at gmail dot com 
I'm going to defer to the Sentry dev I've been conversing with, but it is my understanding that it's PHP that doesn't provide those variables in the event of, say, an OOM fatal exception, thus even if you freed up some memory, the data wouldn't be there to grab.

In other words, it's PHP that isn't giving us the data rather than Sentry.
 [2018-04-27 01:47 UTC] requinix@php.net
-Status: Open +Status: Suspended -Package: *General Issues +Package: Scripting Engine problem
 [2018-04-27 01:47 UTC] requinix@php.net 
This is but a lowly bug tracker. Try the internals mailing list.
https://secure.php.net/mailing-lists.php
 [2018-04-28 00:06 UTC] archon810 at gmail dot com
-Summary: FatalExceptions don't include variables and stack traces under some conditions +Summary: archon810@gmail.com
 [2018-04-28 00:06 UTC] archon810 at gmail dot com 
@requinix It's not clear to me whether this is a bug/feature report or there's a solution Sentry isn't seeing, hence filing here. We're looking for feedback from the core devs and a possible enhancement in core PHP.
 [2018-04-28 00:21 UTC] requinix@php.net
-Summary: archon810@gmail.com +Summary: FatalExceptions don't include variables and stack traces under some conditions
 [2018-04-28 00:21 UTC] requinix@php.net 
I understand that, but this bug tracker is not the best place to interact with the "core devs" and it is not suitable for discussions or conversations that go beyond simple Q&A. That's what the mailing list is for.

This report isn't closed. Suspended means just that: suspended, and pending discussion about what to do with it.
 [2018-05-02 22:31 UTC] archon810 at gmail dot com 
The PHP mailing list's archaic software is quite frustrating to use. I tried subscribing to the PHP Internals list http://php.net/mailing-lists.php several times, but no emails arrive to complete the subscription, so I can't send a message out.

Why can't we just have a normal forum these days instead of these prehistoric mailing lists that don't have the ability to post a message without subscribing to everything first? ezmlm is as user-friendly to interface with now as it was 20 years ago.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 26 15:01:56 2024 UTC