Segmentation fault with Navin Minihomer

[kgraefe]

When trying to download the GPS log from my minihomer, gpsbabel segfaults. I think the device has tracks from both before and after the week rollover, so that might cause the issue?

root@raspberrypi0-wifi:~# gpsbabel -D 3 -i miniHomer,initbaud=0 -f /dev/ttyUSB0  -o gpx -F /var/run/minimonty.gpx
GPSBabel Version: 1.6.0
main: Compiled with Qt 5.10.1 for architecture arm-little_endian-ilp32-eabi-hardfloat
main: Running with Qt 5.10.1 on Linux 4.14.68, arm
main: QLocale::system() is C
main: QLocale() is C
main: QTextCodec::codecForLocale() is ISO-8859-1, mib 4
options: module/option=value: miniHomer/baud="115200" (=default)
options: module/option=value: miniHomer/erase="0" (=default)
options: module/option=value: miniHomer/first-sector="0" (=default)
options: module/option=value: miniHomer/initbaud="0"
options: module/option=value: miniHomer/last-sector="-1" (=default)
options: module/option=value: miniHomer/no-output="0" (=default)
options: module/option=value: miniHomer/read-at-once="255" (=default)
skytraq: Probing SkyTraq Venus at 9600baud...
skytraq: Didn't get message start tag
Didn't receive ACK (-3), retrying...
skytraq: Didn't get message start tag
Didn't receive ACK (-3)
skytraq: Probing SkyTraq Venus at 230400baud...
skytraq: Didn't get message start tag
Didn't receive ACK (-3), retrying...
skytraq: Didn't get message start tag
Didn't receive ACK (-3)
skytraq: Probing SkyTraq Venus at 115200baud...
Receiving message with 2 bytes of payload (expected >=2)
Receiving message with 2 bytes of payload (expected >=2)
Got ACK (id=0x02)
Receiving message with 14 bytes of payload (expected >=14)
skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.57, revision (Y/M/D) = 13/10/24
Receiving message with 2 bytes of payload (expected >=2)
Receiving message with 2 bytes of payload (expected >=2)
Got ACK (id=0x17)
Receiving message with 41 bytes of payload (expected >=35)
#logging: tmin=5, tmax=65535, dmin=0, dmax=65535, vmin=0, vmax=65535
skytraq: Device status: free sectors: 449 / total sectors: 509 / 12% used / write ptr: 256108
skytraq: Reading log data from device...
skytraq: start=0 used=61
skytraq: opt_last_sector_val=-1
Reading 61 sectors beginning from #0...
Receiving message with 2 bytes of payload (expected >=2)
Receiving message with 2 bytes of payload (expected >=2)
Got ACK (id=0x1d)
Receiving data of sector #0...
Receiving data of sector #1...
Receiving data of sector #2...
Receiving data of sector #3...
Receiving data of sector #4...
Receiving data of sector #5...
Receiving data of sector #6...
Receiving data of sector #7...
Receiving data of sector #8...
Receiving data of sector #9...
Receiving data of sector #10...
Receiving data of sector #11...
Receiving data of sector #12...
Receiving data of sector #13...
Receiving data of sector #14...
Receiving data of sector #15...
Receiving data of sector #16...
Receiving data of sector #17...
Receiving data of sector #18...
Receiving data of sector #19...
Receiving data of sector #20...
Receiving data of sector #21...
Receiving data of sector #22...
Receiving data of sector #23...
Receiving data of sector #24...
Receiving data of sector #25...
Receiving data of sector #26...
Receiving data of sector #27...
Receiving data of sector #28...
Receiving data of sector #29...
Receiving data of sector #30...
Receiving data of sector #31...
Receiving data of sector #32...
Receiving data of sector #33...
Receiving data of sector #34...
Receiving data of sector #35...
Receiving data of sector #36...
Receiving data of sector #37...
Receiving data of sector #38...
Receiving data of sector #39...
Receiving data of sector #40...
Receiving data of sector #41...
Receiving data of sector #42...
Receiving data of sector #43...
Receiving data of sector #44...
Receiving data of sector #45...
Receiving data of sector #46...
Receiving data of sector #47...
Receiving data of sector #48...
Receiving data of sector #49...
Receiving data of sector #50...
Receiving data of sector #51...
Receiving data of sector #52...
Receiving data of sector #53...
Receiving data of sector #54...
Receiving data of sector #55...
Receiving data of sector #56...
Receiving data of sector #57...
Receiving data of sector #58...
Receiving data of sector #59...
Receiving data of sector #60...
Segmentation fault

[tsteven4]

Can you generate a core dump and post it somewhere? "rm core; ulimit -c unlimited, gpsbabel ...". If the source has been modifiedvfrom 1.6.0 we will need that as well.

…

On Mon, May 13, 2019, 12:54 AM Konrad Gräfe ***@***.***> wrote: When trying to download the GPS log from my minihomer, gpsbabel segfaults. I think the device has tracks from both before and after the week rollover, so that might cause the issue? ***@***.***:~# gpsbabel -D 3 -i miniHomer,initbaud=0 -f /dev/ttyUSB0 -o gpx -F /var/run/minimonty.gpx GPSBabel Version: 1.6.0 main: Compiled with Qt 5.10.1 for architecture arm-little_endian-ilp32-eabi-hardfloat main: Running with Qt 5.10.1 on Linux 4.14.68, arm main: QLocale::system() is C main: QLocale() is C main: QTextCodec::codecForLocale() is ISO-8859-1, mib 4 options: module/option=value: miniHomer/baud="115200" (=default) options: module/option=value: miniHomer/erase="0" (=default) options: module/option=value: miniHomer/first-sector="0" (=default) options: module/option=value: miniHomer/initbaud="0" options: module/option=value: miniHomer/last-sector="-1" (=default) options: module/option=value: miniHomer/no-output="0" (=default) options: module/option=value: miniHomer/read-at-once="255" (=default) skytraq: Probing SkyTraq Venus at 9600baud... skytraq: Didn't get message start tag Didn't receive ACK (-3), retrying... skytraq: Didn't get message start tag Didn't receive ACK (-3) skytraq: Probing SkyTraq Venus at 230400baud... skytraq: Didn't get message start tag Didn't receive ACK (-3), retrying... skytraq: Didn't get message start tag Didn't receive ACK (-3) skytraq: Probing SkyTraq Venus at 115200baud... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x02) Receiving message with 14 bytes of payload (expected >=14) skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.57, revision (Y/M/D) = 13/10/24 Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x17) Receiving message with 41 bytes of payload (expected >=35) #logging: tmin=5, tmax=65535, dmin=0, dmax=65535, vmin=0, vmax=65535 skytraq: Device status: free sectors: 449 / total sectors: 509 / 12% used / write ptr: 256108 skytraq: Reading log data from device... skytraq: start=0 used=61 skytraq: opt_last_sector_val=-1 Reading 61 sectors beginning from #0... Receiving message with 2 bytes of payload (expected >=2) Receiving message with 2 bytes of payload (expected >=2) Got ACK (id=0x1d) Receiving data of sector #0... Receiving data of sector #1... Receiving data of sector #2... Receiving data of sector #3... Receiving data of sector #4... Receiving data of sector #5... Receiving data of sector #6... Receiving data of sector #7... Receiving data of sector #8... Receiving data of sector #9... Receiving data of sector #10... Receiving data of sector #11... Receiving data of sector #12... Receiving data of sector #13... Receiving data of sector #14... Receiving data of sector #15... Receiving data of sector #16... Receiving data of sector #17... Receiving data of sector #18... Receiving data of sector #19... Receiving data of sector #20... Receiving data of sector #21... Receiving data of sector #22... Receiving data of sector #23... Receiving data of sector #24... Receiving data of sector #25... Receiving data of sector #26... Receiving data of sector #27... Receiving data of sector #28... Receiving data of sector #29... Receiving data of sector #30... Receiving data of sector #31... Receiving data of sector #32... Receiving data of sector #33... Receiving data of sector #34... Receiving data of sector #35... Receiving data of sector #36... Receiving data of sector #37... Receiving data of sector #38... Receiving data of sector #39... Receiving data of sector #40... Receiving data of sector #41... Receiving data of sector #42... Receiving data of sector #43... Receiving data of sector #44... Receiving data of sector #45... Receiving data of sector #46... Receiving data of sector #47... Receiving data of sector #48... Receiving data of sector #49... Receiving data of sector #50... Receiving data of sector #51... Receiving data of sector #52... Receiving data of sector #53... Receiving data of sector #54... Receiving data of sector #55... Receiving data of sector #56... Receiving data of sector #57... Receiving data of sector #58... Receiving data of sector #59... Receiving data of sector #60... Segmentation fault — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#351>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADHXMMMYH4SEVI3ZLZ7TMA3PVEGDDANCNFSM4HMM3I2A> .

[tsteven4]

And please build gpsbabel with -g instead if the usual -O2 before generating the core file.

…

On Mon, May 13, 2019, 6:39 AM tsteven four ***@***.***> wrote: Can you generate a core dump and post it somewhere? "rm core; ulimit -c unlimited, gpsbabel ...". If the source has been modifiedvfrom 1.6.0 we will need that as well. On Mon, May 13, 2019, 12:54 AM Konrad Gräfe ***@***.***> wrote: > When trying to download the GPS log from my minihomer, gpsbabel > segfaults. I think the device has tracks from both before and after the > week rollover, so that might cause the issue? > > ***@***.***:~# gpsbabel -D 3 -i miniHomer,initbaud=0 -f /dev/ttyUSB0 -o gpx -F /var/run/minimonty.gpx > GPSBabel Version: 1.6.0 > main: Compiled with Qt 5.10.1 for architecture arm-little_endian-ilp32-eabi-hardfloat > main: Running with Qt 5.10.1 on Linux 4.14.68, arm > main: QLocale::system() is C > main: QLocale() is C > main: QTextCodec::codecForLocale() is ISO-8859-1, mib 4 > options: module/option=value: miniHomer/baud="115200" (=default) > options: module/option=value: miniHomer/erase="0" (=default) > options: module/option=value: miniHomer/first-sector="0" (=default) > options: module/option=value: miniHomer/initbaud="0" > options: module/option=value: miniHomer/last-sector="-1" (=default) > options: module/option=value: miniHomer/no-output="0" (=default) > options: module/option=value: miniHomer/read-at-once="255" (=default) > skytraq: Probing SkyTraq Venus at 9600baud... > skytraq: Didn't get message start tag > Didn't receive ACK (-3), retrying... > skytraq: Didn't get message start tag > Didn't receive ACK (-3) > skytraq: Probing SkyTraq Venus at 230400baud... > skytraq: Didn't get message start tag > Didn't receive ACK (-3), retrying... > skytraq: Didn't get message start tag > Didn't receive ACK (-3) > skytraq: Probing SkyTraq Venus at 115200baud... > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > Got ACK (id=0x02) > Receiving message with 14 bytes of payload (expected >=14) > skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.57, revision (Y/M/D) = 13/10/24 > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > Got ACK (id=0x17) > Receiving message with 41 bytes of payload (expected >=35) > #logging: tmin=5, tmax=65535, dmin=0, dmax=65535, vmin=0, vmax=65535 > skytraq: Device status: free sectors: 449 / total sectors: 509 / 12% used / write ptr: 256108 > skytraq: Reading log data from device... > skytraq: start=0 used=61 > skytraq: opt_last_sector_val=-1 > Reading 61 sectors beginning from #0... > Receiving message with 2 bytes of payload (expected >=2) > Receiving message with 2 bytes of payload (expected >=2) > Got ACK (id=0x1d) > Receiving data of sector #0... > Receiving data of sector #1... > Receiving data of sector #2... > Receiving data of sector #3... > Receiving data of sector #4... > Receiving data of sector #5... > Receiving data of sector #6... > Receiving data of sector #7... > Receiving data of sector #8... > Receiving data of sector #9... > Receiving data of sector #10... > Receiving data of sector #11... > Receiving data of sector #12... > Receiving data of sector #13... > Receiving data of sector #14... > Receiving data of sector #15... > Receiving data of sector #16... > Receiving data of sector #17... > Receiving data of sector #18... > Receiving data of sector #19... > Receiving data of sector #20... > Receiving data of sector #21... > Receiving data of sector #22... > Receiving data of sector #23... > Receiving data of sector #24... > Receiving data of sector #25... > Receiving data of sector #26... > Receiving data of sector #27... > Receiving data of sector #28... > Receiving data of sector #29... > Receiving data of sector #30... > Receiving data of sector #31... > Receiving data of sector #32... > Receiving data of sector #33... > Receiving data of sector #34... > Receiving data of sector #35... > Receiving data of sector #36... > Receiving data of sector #37... > Receiving data of sector #38... > Receiving data of sector #39... > Receiving data of sector #40... > Receiving data of sector #41... > Receiving data of sector #42... > Receiving data of sector #43... > Receiving data of sector #44... > Receiving data of sector #45... > Receiving data of sector #46... > Receiving data of sector #47... > Receiving data of sector #48... > Receiving data of sector #49... > Receiving data of sector #50... > Receiving data of sector #51... > Receiving data of sector #52... > Receiving data of sector #53... > Receiving data of sector #54... > Receiving data of sector #55... > Receiving data of sector #56... > Receiving data of sector #57... > Receiving data of sector #58... > Receiving data of sector #59... > Receiving data of sector #60... > Segmentation fault > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#351>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/ADHXMMMYH4SEVI3ZLZ7TMA3PVEGDDANCNFSM4HMM3I2A> > . >

[tsteven4]

Lets try to get gpsbabel to dump the data first. Use dump-file option. We might need no-output option as well to get a complete dump depending on where the crash is. Then post the gpsbabel generated dump file.

…

On Mon, May 13, 2019, 6:43 AM tsteven four ***@***.***> wrote: And please build gpsbabel with -g instead if the usual -O2 before generating the core file. On Mon, May 13, 2019, 6:39 AM tsteven four ***@***.***> wrote: > Can you generate a core dump and post it somewhere? "rm core; ulimit -c > unlimited, gpsbabel ...". If the source has been modifiedvfrom 1.6.0 we > will need that as well. > > On Mon, May 13, 2019, 12:54 AM Konrad Gräfe ***@***.***> > wrote: > >> When trying to download the GPS log from my minihomer, gpsbabel >> segfaults. I think the device has tracks from both before and after the >> week rollover, so that might cause the issue? >> >> ***@***.***:~# gpsbabel -D 3 -i miniHomer,initbaud=0 -f /dev/ttyUSB0 -o gpx -F /var/run/minimonty.gpx >> GPSBabel Version: 1.6.0 >> main: Compiled with Qt 5.10.1 for architecture arm-little_endian-ilp32-eabi-hardfloat >> main: Running with Qt 5.10.1 on Linux 4.14.68, arm >> main: QLocale::system() is C >> main: QLocale() is C >> main: QTextCodec::codecForLocale() is ISO-8859-1, mib 4 >> options: module/option=value: miniHomer/baud="115200" (=default) >> options: module/option=value: miniHomer/erase="0" (=default) >> options: module/option=value: miniHomer/first-sector="0" (=default) >> options: module/option=value: miniHomer/initbaud="0" >> options: module/option=value: miniHomer/last-sector="-1" (=default) >> options: module/option=value: miniHomer/no-output="0" (=default) >> options: module/option=value: miniHomer/read-at-once="255" (=default) >> skytraq: Probing SkyTraq Venus at 9600baud... >> skytraq: Didn't get message start tag >> Didn't receive ACK (-3), retrying... >> skytraq: Didn't get message start tag >> Didn't receive ACK (-3) >> skytraq: Probing SkyTraq Venus at 230400baud... >> skytraq: Didn't get message start tag >> Didn't receive ACK (-3), retrying... >> skytraq: Didn't get message start tag >> Didn't receive ACK (-3) >> skytraq: Probing SkyTraq Venus at 115200baud... >> Receiving message with 2 bytes of payload (expected >=2) >> Receiving message with 2 bytes of payload (expected >=2) >> Got ACK (id=0x02) >> Receiving message with 14 bytes of payload (expected >=14) >> skytraq: Venus device found: Kernel version = 1.4.42, ODM version = 1.4.57, revision (Y/M/D) = 13/10/24 >> Receiving message with 2 bytes of payload (expected >=2) >> Receiving message with 2 bytes of payload (expected >=2) >> Got ACK (id=0x17) >> Receiving message with 41 bytes of payload (expected >=35) >> #logging: tmin=5, tmax=65535, dmin=0, dmax=65535, vmin=0, vmax=65535 >> skytraq: Device status: free sectors: 449 / total sectors: 509 / 12% used / write ptr: 256108 >> skytraq: Reading log data from device... >> skytraq: start=0 used=61 >> skytraq: opt_last_sector_val=-1 >> Reading 61 sectors beginning from #0... >> Receiving message with 2 bytes of payload (expected >=2) >> Receiving message with 2 bytes of payload (expected >=2) >> Got ACK (id=0x1d) >> Receiving data of sector #0... >> Receiving data of sector #1... >> Receiving data of sector #2... >> Receiving data of sector #3... >> Receiving data of sector #4... >> Receiving data of sector #5... >> Receiving data of sector #6... >> Receiving data of sector #7... >> Receiving data of sector #8... >> Receiving data of sector #9... >> Receiving data of sector #10... >> Receiving data of sector #11... >> Receiving data of sector #12... >> Receiving data of sector #13... >> Receiving data of sector #14... >> Receiving data of sector #15... >> Receiving data of sector #16... >> Receiving data of sector #17... >> Receiving data of sector #18... >> Receiving data of sector #19... >> Receiving data of sector #20... >> Receiving data of sector #21... >> Receiving data of sector #22... >> Receiving data of sector #23... >> Receiving data of sector #24... >> Receiving data of sector #25... >> Receiving data of sector #26... >> Receiving data of sector #27... >> Receiving data of sector #28... >> Receiving data of sector #29... >> Receiving data of sector #30... >> Receiving data of sector #31... >> Receiving data of sector #32... >> Receiving data of sector #33... >> Receiving data of sector #34... >> Receiving data of sector #35... >> Receiving data of sector #36... >> Receiving data of sector #37... >> Receiving data of sector #38... >> Receiving data of sector #39... >> Receiving data of sector #40... >> Receiving data of sector #41... >> Receiving data of sector #42... >> Receiving data of sector #43... >> Receiving data of sector #44... >> Receiving data of sector #45... >> Receiving data of sector #46... >> Receiving data of sector #47... >> Receiving data of sector #48... >> Receiving data of sector #49... >> Receiving data of sector #50... >> Receiving data of sector #51... >> Receiving data of sector #52... >> Receiving data of sector #53... >> Receiving data of sector #54... >> Receiving data of sector #55... >> Receiving data of sector #56... >> Receiving data of sector #57... >> Receiving data of sector #58... >> Receiving data of sector #59... >> Receiving data of sector #60... >> Segmentation fault >> >> — >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub >> <#351>, or mute the thread >> <https://github.com/notifications/unsubscribe-auth/ADHXMMMYH4SEVI3ZLZ7TMA3PVEGDDANCNFSM4HMM3I2A> >> . >> >

[kgraefe]

I found it: opt_gps_utc_offset and opt_gps_week_rollover have not been initialized properly when using the miniHomer driver. And apparently atoi(NULL) is undefined and behaves differently on ARM (Segmentation fault) than on x86_64 (returns 0).

[robertlipe]

"On ARM" was certainly a nuance I didn't notice the first time and would have been difficult for most of us to repro. atoi() is generally not very smart. std::stoi, strtol, or QString::number generally have fewer hazards. Where was the call site? Oh. Was it opt_gps_week_rollover ? If so, it's a null because that option isn't repeated in the miniHomer from the skytraq block. Ditto for utc-offset, I suppose. It's probably worth a bugreport to your OSV if the x86 and ARM versions act differently (yes, I know what "undefined" means) but if you can work out a copy-paste solution with those hints, please do turn it into a pull request for us.

…

On Mon, May 13, 2019 at 5:27 PM Konrad Gräfe ***@***.***> wrote: I think I found it: apparently atoi(NULL) is undefined and behaves differently on ARM (Segmentation fault) than on x86_64 (returns 0). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#351>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACCSD3667TBF7LXYWB5CZMDPVHTORANCNFSM4HMM3I2A> .

[kgraefe]

TBH, "on ARM" isn't very accurate here. The "x86_64" system is an Ubuntu 18.04 LTS where the "ARM" system is running an embedded distro (Yocto Sumo).... So on a second thought I guess it's more likely caused by a version of libc optimized for size or something.