Skip to content


Subversion checkout URL

You can clone with
Download ZIP


RFC : getDebug() & setDebug() #132

olekukonko opened this Issue · 6 comments

3 participants


pThreads current does not work with xdebug, It is possible to enable a debug via setDebug where the following information can be available via getDebug

  • Time Taken
  • Memory Used
  • Errors Generated
  • Back Trace (Optional etc)

This can help a lot during development and and error logging in production environments

Suggestions and better Ideas are welcome


Anyone else have thoughts on this ??


I currently have something with debug_backtrace and register_tick_function to halt execution temporarily on certain points where I can get some command from stdin and eval() it (mostly some var_dump()).

It's not perfect what I've done here, but it's feasible to build your own PHP debugger in PHP.

@olekukonko How exactly should getDebug() work? get data from the last setDebug() or how?


Ping @olekukonko ... more info about your ideas would be useful ...


Like what kind of information do you need ? The basic idea is that profiling & optimization is a bit tricky when you have multiple threads doing different things. Have basic information would go a long way to make apps production ready since it does not work with profiling tools such as xdebug


Ok, isTerminated coupled with getTerminationInfo to tell where the termination occurred in the other thread, scope, function, file and line reported. This is enabled all the time ...

I'm still thinking up what to do for the other bits ... the problem is we cannot neatly turn everything into an exception that would be too intrusive, php doesn't save errors by default, adding handlers is intrusive also, exceptions are objects that were destroyed and generating a backtrace might turn out to be a headache, but have a go I will, bt will only be available in debug mode as it'll add a bunch of overhead ...


Here's what we'll do, take a look at profiler repos on here ... it'll be simpler to get that working to an acceptable level (it already does but callgrinds aren't trees), I have to mess about with it to make it work as far back as 5.3 I guess, but you'll be okay against 5.5 and commits before the last couple of days 5.4 ...

This gives us time taken (cpu ticks, not related to seconds but perfect for multithreaded tracing), memory used, code annotation, and eventually call trees (so stacktraces for every execution of everything) ... fatal errors we have handled in getTerminationInfo from within pthreads, so I think that's everything covered ...

I don't know how long it'll be before I can find the time to get trees working but I will eventually get round to it ...

@krakjoe krakjoe closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.