All costs show "0.00"

[JacobDB]

Very new to this software, trying to get it set up locally to diagnose issues with a client's site. Running in to a strange problem where absolutely no timing data exists. You can see in the screenshot "4452 different functions called in milliseconds ( runs, 4452 shown)" (missing the actual number of milliseconds), as well as "0.00" for all costs. Very frustrating.

Ubuntu 18.04.4 64-bit (WSL1)
PHP 7.4.3

I thought this might be related to #119, but trying that patch did not solve the issue.

[alpha0010]

Is this resolved in version 1.7?

[t-schroeder]

I recently ran into this. Deleting the old bin/preprocessor fixed it for me.

[jacobweber]

For what it's worth, I just ran into this, but realized that my script had an error (exceeded the max_execution_time). For whatever reason this resulted in 0s in the time columns.

[anttikanes]

Seems to still exist in 1.8 downloaded from Github as run on a Debian system with PHP7.3 - same cachegrind.out produces correct (or so presumed) cost summaries on version 1.2 but will only have 0.00 when analyzed with 1.8.

[einacio]

I have this problem with scripts that have too many calls or long run time.

Debugging the process, I saw that the "summary" header was not set in those runs.

At one point I made a test disabling the binary preprocessor so I could test it with PHP, and that one worked just fine, so it's a difference in the implementation.

@jokkedk @alpha0010
I managed to fix it by changing on the preprcessor.cpp the types of FunctionData.invocationCount, summedSelfCost and summedInclusiveCost from int to long. I don't know much cpp, probably unsigned int or something else is more appropriate.
From that point on, the results from the binary and php preprocessors are the same.

[alpha0010]

Xdebug 3 has a change in timing resolution. #145 partially fixed that with changes to the reader. However, that fix means integer overflow on 32-bit values means anything running longer than about 45 seconds will likely give wrong values. Using unsigned (which it was supposed to be doing already...) would support double that. uint32_t would be the type to use (which is likely what PHP processor is doing internally).