gpsd-users
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]