View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001242||Xdebug||Uncategorized||public||2016-01-02 22:32||2016-12-04 18:33|
|Platform||Windows||OS||Windows 2012||OS Version||2012|
|Fixed in Version||2.5.0|
|Summary||0001242: Xdebug on Windows with Eclipse has issues with breakpoint IDs|
Note that I've reported this as 2.4.0 rc3 because there is no option to report a problem against the GitHub code.
I've downloaded the source for PHP 7.0.1 and the XDebug source in the master branch on the XDebug githu site. I am able to compile the source using guidance here: http://www.kshabazz.net/build-php-on-windows.html
The compiled php.exe works well. When I reference the compiled php_xdebug.dll in php.ini and use PHPInfo() it reports XDebug 2.4 RC4 is being used. However when I try to use this configuration in Eclipse it does not work. PHP does not run. There is no error.
If I remove the reference to XDebug 2.4 RC4, Eclipse runs the PHP code using my compiled version of PHP 7.01 (though without a debugger).
If I reference the Xdebug package you compiled from the master branch (Dec 14th) it works and and am able to use the version of PHP 7.0.1 I compiled with your XDebug. That is, in Eclipse I'm able to step through the code.
If I compile the XDebug RC3 source available on the XDebug download page and reference this compiled DLL from php.ini I am also able to debug.
So the problem seems to be with the source I have downloaded from the master branch on GitHub or, at least, my use of it. The compiled php_xdebug.dll file is the correct size (184kb). Is there something I am supposed to do with the code from the master branch on GitHib before I use it to compile?
The reason I'm attempting to compile XDebug is to obtain the fix you created for my issue 1236 (XDebug reporting negative ids). Should I apply this fix and the one for 1223 to the RC3 code?
I wish I could give you a log but there are absolutely no errors shown anywhere.
|Steps To Reproduce|
Use PHP 7 with php_xdebug.dll compiled from the GitHub master in Eclipse.
|Tags||No tags attached.|
I applied the patch for bug 1223 to the RC3 code and the XDebug DLL worked OK. I then applied the patch for bug 1236. This stopped PHP working in Eclipse.
I think the issue can be seen in this line from my xdebug log file. You can see a breakpoint is set but the id returned to Eclipse is 4056520001. This number is too big.
<- breakpoint_set -i 1006 -t line -f file:///D:%5CXBRL%5CCode%5CXBRL-Report-Base.php -n 679
I will learn more about how to output information to the log file
How can the number be too big? The ID should not be considered as an unsigned integer number, but a string. If it's "too big", Eclipse has the bug. The specs say in http://xdebug.org/docs-dbgp.php#id1 :
debugger engine to IDE:
Of course you are correct. I do not know the specifications I just want to be able step through some PHP code. How do I get out of the middle of this? I am using Eclipse but am not wedded to it. Do you have any channels of communication with members of the PDT team?
Do you know of another debugging tool that is known to work with PHP 7 and XDebug 2.4 that offers a reasonable debugging experience?
You comment made me look at the issues reported on the PDT GitHub site. I am going to look at this change: http://git.eclipse.org/c/pdt/org.eclipse.pdt.git/commit/?id=97d7511d17845b47ab704c1ad94dc7e28da12d8f
The report was made a few days after you made the change to fix 1236. Perhaps the PDT team saw the same issue and the patch committed addresses my problem.
The issue I found in the Eclipse PDT bug tracker (above) has nothing to do with the problem I face and I think it's a lot worse. So let me ask you this question: is the code below wrong (it interprets the id from the response as an integer). Below is the code from the Eclipse PDT (org.eclipse.php.internal.debug.core.xdebug.dbgp.model.DBGpTarget.java). Even if you are not a Java programmer, you can see the XDebug command 'breakpoint_set' is executed and the XDebug response processed.
By the time the DBGpResponse instance is returned by session.sendSyncCmd() the response is parsed and the transaction_id extracted. In this code the 'id' (BREAKPOINT_ID from the specification) is accessed from the XDebug response as a string but then an attempt is made to convert the id to an integer. I assume this is just wrong.
yes, you're right. It should not be converted to an integer with "Integer.parseInt".
This post is to make a case for a specific modification to XDebug. In this issue report, I've seen that the implementation of the XDebug protocol in Eclipse PDT is not correct because it converts the BREAKPOINT_ID to an integer. However, I've learned it has to be this way because the whole of the Eclipse debugging support is based breakpoints having numeric identifiers.
A reminder of the core problem: it's not possible to remove a breakpoint during a debug session in Eclipse. This is an issue because once a breakpoint is set in, say, a for-loop the breakpoint cannot be removed to allow a for-loop to continue until the debug session is terminated. In Eclipse the problem of being unable to remove a breakpoint during a debug session is reported as:
DBGp Response Error: breakpoint_remove:=205 msg:no such breakpoint
I think it is possible to make everything work together with a modest change to the 'breakpoint_do_action' function in 'xdebug_handler_dbgp.c'.
Let me review why the problem occurs. When a breakpoint is set in XDebug RC3 and earlier versions it returns a negative number to the caller. This because the breakpoint id generated by XDebug is a large unsigned int. So the most significant bit is set and when presented using printf format '%d' it comes out as a negative number. For example, if XDebug generates the id '2286162193' then it will be returned to the caller as '-2008805103'.
I wonder if this may have been a deliberate decision at some time in the past. Because Eclipse has to convert the id returned by XDebug to a 4 byte integer it would never have worked if the unsigned version of the number were returned. This is because the Java integer type cannot accept an unsigned XDebug id because the value is too large to fit into a signed Java 4 byte signed integer.
OK, so XDebug generates an id that happens to comprise numeric characters and returns it as a negative number to the caller.
The problem is that the breakpoint cannot be removed because Eclipse holds the negative number provided by XDebug in response to a breakpoint_set call. Eclipse PDT sends this signed value to XDebug when a user removes a breakpoint during a debug session. However, XDebug is expecting the unsigned value for the id but is passed a signed, negative value so it can't find the breakpoint in its list so XDebug returns the error shown above.
The trick that is working for me (and I appreciate I do not understand the ramifications of the changes I have made and am suggesting in this note) is to intercept the 'd' parameter sent in the 'breakpoint_remove' command and make sure the 'd' parameter value appears as an unsigned long.
Below are the lines I added and modified. They start on line 682 of 'xdebug_handler_dbgp.c'. But first it is important to remove the change you made to accommodate issue 1236. As a result of this change, XDebug returns the unsigned breakpoint id value, a value that cannot be used in Eclipse. As a result of this change XDebug cannot be used with Eclipse PDT at all so it needs to be removed.
The lines below do something simple: grab the 'd' parameter value from the command string and convert it to a long. The long is then converted back to a string representation of the unsigned id. Finally, the string representation of the updated id is passed to 'breakpoint_admin_fetch' to retrieve the breakpoint - and it works.
I am able to compile php_xdebug.dll with these modification so now I am sorted. But I think it will be great if these changes or something similar can be added to code in GitHub.
I've created a pull request so you can see the changes in context. I'm not a C programmer so I do not appreciate the consequences of the function calls I've used for robustness or cross-platform support.
I also did not limit the change to affect just the breakpoint_remove command because it does not seem to be an issue if it is applied more widely. Someone with a better appreciation of the code will be able to make a more informed judgement.
I saw the Pull Request, but I don't think this is quite good enough. I'm going to have a look to see how to make this better in the near future. Likely, I might just mask the ID with 0x7FFFFFFF to make sure it fits within 32bit signed.
Sorry it took so long!
But this is now fixed for Xdebug 2.5.0RC2.
|2016-01-02 22:32||bseddon||New Issue|
|2016-01-03 02:02||bseddon||Note Added: 0003373|
|2016-01-03 10:49||derick||Note Added: 0003375|
|2016-01-03 10:49||derick||Assigned To||=> derick|
|2016-01-03 10:49||derick||Status||new => feedback|
|2016-01-03 10:50||derick||Note Edited: 0003375|
|2016-01-03 13:12||bseddon||Note Added: 0003377|
|2016-01-03 13:12||bseddon||Status||feedback => assigned|
|2016-01-03 13:18||bseddon||Note Added: 0003378|
|2016-01-03 16:49||bseddon||Note Added: 0003379|
|2016-01-03 19:39||derick||Note Added: 0003380|
|2016-01-04 02:01||bseddon||Note Added: 0003382|
|2016-01-04 12:05||bseddon||Note Added: 0003384|
|2016-01-11 22:44||derick||Note Added: 0003399|
|2016-07-31 12:36||derick||Category||Usage problems => Usage problems (Crashes)|
|2016-07-31 12:38||derick||Category||Usage problems (Crashes) => Usage problems (Wrong Results)|
|2016-11-23 21:27||derick||Summary||Compiled XDebug RC4 (Master) does not work in Eclipse => Xdebug on Windows with Eclipse has issues with breakpoint IDs|
|2016-11-23 21:32||derick||Note Added: 0003788|
|2016-11-23 21:32||derick||Status||assigned => closed|
|2016-11-23 21:32||derick||Resolution||open => fixed|
|2016-11-23 21:32||derick||Fixed in Version||=> 2.5.0RC2|
|2016-12-04 18:33||derick||Fixed in Version||2.5.0RC2 => 2.5.0|
|2020-03-12 16:35||derick||Category||Usage problems (Wrong Results) => Variable Display|
|2020-03-12 16:38||derick||Category||Variable Display => Uncategorized|