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
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug&quot; command="breakpoint_set" transaction_id="1006" id="4056520001"></response>

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:

<response command="breakpoint_set"
transaction_id="TRANSACTION_ID"
state="STATE"
id="BREAKPOINT_ID"/>

where,

BREAKPOINT_ID   is an arbitrary **string** that uniquely identifies this breakpoint in the debugger engine.

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.

Bill

DBGpResponse resp;
resp = session.sendSyncCmd(DBGpCommand.breakPointSet, args);
if (DBGpUtils.isGoodDBGpResponse(this, resp)) {
/*

• <response command="breakpoint_set"
• transaction_id="TRANSACTION_ID" state="STATE"
• id="BREAKPOINT_ID"/>
  */
  String bpId = resp.getTopAttribute("id"); //$NON-NLS-1$
  if (bp instanceof DBGpLineBreakpoint) {
  bp.setID(Integer.parseInt(bpId));
  } else if (bp instanceof DBGpExceptionBreakpoint) {
  ((IPHPExceptionBreakpoint) bp.getBreakpoint()).setId(this, Integer.parseInt(bpId));
  }
  if (DBGpLogger.debugBP()) {
  DBGpLogger.debug("Breakpoint installed with id: " + bpId); //$NON-NLS-1$
  }
  } else {
  // we have already logged the issue as an error
  }

Hi Bill,

yes, you're right. It should not be converted to an integer with "Integer.parseInt".

cheers,
Derick

Hi Derick

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.

Regards

Bill

char *d = CMD_OPTION('d');

/* Convert the raw d into a long */
errno = 0;
long dvalue = strtol(d, NULL, 10);

/*Check a numeric value was passed in d */
if (errno) {
    RETURN_RESULT(XG(status), XG(reason), XDEBUG_ERROR_BREAKPOINT_INVALID);
}

// Put a string value of dvalue back into d
sprintf(d,"%lu", dvalue);

if (breakpoint_admin_fetch(context, d, &type, (char**) &hkey) == SUCCESS) {

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.

Hey,

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.

cheers,
Derick

Sorry it took so long!

But this is now fixed for Xdebug 2.5.0RC2.