Red Hat Bugzilla – Bug 989851
gpsbabel: Definition message reserved bits not zero
Last modified: 2013-08-12 14:02:53 EDT
Created attachment 780327 [details]
Input file that gpsbabel fails to process
Description of problem:
gpsbabel aborts when a specific reserved byte in Garmin .fit files is non-zero.
Version-Release number of selected component (if applicable):
Always. Attaching example .fit file...
Steps to Reproduce:
1. gpsbabel -i garmin_fit -f <attached_file.fit> -o gpx -F xxx.gpx
With debugging enabled:
GPSBabel Version: 1.4.4
fit: header len=14
fit: protocol version=16
fit: profile version=135
fit: starting to read data with fit_data.len=8928
.....fit: got data message at fit_data.len=8927 ...local message type 0x2
.....fit: got definition message at fit_data.len=8926 ...local message type 0xB
fit: Definition message reserved bits not zero
Conversion as usual. I'm not sure what the fix should be. I think maybe warning about the non-zero byte, printing the value, and then proceeding might be the best course forward, although of course we should test that this works given the source file.
The byte is 0x40, which is suggestive of some kind of flag. It's not clear what the flag signifies.
gpsies.com successfully converts the source file. I don't think they publish source code, but it's possible they just ignore the bit.
For what it's worth, here's the backtrace around where this behavior occurs:
#0 fit_parse_definition_message (header=91 '[') at garmin_fit.c:183
#1 fit_parse_record () at garmin_fit.c:435
#2 fit_read () at garmin_fit.c:461
#3 0x00000000004046de in main (argc=10, argv=0x7fffffffdd28) at main.c:368
// first byte is reserved
is_fatal(fit_getuint8() != 0,
MYNAME ": Definition message reserved bits not zero\n");
Submitted bug, patch to upstream on -code mailing list:
Created attachment 780332 [details]
Bad patch, ignore
This issue appears fixed in upstream SVN already... I've asked them to cut a new release so we can update in Fedora.
After speaking with the project leader off-list, the changes to garmin_fit.c in r4400 upstream resolve this issue:
Upstream is in the middle of a rewrite and doesn't want to cut a new release any time soon. It's unclear if they are willing to push a maintenance release. I think Fedora should adopt at least the garmin_fit.cc portion of the patch until a new release comes out. I'll attach a new patch shortly.
Comment on attachment 780332 [details]
Bad patch, ignore
This is not the correct fix. Will backport r4400 soon.
Thanks for the report.
(In reply to Conrad Meyer from comment #6)
> This is not the correct fix. Will backport r4400 soon.
OK, I'll wait for the things to settle.
Created attachment 780934 [details]
Backport of upstream r4400 garmin_fit fix for 1.4.4
This patch should fix the issue, thanks.
Patch applied in gpsbabel-1.4.4-5.fc20
gpsbabel-1.4.4-5.fc19 has been submitted as an update for Fedora 19.
Added karma to the F-19 update, thanks.
gpsbabel-1.4.4-5.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gpsbabel-1.4.4-5.fc18'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
gpsbabel-1.4.4-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
gpsbabel-1.4.4-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.