Bug 989851
| Summary: | gpsbabel: Definition message reserved bits not zero | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Conrad Meyer <cse.cem+redhatbugz> | ||||||||
| Component: | gpsbabel | Assignee: | Ralf Corsepius <rc040203> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 19 | CC: | itamar, rc040203, rhbugs, silfreed | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | gpsbabel-1.4.4-5.fc18 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-08-12 18:02:53 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
For what it's worth, here's the backtrace around where this behavior occurs:
(gdb) bt
#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
Relevant code:
static void
fit_parse_definition_message(uint8_t header)
{
...
// 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: http://article.gmane.org/gmane.comp.hardware.gps.gpsbabel.devel/3823 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: https://code.google.com/p/gpsbabel/source/detail?r=4400 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. Thanks, Conrad 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. https://admin.fedoraproject.org/updates/gpsbabel-1.4.4-5.fc19 Thanks! Added karma to the F-19 update, thanks. gpsbabel-1.4.4-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/gpsbabel-1.4.4-5.fc18 Package gpsbabel-1.4.4-5.fc18: * 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: https://admin.fedoraproject.org/updates/FEDORA-2013-14095/gpsbabel-1.4.4-5.fc18 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.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. |
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): gpsbabel-1.4.4 How reproducible: Always. Attaching example .fit file... Steps to Reproduce: 1. gpsbabel -i garmin_fit -f <attached_file.fit> -o gpx -F xxx.gpx Actual results: With debugging enabled: GPSBabel Version: 1.4.4 fit: header len=14 fit: protocol version=16 fit: profile version=135 fit: fit_data.len=8928 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 Expected results: 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. Additional info: 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.