Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error handling Section 1 with extra baggage #47

Open
vsouvan opened this issue Apr 19, 2020 · 2 comments
Open

error handling Section 1 with extra baggage #47

vsouvan opened this issue Apr 19, 2020 · 2 comments

Comments

@vsouvan
Copy link
Collaborator

vsouvan commented Apr 19, 2020

Found this with the G-AIRMETs at:
ftp://tgftp.nws.noaa.gov/SL.us008001/DC.avspt/DS.sgairmet/PT.bin_DF.buf/

The section 1 length in these messages is 22 octets. A normal (edition 3) section 1 is 17 bytes padded out to 18. The 17 bytes is tracked in s1.header_len, and the 18 byte length in s1.len. The s1.data_len ends up being 5 in this case.

It triggers a failure in the section 4 size calculations, which causes section 4 to have a 1 byte undersize because it uses s1.len + s1.data_len... well, s1.len = s1.header_len+1 and this never gets recalculated when the baggage is handled. 18+5 != 22...


Imported from Launchpad using lp2gh.

@vsouvan
Copy link
Collaborator Author

vsouvan commented Apr 19, 2020

(by yves-pelletier)
Chris,

Would it be worthwhile to add one of these messages to the test suite?

Yves

@vsouvan
Copy link
Collaborator Author

vsouvan commented Apr 19, 2020

(by chris-beauregard)
On 03/22/2012 01:57 PM, Yves Pelletier wrote:

Chris,

Would it be worthwhile to add one of these messages to the test suite?

Already done. It's just SOP. Anytime I find a bug triggered by a piece
of data, it goes into the test suite. There's also one in the MetManager
test suite. And for the most part, when I find a bug triggered by a
certain use of the API, I write/modify a test program to trigger the bug.

Having to fix a bug sucks. Having to fix a bug twice because your test
suite didn't see it come back is a whole other level of sucks.

The trick is that the decoder doesn't handle this particular message
because it claims to use Table 13, but uses descriptors which aren't
found in the Table 13 included with libecbufr. No further comment on
that particular issue ;)

However, it's okay for regression testing. The failure mode before I
fixed it was that it didn't even recognize the message as valid BUFR
because the section 4 off-by-one meant it couldn't see section 5. Now,
it can find all the sections and make sense of them even if it can't
actually display the data payload. That's fixed enough for me.

c.

@vsouvan vsouvan added this to the 0.8.5 milestone Apr 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant