This page used to be part of the to-do list in our source distribution, until we realized it would be useful for the rest of the Web to see these bug reports. Where we can identify a responsible maintainer, we've tried to kick these upstream.

Links to Open User-Visible Problems

Links to Open Toolchain Bugs

Links to Fixed Bugs

Open User-Visible Problems

Firmware problems in some Bluetooth devices can hang them

The baudrate-hunting code in gpsd tickles a serious firmware bug on some some Bluetooth devices, notably those shipped by Holux and including the GPSlim-236. This bug may render these GPSes catatonic. The problem seems to be that buggy firmware inside these receivers doesn't necessarily keep the Bluetooth serial-port emulation and the GPS chip talking at the same baud rate. This problem is not unique to gpsd - windows users are warned against using SiRFdemo's "Synchronize Protocol/Baud Rate" option on bluetooth devices.

If this happens, you can sometimes recover by repeatedly sending reset messages using gpsctl

. The only guaranteed fix is to open the case and unsolder the backup battery so the chip forgets its configuration settings.

Use the -b option of gpsd to prevent it from trying to reconfigure your GPS; this will avoid the bug.

Linux pl2303 driver on openwrt 2.4 kernel can hang when device is read at unexpected speed

Michael R. Davis reports "If you read from the device at the wrong rate (e.g. cat /dev/xxx) it will lock up. On openwrt it required a hard reboot." Details here. This bug was reported in 2006 with an old kernel version and may since have been fixed.

pthread_create() fails to return when called in background

There is a call to pthread create in libgpsd_core.c::link_activate(): /*@i1@*/(void)pthread_create(&pt,NULL,gpsd_ppsmonitor,(void *)session);

If this is called when gpsd is in the foreground then the thread is created fine and pthread_create() returns right away. If this is called when gpsd is in the background then the thread is created fine, but it may return! That freezes the main loop of gpsd. There is a workaround, but the nature of the workaround only makes ther bug more mysterious.

Open Toolchain Bugs

gpsd is distressingly good at tickling bugs in development toolchains. Most of these, thankfully, are non-issues if you keep your toolchain up to date.

Multiple definitions of symbol _gpsd_report due to libtool bug

Some people building gpsd get 'multiple definitions of symbol _gpsd_report' as a warning. This seems to be a result of two bugs in libtool, one of which masks the other on i386. gpsd_report() is indeed multiply defined, the problem is that libtool generates libgps.o where it should generate -lgps and all instances (rather than just the first to be incorporated by other linkage demands) are linked in.

Mac OS 10.5 X library packaging problem

Building xgpsspeed will fail under MacOS 10.5.6 because the X SDK libraries and include files are not installed to the canonical places. The workaround is to configure like this:

configure \
    --x-includes=/Developer/SDKs/MacOSX10.5.sdk/usr/X11R6/include \
    --x-libraries=/Developer/SDKs/MacOSX10.5.sdk/usr/X11R6/lib

We haven't attempted to embed this in our autotools build because it looks like the fix would have to change every time the OS version number is incremented.

Defective Python installation in SuSE 10.3rc

The Python 2.5 installed with SuSE 10.3rc is missing a needed Makefile. This prevents the gpsd Python components from building correctly.

Fixed Problems

We document these here in case you're running on an older system. They will be removed as they bwcome sufficiently ancient.

Distro-dependent problems with gpsd startup

See this Gentoo bug. This shows up on other distributions as well, but not under Fedora Core. The Gentoo problem can be fixed by creating a /var/run/usb directory; this fix may apply to other distributions as well.

Buggy pl2303 drivers on Maxc OS X can make select(2) look broken

When the fd set being polled includes tty devices (as opposed to sockets), select(2) can return 0 and shows no fd with input waiting even when data is in fact ready to be read from some of the devices.

The most recent incarnation of this problem was due to a buggy pl2303 USB-to-serial driver. OS X users should ensure that all their drivers are up to date. As of January 2009, this is still a problem - the most recent report being a failure of the drivers from osx-pl2303.sourceforge.net on OS X 10.5.6. Please try the latest drivers from www.prolific.com.tw before reporting hangs on OS X.

The 2.3.0-beta version of OpenMotif shipped with Fedora Core 5 was buggy.

xgps tickles a bug, described at http://bugs.motifzone.net/ as bugs 1330 and 1331 and marked FIXED, in some versions of OpenMotif. The symptom is that the satellite-data window in xgps is too small. Avoid by either upgrading to 2.3.0-0.1.9.3 (or later) or dropping back to a stable version like 2.2.2. Alternatively, remove OpenMotif and install lesstif. For gpsd's purposes, lesstif is a completely compatible drop-in replacement.

Python socket library barfs on IPV6 notation in the /etc/hosts file

Robert J.Berger reports: Until I changed the line in /etc/hosts from:

::1    localhost.localdomain   localhost
to:
127.0.0.1       localhost.localdomain   localhost

gps.py would fail when trying to open the socket connection to the gpsd:

   File "/usr/local/bin/spGps.py", line 198, in __init__
     self.connect(host, port)
   File "/usr/local/bin/spGps.py", line 237, in connect
     raise socket.error, msg
socket.error: (111, 'Connection refused')

and gpsprof would fail with:

# gpsprof | gnuplot -persist
gpsprof: gpsd unreachable.

This is with Python 2.4.4 under Red Hat Linux, kernel version 2.6.18. This was filed upstream as Python bug 1603527 on trheir old tracker, and is no longer open on their new one.

isgps.c triggers an optimizer bug in older gcc versions

The isgps.c file confuses the gcc-3.4.[23] optimizer at -O2 level, making it generate incorrect code. Removing -O2 from the compilation flags works around the problem. Details are in the isgps.c source file.

Compiling with --enable-max-devices=1 may trigger a gcc optimizer bug

At gpsd revision level 3365, compiling with --enable-max-devices=1 has been observed to trigger an optimizer bug in gcc 4.1.0 20060304 (Red Hat 4.1.0-3). The symptom is a for-loop termination condition not causing an exit, leading to a core dump. Removing -O2 from the compilation flags works around the problem; upgrading to gcc 4.1.1 20060525 (Red Hat 4.1.1-1) solves it. Other reports indicate this bug was introduced sometime after gcc 4.0.2 20051125 (Red Hat 4.0.2-8).

gpsd build may break on 64-bit systems running Fedora Core 5

The problem may be be caused by the old ld (binutils-2.15.92.0.2-18) being incompatible with gcc 4.1.0 on a 64-bit system. Updating to binutils 2.16.1 or later avoids it.

Incorrect generation of floating-point code in embedded toolchains

One problem area is errors in generation of floating-point code. A number of trouble reports have been received indicating erroneous results on embedded platforms, most notably ARM systems. These have all been traced back to the toolchain; when appropriate corrective action was taken, gpsd functioned correctly. Source code for a simple test program (floattest.c) is in the Subversion repository; if gpsd seems to be producing incorrect output, please use this tool to validate your toolchain before filing a bug report.

 

Search for GPS-related information here:
Google
 
Web gpsd.berlios.de