View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001756XdebugStep Debuggingpublic2020-03-05 11:522020-10-14 15:02
Reporterbarel Assigned Toderick  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformDockerOSMACOS Version10.13.6
Product Version2.9.2 
Target Version3.0devFixed in Version3.0.0beta1 
Summary0001756: Php process won't exit after running connected to a client
Description

This commit 37bfcc8a219a3ca88cb46f07a6404ce85e90fd84 (Re-add post-mortem checking for commands, and tweak tests) makes the php process not exit when running connected to a debugging client.

Steps To Reproduce
  • Enable an Xdebug client
  • Run a php file from the command line by using php file.php
  • After running the code, the process will not exit and you will need to hit CTL-C to finish it

I have traced the problem to this specific commit. My environment:

  • MacOS 10.13.6
  • PHP running within a docker environment (docker 2.2.0.0) with Alpine
  • PHP version 7.1.20
  • XDebug compiled with this commit, compiled with --enable-xdebug-dev (also happens with the non-dev version)

More info:

  • Happens for any php code, it is not tied to the particular code that you are running
  • php -v and php -i work fine and exit after outputting the info
TagsNo tags attached.
Attached Files
Operating System
PHP Version7.1.20-7.1.24

Activities

barel

2020-03-05 11:53

reporter   ~0005266

The debug client is PHPStorm

barel

2020-03-05 12:53

reporter   ~0005268

I am attaching here that remote log from one of the runs that failed to exit in case it helps

remote.log (4,247 bytes)    
[23203] Log opened at 2020-03-05 12:50:08
[23203] I: Connecting to configured address/port: docker.for.mac.localhost:10000.
[23203] I: Connected to client. :-)
[23203] -> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///var/www/i6-in2plane/fib.php" language="PHP" xdebug:language_version="7.1.20" protocol_version="1.0" appid="23203" idekey="PHPSTORM"><engine version="3.0.0-dev"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2019 by Derick Rethans]]></copyright></init>

[23203] <- feature_set -i 1 -n show_hidden -v 1
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="1" feature="show_hidden" success="1"></response>

[23203] <- feature_set -i 2 -n max_depth -v 1
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="2" feature="max_depth" success="1"></response>

[23203] <- feature_set -i 3 -n max_children -v 100
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="3" feature="max_children" success="1"></response>

[23203] <- feature_set -i 4 -n extended_properties -v 1
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="4" feature="extended_properties" success="1"></response>

[23203] <- feature_set -i 5 -n resolved_breakpoints -v 1
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="5" feature="resolved_breakpoints" success="1"></response>

[23203] <- feature_set -i 6 -n notify_ok -v 1
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="6" feature="notify_ok" success="1"></response>

[23203] <- stdout -i 7 -c 1
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stdout" transaction_id="7" success="1"></response>

[23203] <- status -i 8
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="status" transaction_id="8" status="starting" reason="ok"></response>

[23203] <- step_into -i 9
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="step_into" transaction_id="9" status="break" reason="ok"><xdebug:message filename="file:///var/www/i6-in2plane/fib.php" lineno="2"></xdebug:message></response>

[23203] <- eval -i 10 -- aXNzZXQoJF9TRVJWRVJbJ1BIUF9JREVfQ09ORklHJ10p
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="10"><property type="bool"><![CDATA[1]]></property></response>

[23203] <- eval -i 11 -- KHN0cmluZykoJF9TRVJWRVJbJ1BIUF9JREVfQ09ORklHJ10p
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="11"><property type="string" size="23" encoding="base64"><![CDATA[c2VydmVyTmFtZT10ZXN0LWNvbXBhbnk=]]></property></response>

[23203] <- stack_get -i 12
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="stack_get" transaction_id="12"><stack where="{main}" level="0" type="file" filename="file:///var/www/i6-in2plane/fib.php" lineno="2"></stack></response>

[23203] <- run -i 13
[23203] -> <stream xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" type="stdout" encoding="base64"><![CDATA[OA==]]></stream>

[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="13" status="stopping" reason="ok"></response>

[23203] <- run -i 14
[23203] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="run" transaction_id="14"><error code="5"><message><![CDATA[command is not available]]></message></error></response>
remote.log (4,247 bytes)   

barel

2020-03-05 13:08

reporter   ~0005269

It is specifically this code change that creates the problem:

In handler_dbgp.c line 2240

  • if ((XG_DBG(status) != DBGP_STATUS_RUNNING && (command->falgs & XDEBUG_DBGP_SYNC) == XDEBUG_DBGP_SYNC)
  • || (XG_DBG(status) == DBGP_STATUS_RUNNING && (command->falgs & XDEBUG_DBGP_ASYNC) == XDEBUG_DBGP_ASYNC)
  • if (
  • (XG_DBG(status) != DBGP_STATUS_RUNNING && XG_DBG(status) != DBGP_STATUS_STOPPING && (command->flags & XDEBUG_DBGP_SYNC))
  • ||
  • (XG_DBG(status) == DBGP_STATUS_RUNNING && (command->flags & XDEBUG_DBGP_ASYNC))
  • ||
  • (XG_DBG(status) == DBGP_STATUS_STOPPING && (command->flags & XDEBUG_DBGP_POST_MORTEM))

derick

2020-03-21 20:13

administrator   ~0005315

I think I fixed something related with https://github.com/xdebug/xdebug/commit/7db9edee8935af9c51520572437aaed3dbeeae0d through 0001766

derick

2020-03-28 13:23

administrator   ~0005355

Hi,

I've now fixed this in Git, but, this turned out not to be an actual bug in Xdebug. It is rather a bug in PhpStorm, which would issue an extra 'run' command in the 'stopping' state. As 'run' is not valid, Xdebug replies with an error, but there is no reason why Xdebug should then abort the connection. Xdebug did do that incorrectly previously, so I suppose PhpStorm just came to rely on this behaviour. In https://xdebug.org/docs/dbgp#initiating-a-debugging-session, there is the text "Likewise, at the end of a debug session, there is a 'stopping' state. This state is entered after all execution is complete. For most debugger engine implementations, only a 'stop' command can be accepted at this point, however some implementations may provide additional commands for retrieving various data from the engine for post debug session processing." And for the "stop" command (https://xdebug.org/docs/dbgp#continuation-commands) it says "stop: ends execution of the script immediately, the debugger engine may not respond, though if possible should be designed to do so. The script will be terminated right away and be followed by a disconnection of the network connection from the IDE (and debugger engine if required in multi request apache processes)."

I'll lodge a report with the PhpStorm team, but for now, the workaround that I've just committed should do the trick for now.

cheers,
Derick

derick

2020-03-28 13:36

administrator   ~0005356

As reference: https://youtrack.jetbrains.com/issue/WI-51991

Issue History

Date Modified Username Field Change
2020-03-05 11:52 barel New Issue
2020-03-05 11:53 barel Note Added: 0005266
2020-03-05 12:53 barel File Added: remote.log
2020-03-05 12:53 barel Note Added: 0005268
2020-03-05 13:08 barel Note Added: 0005269
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:37 derick Category Variable Display => Step Debugging
2020-03-21 20:13 derick Note Added: 0005315
2020-03-23 11:08 derick Target Version => 3.0dev
2020-03-28 13:23 derick Assigned To => derick
2020-03-28 13:23 derick Status new => closed
2020-03-28 13:23 derick Resolution open => fixed
2020-03-28 13:23 derick Fixed in Version => 3.0dev
2020-03-28 13:23 derick Note Added: 0005355
2020-03-28 13:36 derick Note Added: 0005356
2020-10-14 15:02 derick Fixed in Version 3.0dev => 3.0.0beta1