[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] Segmentation fault on Qualcomm MDM9615
From: |
Jordi Augé |
Subject: |
Re: [gpsd-users] Segmentation fault on Qualcomm MDM9615 |
Date: |
Tue, 20 Sep 2016 11:45:13 +0200 (CEST) |
Hi guys,
Sorry to bump my own thread, but I'm still stuck on this mysterious
insanely-speedy, buffer-filling serial port issue.
Can anyone share some thoughts on this, so I can do some research on possible
causes?
Thanks,
Jordi
----- Original Message -----
From: "jordi" <address@hidden>
To: "gpsd-users" <address@hidden>
Sent: Friday, September 2, 2016 5:12:42 PM
Subject: Re: [gpsd-users] Segmentation fault on Qualcomm MDM9615
Hello,
I've compiled gpsd from git, and the problem still reproduces. All tests here
were done against the git version.
Here is a log with strace, as suggested by Tom:
- http://pastebin.com/nSArCT74
It seems to crash on a read, which would be consistent with a buffer
overflowing.
A little information about the build environment, as requested by Gary:
- My system is a rather uninteresting Ubuntu 16.04, 64-bit. Kernel
4.4.0-36-generic
- I'm using the compiler and toolchain provided by the board manufacturer, with
gcc version 4.7.2 (GCC)
- Build command is: scons
prefix='/opt/swi/y16-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr'
target='/opt/swi/y16-ext/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi'
sysroot='/opt/swi/y16-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi'
bluez=False dbus_export=False libgpsmm=False ncurses=False python=False
qt=False systemd=False usb=False
I tried capturing data from the nmea port and then using gpsfake to reproduce
the error as suggested by Eric, and it just happens to work fine with the dump.
I was even able to get a proper fix after doing "cat /dev/nmea > nmea_log",
letting the command run for some time and then running the file against gpsfake.
However, running gpsd directly against /dev/nmea crashes. So, there definitely
is something fishy about the /dev/nmea port. Let's find out a little more about
it:
kai:~# ls -lah /dev/nmea
crw-rw-rw- 1 root root 10, 58 Jan 1 1970 /dev/nmea
- So it looks like a real device, with a major and minor IDs
kai:~# ps auxf | grep -i nmea
root 22 0.0 0.0 0 0 ? S< 00:20 0:00 \_ [nmea]
- There is a kernel thread named nmea
kai:~# ls -lah /proc/*/fd | grep nmea
kai:~#
- No other application is using the device
I'm not really sure what can be going on with the port, or where to go from
here.