trconv.Atoi: parsing ]]></stream>": invalid syntax

[lsascha]

I know there is already a solved issue here that mentions the issue with trconv.Atoi: parsing is fixed.
but i now tried for quite a while to get this running.
But i always get these errors in the debug output of the container running the debugproxy:

trconv.Atoi: parsing "zZXIvZm9yZ290cGFzc3dvcmQiPlBhc3N3b3J0IHZlcmdlc3Nlbj88L2E+CiAgICAgICAgICAgICAgICA8L3A+CgogICAgICAgICAgICAgICAgPGlucHV0IHR5cGU9InN1Ym1pdCIgdmFsdWU9IkxvZ2luIiBjbGFzcz0iYnRuIGJ0bi1wcmltYXJ5IiAvPgogICAgICAgICAgICA8L2Zvcm0+CiAgICAgICAgCgogICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zZWN0aW9uPgogICAgICAgICAgICAgICAgICAgICAgICAKCiAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICA8L21haW4+CiAgICAgICAgICAgIDwvZGl2PgogICAgICAgIDwvZGl2PgoKICAgICAgICA8c2NyaXB0IHNyYz0iaHR0cHM6Ly9jZG4uanNkZWxpdnIubmV0L25wbS9AcG9wcGVyanMvY29yZUAyLjkuMS9kaXN0L3VtZC9wb3BwZXIubWluLmpzIiBpbnRlZ3JpdHk9InNoYTM4NC1TUjFzeDQ5cGN1TG5xWlVublB3eDZGQ3ltMHdMc2s1Slp1TngyYlBQRU56c3dUTkZhUVUxUkR2dDN3VDRnV0ZHIiBjcm9zc29yaWdpbj0iYW5vbnltb3VzIj48L3NjcmlwdD4KICAgICAgICA8c2NyaXB0IHNyYz0iaHR0cHM6Ly9jZG4uanNkZWxpdnIubmV0L25wbS9ib290c3RyYXBANS4wLjAtYmV0YTMvZGlzdC9qcy9ib290c3RyYXAubWluLmpzIiBpbnRlZ3JpdHk9InNoYTM4NC1qMENOTFVlaXF0eWFSbWx6VUhDUForR3k1ZlF1MGRRNmVaL3hBd3c5NDFBaTFTeFNZKzBFUXFOWE5FNkRaaVZjIiBjcm9zc29yaWdpbj0iYW5vbnltb3VzIj48L3NjcmlwdD4KICAgICAgICA8c2NyaXB0IHNyYz0iaHR0cDovL2xvY2FsLmF3by1laHJlbmFtdC5kZS9fUmVzb3VyY2VzL1N0YXRpYy9QYWNrYWdlcy9Bd28uRWhyZW5hbXQvYXNzZXRzL2pzL2FkbWluL3Rvb2x0aXAuanMiIHR5cGU9InRleHQvamF2YXNjcmlwdCI+PC9zY3JpcHQ+CiAgICA8L2JvZHk+CjwvaHRtbD4K]]></stream>": invalid syntax

which comes right after a line with this content:

Processed protocol:
debugproxy_1_679f7c439e19 | <stream xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" type="stdout" encoding="base64">DQo=</stream>

and just now i got the error (with an extremely long gibberish value) after this line:

Processed protocol:
debugproxy_1_679f7c439e19 | <stream xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" type="stdout" encoding="base64">Q29udGVudC10eXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTg=</stream>

when i base64 decode the line of my first logged line, i get something like a linebreak or similar.

if i decode the second logged line i get Content-type: text/html; charset=UTF-8 But i don't know if these are even lines that are supposed to appear in these base64 values. So not sure if i still have some wrong configuration or if anything else is wrong here.

Using PHP v7.3.27
xdebug v2.8.0
in a docker environment

[dlubitz]

Same here. I assume this is caused by xdebug 2.8?

[dfeyer]

It happends with XDebug 3.0 too ... hard to debug and actually I don't really understand the problem. Look like related to protocol string length ... need to ready again the XDebug spec ...

[dlubitz]

I tried to get this fixed, but I failed, due to my lack of GO knowledge. I'd like to share my findings, so maybe some else can fix it.

Main issue is the current handling of the incoming stream buffer from xdebug.
https://github.com/dfeyer/flow-debugproxy/blob/master/xdebugproxy/xdebugproxy.go#L99-L174

The current implementation assumes that each chunk of the stream contains maximum ONE package. The latest change (PR #20) has improved it, in case the chunk does not contain all information of the package.

Issue is now, that the chunk contains more than ONE package, which is not handled. So the string sent to the mapper might contain a incomplete package, which is not parseable.

e.g:

17 NULL this is a package NULL 23 NULL this is another package NULL 101 NULL this package is incompl

For some reason this might have changed in the past, as this code was actually working before. Maybe it's something special due to a configuration or environment.

I tried to fix this by iterating over all package parts and checking if the last one is complete. If not to read the next chunk from the stream until it's complete. But this can also lead to a "leftover" package part. And as I said, it doesn't work as expected. (See: dlubitz@6617a03)

Maybe this helps someone else to solve the issue.

For me increasing the buffer size which is now set to 64KB resolved this issue (see line: https://github.com/dfeyer/flow-debugproxy/blob/master/xdebugproxy/xdebugproxy.go#L99)

The size of the message from the Debugger >>> IDE would exceeded this buffer size (76880 bytes in my case):

debugproxy_1  | Debugger >>> IDE
debugproxy_1  | ================
debugproxy_1  | Raw protocol:
debugproxy_1  | <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="detach" transaction_id="14" status="stopping" reason="ok">
debugproxy_1  | </response>
debugproxy_1  |
debugproxy_1  | Processed protocol:
debugproxy_1  | <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="detach" transaction_id="14" status="stopping" reason="ok">
debugproxy_1  | </response>
debugproxy_1  |
debugproxy_1  | Closed (76880 bytes sent, 443 bytes recieved)

As a quickfix I doubled this size to 128KB (0x20000)