Profiler Tab stuck on "Loading profile"

[PopovicV]

I'm using Laravel 10 + Sail. I wanted to use clockwork to help me do code profiling with xdebug, but I'm having issues setting everything up.

I've added these two lines to .env file:
SAIL_XDEBUG_MODE=profile
SAIL_XDEBUG_CONFIG="client_host=host.docker.internal profiler_output_name=cachegrind.out.%t-%s"

and when I refresh a page in my application a new .json file is created in storage/clockwork, and when looking at headers in network tab there is X-Xdebug-Profile-Filename header.

I've also checked with phpinfo() if profiling is enabled and it is:

I can see all the info on Timeline tab inside clockwork add-on but when I switch to Profiler tab, it gets stuck with message "Loading profile...".

Am I missing anything? Are there any specific setup steps for using Clockwork with Sail?

[mattvb91]

Does this help? #591 (comment)

[UlrichEckhardt]

I've been trying to get the profiling to work with the Slim framework. Doing so, I found one thing that causes problems: The profiler output (xdebug_get_profiler_filename()) that is integrated into the Clockwork record (.../storage/clockwork/*.json) is sometimes truncated. I haven't investigated deeper yet why and when exactly that is the case. What I noticed is that the profile is sometimes truncated in the Clockwork record, but the file on disk is complete. My guess is that at the time the profile is retrieved from the file, it wasn't fully written yet.

The "Loading profile" message with the rotating progress indicator then gets stuck. I have only tried to reverse-engineer the JS code in Clockwork/Web/public/ and the loop there lacks a bit of error handling, it just chokes on the truncated input. When I added some checks there, it then came back with a message like "no profile info found" or so. I don't know where the actual source code for that condensed JS can be found, but the problem there is in the code that processes lines starting with "fl=". That code simply uses the two following lines without checking if they exist at all.

[UlrichEckhardt]

Short update on that: It seems that multiple complete records are written to the output file (xdebug_get_profiler_filename()). This is not caused by the ini setting xdebug.profiler_append, but probably rather by using PHP's builtin server (php -S...).

[itsgoingd]

Hey, you can try changing the xdebug.profiler_output_name setting if you are running into an issue with multiple profiles being written to the same file, we solved a similar issue here - underground-works/clockwork-app#109. I'm not sure if this will help in your case though, afaik the built-in php web server is single-threaded.

The xdebug.profiler_append should always be disabled (it is by default), as Clockwork does not expect multiple profiles in a single file.

Btw. you can find the source for the client app here - https://github.com/underground-works/clockwork-app

[UlrichEckhardt]

I'll try that! The default xdebug.profiler_output_name=cachegrind.out.%p (%p is a placeholder for the PID) will keep using the same file for every request (like profiler_append), because all requests are served in the same process. I'll find out which setting makes sense when using the builtin HTTP server.

Also, yes, this looks exactly like the bug reported against the clockwork-app project.

BTW: These are all things that are rather easy to get wrong and they will make the experience miserable. I've had good results in other apps by providing a diagnostic endpoint, where you query the app "Are you feeling well in this environment?". That endpoint (or CLI) would reply with a list of self-diagnostic checks and their results:

• For example, I'd add one check that profiler_append=false.
• Also, is XDebug enabled at all?
• Then, another check that when running with the builtin HTTP server, that you don't use the PID as placeholder in the profile.
• A check that the target directory for the Clockwork records can be accessed.
• ...

The use case is simply troubleshooting an installation. If something doesn't work, just call this endpoint to check for common errors before diving deeper. I'm still getting more familiar with the codebase, but I'm planning to implement something to better illustrate this goal.

[itsgoingd]

Yeah, having some diagnose command would be cool at some point. For starters, we should suggest changing the xdebug.profiler_output_name in the docs, as the default value does not make sense in most currently used ways to run php.