diff options
author | Fred Wright <fw@fwright.net> | 2016-01-04 14:55:29 -0500 |
---|---|---|
committer | Eric S. Raymond <esr@thyrsus.com> | 2016-01-04 14:55:29 -0500 |
commit | 3b66e6cb486b157aad6a65b22caae65e10b8b4e5 (patch) | |
tree | c6ae2b37e16f12e8e626c0b9481f1f4be2e800b0 /test/sample.aivdm.chk | |
parent | 753b96619a490369e3c73ea55eca571f64d1b935 (diff) | |
download | gpsd-3b66e6cb486b157aad6a65b22caae65e10b8b4e5.tar.gz |
Address bug #46802: AIVDM to CSV is broken in some weird cases
While trying the regression tests on a MacBook (PowerPC), I ran across
some failures in the "Testing AIVDM decoding w/ CSV format" test. The
failing type/dac/fid cases were as follows:
6,1,14
6,1,18
6,1,30
6,1,32
8,200,10
The proximate cause is endian dependence in the CSV output, but the
real problem turns out to be that the code is broken on all platforms,
but only fails on big-endian platforms because the
incorrect-but-presumed-correct output was captured on a little-endian
processor.
The problem arises when the type 6 or type 8 case is supported by the
AIVDM parser but not by the CSV formatter. When the parser doesn't
support the case, it falls back to capturing the raw binary
bitdata. When the formatter doesn't support the case, it falls back to
dumping the raw binary bitdata. But in the offending cases, the raw
data was never correctly captured, and is instead an overlaid view of
the structured data, which is incorrect (as raw data) in all cases as
well as being endian-sensitive due to the presence of multibyte
quantities in host byte order.
The only way to make the CSV fallback work as intended would be to
change the struct ais_t type6 and type8 substructure definitions to
move the bitdata field out of the union and populate it
unconditionally. But this would increase the memory footprint and add
to the core code for the sole purpose of providing more useful output
in these cases of missing CSV formatting support, which doesn't seem
very justifiable.
The alternative is simply not to report the unavailable raw bitdata at
all in these cases, but instead to report something indicating that
the raw data is unknown. I've implemented a version of this where the
formatting remains the same (including the bit count) but the hex data
is replaced by "x" characters (which seemed safer than using "?",
given the absence of the latter in any existing cases.
After implementing the code change and before updating the test data,
I saw one additional miscompare that I'd not seen on the PPC. This was
for the 6,1,12 case, where the existing test data is too incomplete to
populate the endian-sensitive fields in the decoded form, but which
would have failed with a better version of the test case.
After updating the test data as well as the code, the test passes on
both x86_64 and PPC.
P.S.:
There are three additional uses of gpsd_hexdump in the CSV output, for
types 17, 25, and 26, but those all seem to populate the bidata field
unconditionally (and type 17 doesn't even have a "structured" flag),
so I left them alone.
Clearly the right fix would be to implement the missing CSV formatting
cases, which would render the fallback code unreachable, but it could
become reachable again if new cases were implemented in the parser and
not in the CSV formatter, so having a well-behaved fallback seems like
a good idea.
Diffstat (limited to 'test/sample.aivdm.chk')
-rw-r--r-- | test/sample.aivdm.chk | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/test/sample.aivdm.chk b/test/sample.aivdm.chk index bae01919..39d75662 100644 --- a/test/sample.aivdm.chk +++ b/test/sample.aivdm.chk @@ -7,9 +7,9 @@ 6|1|150834090|3|313240222|0|669|11|48:eb2f118f7ff1
6|0|992509976|0|2500912|0|235|10|274|1|1|2|2|0|0|0
6|0|265538450|0|2655651|0|1|40|16:0000
-6|0|230986000|2|970110950|1|1|12|56:30435445530000
-6|3|002443808|0|329176500|1|1|14|80:00000000000000000100
-6|3|002442101|1|244615956|1|1|18|80:01000000000000000000
+6|0|230986000|2|970110950|1|1|12|56:xxxxxxxxxxxxxx
+6|3|002443808|0|329176500|1|1|14|80:xxxxxxxxxxxxxxxxxxxx
+6|3|002442101|1|244615956|1|1|18|80:xxxxxxxxxxxxxxxxxxxx
7|0|002655651|265538450|0|0|0
7|1|655901842|158483613|321823389|836359488|0
7|2|537411077|43101326|717096664|76161024|0
@@ -18,7 +18,7 @@ 8|0|992509977|1|11|-368039|3197693|18T17:15Z|3|6|12|15|742|50|323|224|2|153|16|1|103|256|104|257|10|126|203|20|42|35|25|23|48|124|3|223|6|53|0
8|0|992509977|1|11|-368037|3197689|18T17:45Z|127|127|511|511|2047|127|1023|511|3|255|511|3|255|511|255|511|31|255|511|31|255|63|511|255|63|511|15|1023|7|511|3
8|0|992509977|1|31|-368044|3197696|29T23:24Z|127|127|360|360|-1024|101|501|511|3|127|4001|3|255|360|255|360|31|255|360|31|255|63|360|255|63|360|13|501|7|510|3
-8|0|244650946|200|10|112:3032313033353437000000008601
+8|0|244650946|200|10|112:xxxxxxxxxxxxxxxxxxxxxxxxxxxx
8|0|244650946|200|10|368:c32c70cf5d370c3064fa50198800b4987e9555557e083a544f082003b809ae511bfc75f0a7ff960808ccb6be7ed5
9|0|111265591|15|0|0|7128960|34667073|0|28|0x0|0|0|0xc02a
9|0|111232511|303|42|0|-3767306|34886400|1545|15|0x0|1|0|0x8270
@@ -71,11 +71,11 @@ 4|0|002242115|2012-06-01T24:60:60Z|1|-5031130|26021408|7|0|0x208ca
4|0|972158237|10196-00-24T09:57:37Z|1|123070132|65599231|14|1|0x8c8
22|2|875794037|3396|373|1|0|837968222|254804543|1|0|1|7
-6|0|002444012|0|255803540|1|1|18|80:01000000000000000000
-6|3|002442102|0|244100055|1|1|30|80:01000000280000000000
-6|0|002444012|0|255803540|1|1|18|80:01000000000000000000
-6|3|002442101|2|246351000|0|1|32|80:00000000000000000100
-6|3|002442104|0|245679000|0|1|32|80:00000000000000000100
+6|0|002444012|0|255803540|1|1|18|80:xxxxxxxxxxxxxxxxxxxx
+6|3|002442102|0|244100055|1|1|30|80:xxxxxxxxxxxxxxxxxxxx
+6|0|002444012|0|255803540|1|1|18|80:xxxxxxxxxxxxxxxxxxxx
+6|3|002442101|2|246351000|0|1|32|80:xxxxxxxxxxxxxxxxxxxx
+6|3|002442104|0|245679000|0|1|32|80:xxxxxxxxxxxxxxxxxxxx
8|1|002300061|1|11|1464000|3879000|20T18:27Z|11|12|162|167|473|80|1023|232|2|255|511|3|255|511|255|511|31|255|511|31|255|63|511|255|63|511|15|1023|7|511|3
8|1|002300057|1|11|1617700|3622270|20T18:27Z|18|22|99|99|569|56|1023|231|2|255|511|3|255|511|255|511|31|255|511|31|255|63|511|255|63|511|15|1023|7|511|3
8|0|992611190|1|31|1126600|3264671|20T18:28Z|17|127|132|511|14|127|-1|214|3|127|1538|3|0|0|255|511|31|255|511|31|0|0|0|255|63|511|15|-1|7|511|3
|