Community
Participate
Working Groups
Build Identifier: in org.eclipse.tm.tcf.core/src/org/eclipse/tm/internal/tcf/services/remote in MemoryProxy.java , MemoryProxy.MemContext#get()$MemoryCommand#done() can end up with a perfectly valid 3-byte buffer that should be filled with the Byte64 filled string containing the values to place in the buffer. however, the algorithm of JSON.toByteArray() will choke on this input. (it's possible that the value passed back is not properly terminated, or that JSON didn't take this into account; but it the conversion routine throws IllegalArgumentException if the buffer is not big enough.) I will attach a patch that causes this not to happen. Reproducible: Always Steps to Reproduce: 1. create a plug-in that uses TCF 2. attempt to get a 3-byte chunk of memory that will fail if the portion of the code using TCF to retrieve memory fails with an unhandled IllegalArgumentException in the call made from JSON.toByteArray() => FAIL
Created attachment 179604 [details] patch to MemoryProxy.java that bulletproofs the call to JSON.toByteArray()
I cannot reproduce the error. Reading 3-byte chunk of memory appears to work fine in the current code. It looks like you are using agent that is different from one in Eclipse repository, and it produces malformed BASE64 strings. Can you send a value of BASE64 string that causes JSON.toByteArray() to fail? If the string is indeed malformed, throwing IllegalArgumentException is correct behavior. BTW, what does the exception message say?
the problem occurs on a target which disallows the reading of the 3 bytes in question due to access restriction. an error message is getting sent back. the String being sent back is something like "TLTVAA==" ... 8 characters, with the last two being "=" signs. when the Byte64 translator parses this, it starts with an outlen of 8/4*3 or 6, and then reduces the size for each of the "=" signs so outlen is 4 … which is still larger than the input buffer which is 3.
So the agent does misbehave. Even if it can read memory only in 4-byte chucks, it should transmit only requested number of bytes. Otherwise it is a communication error and an the exception seems to be the best way to report it. Looks like agent problem to me.
i will see about what the agent is doing. sounds like the expectation is that it should only be returning a JSON string of 4 bytes that gets turned into the buffer of 3 that i want.
Moving bugs to new home for IP log.
