View Issue Details

IDProjectCategoryView StatusLast Update
0001059XdebugFeature/Change requestpublic2017-12-28 19:16
ReporterRQuadlingAssigned Toderick 
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Product Version 
Target Version2.6.0Fixed in Version2.6.0beta1 
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

Relationships

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

Activities

derick

2016-12-13 21:30

administrator   ~0004048

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).

RQuadling

2016-12-14 23:14

reporter   ~0004073

That's great. I'm not really able to contribute to the code, but can offer testing support if you need it.

jboffel

2017-01-20 03:50

reporter   ~0004187

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...

sebastian

2017-03-22 15:02

reporter   ~0004240

Progress on leveraging this for php-code-coverage (and PHPUnit) is tracked at https://github.com/sebastianbergmann/php-code-coverage/issues/514

derick

2017-04-25 12:02

administrator   ~0004324

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?

RQuadling

2017-04-25 15:47

reporter   ~0004325

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.

derick

2017-04-25 15:57

administrator   ~0004326

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.

RQuadling

2017-04-26 00:56

reporter   ~0004327

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.

stof

2017-04-26 07:14

developer   ~0004328

Making the filter cascading looks weird to me.

The common use case for code coverage filtering is to filter out the vendor folder, keeping only your own code.
And we can have out own code being called from code living in vendors (the framework for instance).

sebastian

2017-04-26 11:53

reporter   ~0004329

I won't be able to actually experiment with the current state of the implementation until next week, but on first glance the API looks okay to me.

PHPUnit used to support both whitelisting and blacklisting for code coverage filtering. By default it used to use a blacklist and when a whitelist was configured it would use the whitelist but not the blacklist. This blacklist XOR whitelist usage makes sense to me. If it were up to me, though, I would not bother adding blacklist support to Xdebug. What I need from PHPUnit's perspective, whitelisting, is there and I will use that.

I am not sure that I understand the discussion about cascading correctly. How I expect the filtering for code coverage to work is this: when I put one directory on the whitelist then only files that are in/under that directory must show up in the code coverage data. It does not matter where code in that files is called from.

RQuadling

2017-07-31 11:46

reporter   ~0004387

Has this feature had any movement?

derick

2017-12-28 19:14

administrator   ~0004527

Closed in Xdebug master, for Xdebug 2.6.0 (and beta1).

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
2017-04-26 07:14 stof Note Added: 0004328
2017-04-26 11:53 sebastian Note Added: 0004329
2017-07-31 11:46 RQuadling Note Added: 0004387
2017-12-02 18:35 derick Target Version 2.6.0dev => 2.6.0
2017-12-28 19:14 derick Note Added: 0004527
2017-12-28 19:14 derick Status confirmed => closed
2017-12-28 19:14 derick Resolution open => fixed
2017-12-28 19:14 derick Fixed in Version => 2.6.0
2017-12-28 19:16 derick Fixed in Version 2.6.0 => 2.6.0beta1