No matter how much I think I know about about character encoding or trying to work around issues arising from the same, I’ll always get bitten.<\/p>\n
For a long time, one particular FATE<\/a> configuration has shown 87\/127 tests succeeding, even though the total number of test specs has crept up over to 300. I investigated this errant configuration on the client side and concluded that it was, in fact, executing all of the tests and sending all the results over the server in one neat package. Apparently, the problem was on the server side. Since it was an older Intel C compiler configuration, I didn’t care about investigating much further.<\/p>\n At one point, some bad bit of code was checked into FFmpeg and all of the results started showing xy\/127 tests succeeded. This made the issue a bit more pressing. Mans<\/a> discovered that the problem had to do with the svq3 test spec<\/a> failing. The bad code affecting the SVQ3 test was quickly fixed so I didn’t worry about it again until yesterday when, once again, FATE’s various configs were only reporting that 127 tests had been run.<\/p>\n Here’s what was happening: FATE stores the stderr output of a test only if<\/em> the test spec fails. This is a key data point since everything is fine when the test is successful and FATE tosses the output. The sample used for the SVQ3 test outputs the following metadata (among other data) in the stderr (seen, for example, in this test result<\/a>):<\/p>\n Those mystery characters map to the byte 0xA9 which is the c-in-a-circle copyright symbol according to UTF tables I can find (at least, U+00A9 is). That byte is making the system choke somewhere along the line, which annoys me greatly. When the client-side Python script executes the test and stuffs the stdout and stderr into the SQLite database, the relevant field is supposed to be a blob– a binary large object<\/em>. The receiving PHP script on the server is also supposed to honor that blob schema.<\/p>\n Mans’ solution is to specifically encode the stdout\/stderr blobs as UTF8 strings in the client-side Python script. That fixes this problem. But I’m confused as to why this is necessary in the first place. Was the PHP script doing its best to interpret the data inside the blob and falling over? Or was the SQLite engine on the server confused by the 0xA9 character in the blob?<\/p>\n\r\n copyright : ?<\/em> Vertical Online 2001\r\n copyright-eng : ?<\/em> Vertical Online 2001\r\n<\/pre>\n