[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gpsd-dev
Subject:    [Gpsd-dev] Paranoia pays
From:       gpsd-dev () lists ! berlios ! de (Eric S !  Raymond)
Date:       2006-06-11 23:16:27
Message-ID: 20060611231627.GB32009 () thyrsus ! com
[Download RAW message or body]

Gary E. Miller <gem@rellim.com>:
> send(6, "+/dev/pts/25\r\n", 14, 0)      = 14
> recv(6,
>  
> Not sure what bringing up the gdb would tell us.  Especially since
> Pythin is not my thing.  It is clear that gpsfake is hung in recv().
> Is there anythine more you can add to the '-v' in gpsfake to shed some
> light?  At a minimum a timeout on the recv() would be nice.
> 
> Looks like the normal gpsd and the gpsd for gpsfake are running fine:
> 
> gpsd/trunk# pstree -paul | fgrep gps
>   |  |       |-fgrep,2061 gps
>   |  |       `-strace,2049 gpsfake -b -v -p bu303-climbing.log
>   |  |           `-python,2050 /usr/bin/gpsfake -b -v -p bu303-climbing.log
>   |-gpsd,2052 -N -S 12000 -F /tmp/gpsfake-2050.sock -P /tmp/gpsfake_pid-2050
>   |-gpsd,1351,nobody -n /dev/ttyUSB0

Python doesn't have to be your thing.  This failure appears to be at C level
inside gpsd.  Python is involved only as the language the test framework
is implemented in.

The reason I suggested the -g option of gpsfake is because that will start a 
gpsd instance running under gdb control.  If you set a break on the 
control-message handler, and then tell gdb to continue the gpsd, it
should stop at the beginning of the control-message handler as it receives
its device-registration command. 

You should then be able to step forward until you find where gpsd is hanging.
It will be somewhere before the response gets shipped back to gsfake's recv()
call.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

[prev in list] [next in list] [prev in thread] [next in thread]