MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001059XdebugFeature/Change requestpublic2014-07-03 10:062017-04-26 00:56
ReporterRQuadling 
Assigned Toderick 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version 
Target Version2.6.0devFixed in Version 
Summary0001059: Add filter capabilities to tracing, stack traces, and code coverage.
DescriptionHi.

The call trace feature of xDebug is brilliant. But sometimes it can be very very long, especially when used with a third party framework.

It would be really nice to be able either/both include/exclude namespaces from the trace, so for an application based upon Laravel, xDebug could be setup to not trace into the Illuminate namespace, this reducing the trace log to just my code.

Things could get messy where the first call is to the Illuminate code and then at some point the framework calls my code which is where the tracing is required.

Not really got much of a clue as to what else could be done around this, but I would certainly find it very useful to have such a feature.
TagsNo tags attached.
Operating System
PHP Version5.5.5-5.5.9
Attached Files

- Relationships
has duplicate 0000365resolvedderick Feature patch, allow code coverage to avoid "covering" certain files by path. 
has duplicate 0000504resolvedderick i'd like to be able to list a whitelist / blacklist of functions & classes for a trace / profiling 

-  Notes
(0004048)
derick (administrator)
2016-12-13 21:30

I would like to do this, but not just for tracing. I am intending to add filtering based on *either* a list of directory prefixes, or a list of namespaces.

With this filter enabled, this would act for tracing, stacktraces, code coverage, and perhaps also profiling (the latter is trickier, as it currently collates times from different functions into one blob).
(0004073)
RQuadling (reporter)
2016-12-14 23:14

That's great. I'm not really able to contribute to the code, but can offer testing support if you need it.
(0004187)
jboffel (reporter)
2017-01-20 03:50

Can't wait for this one! It would drastically speed up my current functional testing with coverage report.

By the way, to make gathering of coverage easier in functional testing context (like JaCoCo) it would help if there were an option to activate code coverage for any request without the need to call to xdebug_start_coverage(). I did a patch to PHP to call those function for me automatically and save the report in a compatible format with PHPUnit tool to merge report but it is very dirty and the lack of blacklist/whitelist in xdebug make the all process slow...
(0004240)
sebastian (reporter)
2017-03-22 15:02

Progress on leveraging this for php-code-coverage (and PHPUnit) is tracked at https://github.com/sebastianbergmann/php-code-coverage/issues/514 [^]
(0004324)
derick (administrator)
2017-04-25 12:02

I recently made a commit to implement filters in a basic way. This
is by no means complete (or even working properly), but it gives a hint
of how this API could work.

The branch is: https://github.com/derickr/xdebug/tree/issue1059-filter [^]
The commit is: https://github.com/derickr/xdebug/commit/db9e1a8d841a8837400d733a60db63f4d0f26b5f [^]

Currently, the API for this is a single function:

proto void xdebug_set_filter(int group, int type, array filters)

The group is either one of XDEBUG_FILTER_TRACING, XDEBUG_FILTER_PROFILER, or
XDEBUG_FILTER_CODE_COVERAGE. You need to call xdebug_set_filter for each of
the three groups if you want to set up a filter for all of them.

The type is one of XDEBUG_PATH_WHITELIST, XDEBUG_PATH_BLACKLIST,
XDEBUG_NAMESPACE_WHITELIST, or XDEBUG_NAMESPACE_BLACKLIST.
The *PATH* variants operate prefix filters on the filepath of the
function/method's location and the *NAMESPACE* variants operate as a prefix
filter on the *classname* only, to white list non-object functions, you can use
the (empty) string ''.

Right now, if the filter finds a specific frame as "filtered out", it does
not filter out calls made from this function - they would show up as normal.
Is it worth changing that?
(0004325)
RQuadling (reporter)
2017-04-25 15:47

I would say yes to filtering cascades to child calls.

But each call would need to check the appropriate list.

So, if we reach a call that would be filtered out by the blacklist, it is filtered out.

Any calls that are subsequently made would be checked against the whitelist and if appropriate, filtered in.

And then you would look at the blacklist to filter out any further child calls.

etc.
(0004326)
derick (administrator)
2017-04-25 15:57

Right now, you can't set both a black list or a white list. It's going to one of each. Remember that it costs time to check against these lists as well. I have to choose upon function call whether this function matches the blacklist or whitelist and act accordingly. And I'm inclined to make the filters cascading.
(0004327)
RQuadling (reporter)
2017-04-26 00:56

I can't make out the exact meaning of "you can't set both a black list or a white list. It's going to one of each.". Does this mean you can only set a blacklist OR a whitelist?

The main issue I would have with the filters cascading is that, for example, using a framework like Laravel, the code I've written is called upon by Laravel, not the other way around. Laravel sets up the routes, gathers all the data before calling my controllers. The controllers interact with Laravel's Eloquent ORM which in turn calls upon my models, observers, views and presenters. All VERY interleaved. If I excluded ./vendor, pretty much the second line of executed code would be within either composer's autoload or Laravel's framework.

As for checking against the list on each call, can you not add a semaphore to the file upon loading, indicating that the contents is filtered in or out? That way, the list has already been processed and it is a (hopefully) simple semaphore check to report the call? (I am not an expert here, so I may be WILDLY out).

Maybe it would be a good idea if you could demonstrate tracing of a Laravel based application but without reporting any of the Laravel calls.

- Issue History
Date Modified Username Field Change
2014-07-03 10:06 RQuadling New Issue
2016-12-13 21:30 derick Note Added: 0004048
2016-12-13 21:30 derick Assigned To => derick
2016-12-13 21:30 derick Status new => confirmed
2016-12-13 21:30 derick Target Version => 2.6.0dev
2016-12-13 21:30 derick Summary Allow tracing with inclusion/exclusion of namespaces. => Add filter capabilities to tracing, stack traces, and code coverage.
2016-12-13 21:34 derick Relationship added has duplicate 0000365
2016-12-13 21:35 derick Relationship added has duplicate 0000504
2016-12-14 23:14 RQuadling Note Added: 0004073
2017-01-20 03:50 jboffel Note Added: 0004187
2017-03-22 15:02 sebastian Note Added: 0004240
2017-04-25 12:02 derick Note Added: 0004324
2017-04-25 15:47 RQuadling Note Added: 0004325
2017-04-25 15:57 derick Note Added: 0004326
2017-04-26 00:56 RQuadling Note Added: 0004327


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker