• Rewrote the xdebug_create_socket function so that it also supports creating sockets for IPv6 addresses.
• Wrote a couple of tests that test both IPv4 and IPv6 connectivity.
• Added some functions to the DebugClient (some refactoring to make it more extendable).
• Created a DebugClientIPv6 class that extends from DebugClient. This communicates with Xdebug over IPv6.

Known potential problems

• Haven't been tested on Windows.
• The DebugClientIPv6::isSupported() function isn't tested, so the SKIP for the test could be ignored on a machine that doesn't support IPv6.

@derickr Pick whatever you like of these fixes. I am not sure if tey are all correct, but they fixed compiling with VC14. php_xdebug.dll is still crashing, but given the failed tests (on Centos 6 as well) this does not surprise me. Moreover, with xdebug.so I also experienced segfaults on Centos.

You have a long way to go. Good luck with that.

This PR further improves https://github.com/xdebug/xdebug/pull/611. The simplest php functions (is_int, count, ...) take about 20 ns per call, but the best Windows timer has resolution of 100 ns [1] which implies that this timer source is short to simple php functions. When a script/project under test contain a lot of calls of simple php functions, the xdebug profiler output is quite ambiguous (some calls are recorded with 10 ns duration (minimal time step) and some with 100 ns (minimal timer step)).

This PR solves this issue by using RDTSC as a clock source, which has resolution of about 0.25 ns and reading it is fast, it takes about 6 ns per call. On modern CPUs (Nehalen or newer), it is incremented at constant rate

However, there is no way to detect the RDTSC speed, therefore it needs a short calibration (2 ms) and this feature ~must by enabled explictly by xdebug.profiler_tsc_as_clock php ini option~ is enabled by default on Windows but only for profile mode. As php process takes about 10 ms to startup on Windows, I belive the calibration delay is acceptable against much more accurate results.

[1] https://stackoverflow.com/questions/63205226/better-than-100ns-resolution-timers-in-windows

Since Xdebug doesn't call the previously defined error callback but replaces it, find a way to make it coexist with other extensions that replaces the error callback at RINIT, like APM.

https://github.com/pounard/xtrace2fg is a PHP tool that converts computerized xdebug trace output to https://github.com/brendangregg/FlameGraph suitable input for generating flamegraph.

As suggested in https://github.com/pounard/xtrace2fg/issues/1 by @derickr I tried to implement it directly into xdebug.

Please note that the memory support is probably buggy, it will show memory cost of each function when they allocate memory, but will fallback to 0 for functions that free memory, for the simple reason that flamegraph tool was probably not meant to be used this way and will cause error with negative values.

Because there is 2 different modes, I added 2 different trace handlers, 3 will write cost (time) in output file, 4 will write memory instead.

Please, be kind with me, I didn't write C for something like more than 15 years, last time being a student, there's some high probability I felt in C pitfalls and traps.

In order to have a meaningful output trace file, it's best to use 'self' function cost (no matter it's time or memory) instead of 'inclusive' values (including children own cost). If we return a trace using inclusive cost, it looks marvellously flat, sadly it doesn't yield any meaning, excepted if you want to dynamically draw a red pine forest for your children using your code :)

In order to compute 'self' cost, when children function exists, it increments a value in a linked list which carry one item per function_nr (functions being uniquely identified, we can find the calling function_nr within the stack easily). This linked list always prepend new items, instead of appending it, it makes both the increment and delete operations faster in the common case since that we will always attempt to access one of the most recently appended items (the parent).

My previous attempt was wrong, in order to compute 'self' cost, it now implements a stack in which functions are push on enter, their inclusive costs are increment into the parent on exit, then the stack item is removed on function exit. The need for reading xdebug own stack is therefore eliminated. At the same time, since we need to keep the absolute function path in stack as a string such as {main};some_func;other_called_by_some_func we store that information in the stack item as well so we don't need to traverse it when writing into the trace file. This solution should perform better.

Since stack items are freed once we return from a function, it will never grow bigger than the current stack depth, which should keep a low memory footprint, but with the new fibers API, I'm not sure how all this will behave, this probably needs a careful review.

I think the custom linked list here fits well with the need and I do not expect it to be a performance hog, I hope. Please tell me if the solution seems OK.

Just as a note, here be dragons, because I'm not expert in C, and I had to play with xdfree() and xdmalloc(), it's tested, but use-after-free or memory leaks are still possible.

add_name_attribute_or_element implicitly frees full_name but xdebug_var_export_xml_node passes it over to xdebug_array_element_export_xml_node which attempts to read it

This is the fix for #416, which was submitted in 2009 and 2010. It fixes the trace output of the return value in the computerized format (which was missing).

Fix https://bugs.xdebug.org/view.php?id=1016.

• cmdloop support block and non-block mode
• call cmdloop pre-statement.
• call cmdloop when breakpoint hits.

This commit basically takes the approach to filename comparison used under Win32 (use of "strncasecmp()" instead of "memcmp()") and makes it available on other systems, controlled by a configuration option ("xdebug.case_sensitive_fs"). The default value is 1, which causes the old, case-sensitive behavior. The Win32 code is left untouched.

This addresses bug #973 ("Breakpoints not triggered on case-insensitive file systems in files autoloaded by spl_autoload") by allowing a developer to change the behavior of xdebug to match the behavior of the filesystem.

The main thing that's not included is a test, which I wasn't sure how to implement.

I've rebased and done some extra cleanup (amazing what 6 months and fresh eyes will do). I also ran benchmarks again, this time with public code!

Using PHP 5.3.10 x86_64 compiled on OSX 10.6.8, run on a 3.2GHz i3 with 8GB 1333MHz RAM.

Each timing is the mean of 10 runs of PHPUnit 3.6 (sebastianbergmann/phpunit@5d0ff52bdff9afd479e38fdc880adce453ce88e5). Before each run of 10, I ran it 3 times in a row and threw out those results.

for x in {1..10}; do time ./phpunit.php 2>&1 >/dev/null; done

Before (derickr:master derickr/xdebug@004b99c8a8ad3b2a1986c931a1585e9d71a4b39a): real avg 18.414 s user avg 15.76 s sys avg 2.3133 s

After (taavi:coverage_line_array2 taavi/xdebug@cae8255ea43b9bc2087256968d20e221fa0863fb): real avg 17.666 s (4% improvement over before) user avg 15.0101 s (5% improvement over before) sys avg 2.2652 s (2% improvement over before)

I suspect it also reduces memory usage (given the cost of the hash tables and linked list entries vs 1-byte-per-line-in-a-file) and almost certainly reduces memory fragmentation (one alloc, and probably a few reallocs per file vs alloc-per-line).

Thanks!

Although it is possible to obtain the mode value in userland, it is quite cumbersome and possibly brittle to do so. This is fixed with the addition of an xdebug_mode() function:

xdebug_mode(?string $mode = null) : mixed

Returns the enabled xdebug modes as a comma-separated string, or if the $mode parameter is supplied, whether the named mode(s) are set.

For example, using xdebug.mode=debug,develop,coverage.

var_dump(xdebug_mode());                  // string(22) "develop,coverage,debug"
var_dump(xdebug_mode('off'));             // bool(false)
var_dump(xdebug_mode('debug,coverage'));  // bool(true)
var_dump(xdebug_mode('trace,debug'));     // bool(false)

Add new format to xdebug.trace_output_name to allow set the filename from $_COOKIE "XDEBUG_FILE"

%K filename (from $_COOKIE if set) trace.%K trace.filename_in_set_in_the_XDEBUG_FILE_cookie.xt