I have been debugging drush commands with xdebug and my IDE (currently PHPStorm 7) for a while, but I have been noticing that there are certain commands that die whenever I have the dubegger enabled in the IDE. From what I can tell, it's commands that do batch processing and therefore call drush_backend_batch_process(). In tracking it down as far as it will let me with the debugger, it looks like it dies in _drush_backend_proc_open().

An off the shelf example is the solr-index command in the apachesolr module. I can debug up to the point where drush_backend_batch_process() is called, but it never returns from that call.

Is this a known issue with xdebug on the command line with drush with no way around it? Or is there something I can do in my configuration?


  • It dies silently? Or there is some message?
    – Mołot
    Apr 2, 2014 at 6:33
  • No, there is nothing. It just hangs, and I have to hit Ctrl-C (or kill the debugger from within the IDE) to be able to get the command line prompt back.
    – wonder95
    Apr 3, 2014 at 12:47
  • Oh. Good luck then, I must admit I have no idea. Batch processes are always harder to debug, but never encountered this particular effect.
    – Mołot
    Apr 3, 2014 at 12:51

2 Answers 2


You're debugging your script using IDE which require valid xdebug.idekey to be present in the session which probably isn't passed correctly to the forked process.

It's probably the bug of XDebug (see: #938) which doesn't debug well the forked processes.

I assume you've xdebug.remote_port working correctly and there is no any communication issue. Remote debugging generates log file (defined by xdebug.remote_log), so you should check further debugger communications details there.

As for workaround, you should debug your script manually by calling the functions: xdebug_start_trace() and xdebug_stop_trace().

In case debugging on demand won't work with forked processes, enable xdebug.auto_trace, restart Apache, so all forked processes can be debugged properly which will generate huge trace file which you can analyze (defined by xdebug.trace_output_dir/xdebug.trace_output_name).

Check my xdebug.ini for suggestions, especially these settings are useful to see all the details:

; Data
xdebug.default_enable = 1           ; bool: The stacktraces will be shown by default on an error event.
xdebug.collect_vars = 1             ; bool: Gather information about which variables are used in a certain scope.
xdebug.show_local_vars=1            ; int: Generate stack dumps in error situations.
xdebug.collect_assignments=1        ; bool: Controls whether Xdebug should add variable assignments to function traces.
xdebug.collect_params=4             ; int1-4: Collect the parameters passed to functions when a function call is recorded.
xdebug.collect_return=1             ; bool: Write the return value of function calls to the trace files.
xdebug.var_display_max_children=256 ; int: Amount of array children and object's properties are shown.
xdebug.var_display_max_data=1024    ; int: Max string length that is shown when variables are displayed.
xdebug.var_display_max_depth=5      ; int: How many nested levels of array/object elements are displayed.
xdebug.show_mem_delta=0             ; int: Show the difference in memory usage between function calls.
xdebug.show_exception_trace=0       ; bool: Show a stack trace whenever an exception is raised.
xdebug.max_nesting_level=200        ; int: Controls the protection mechanism for infinite recursion protection.

If XDebug still won't work, then consider using phpdbg instead.

For suggestions how to debug Batch API process, see: How to debug Batch API more efficiently?


I'm not sure if this is the issue or not; but I THOUGHT I had this issue while running migrations with Drush into Drupal 8 from command line. Would just die and hang on Drush's proc_close.

Apparently, increasing the number of debug connections mattered, inside of my IDE (PHPStorm).


Perhaps since Batch API makes multiple requests, this is necessary?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.