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.
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.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.