Re: [gpsd-users] Shared memory interface with gpsd restart results in no data for client

[Michael Lum]

For anyone interested I verified the following problems:

(I'm using C++)

 

1.  the static tick in shmexport.c does not work if gpsd is restarted (at least with a client attached to the shared memory)

 

I fixed this in my code by removing the static int tick and adding it to the shared memory segment and

having shm_update() using the value to set the bookends.

 

struct shmexport_t
{
    int tick;
    int bookend1;
    struct gps_data_t gpsdata;
    int bookend2;
};

shared->bookend2 = shared->tick++;

 

When the shared memory segment is created tick will be 0.

When gpsd restarts it will continue with the 'correct' tick value by using the one from

the existing shared memory segment.

 

2.  wrap around does not work (needs some more conditions in gps_shm_waiting())

 

This was my fix in gps_shm_waiting():

 

        if ((bookend1 == bookend2) &&
            ((bookend1 > PRIVATE(gpsdata)->tick) ||
                ((bookend1 < 0) && (PRIVATE(gpsdata)->tick >= 0))))
            newdata = true;

It assumes that if bookend1 is negative and the (private/client) tick is non-negative then

a wrap must have occurred.

 

3.  the 'tick' member needs to be zeroed after the malloc() call

 

My client code would cause gpsmm to go out of scope in the case of a gps_read()

error and then another one gets allocated and I restart my wait/read loop.

 

Occasionally after a gps_read() error the 'tick' value would be non-zero after the malloc().

 

=============================

 

In addition, I believe the memory malloc() for the privdata should be free'd in

gps_shm_close().  (Also for Dbus?)

 

I hope this helps someone else.

 

Thanks for help by Gary Miller.

---

From: gpsd-users [mailto:address@hidden On Behalf Of Michael Lum
Sent: June-14-18 11:47 AM
To: address@hidden
Subject: [gpsd-users] Shared memory interface with gpsd restart results in no data for client

Hi,

 

I'm using the source from gpsd 3.17 on CentOS 7, Ublox NEO 7 GPS receiver, shared memory interface.

 

If I send a SIGSEGV to the gpsd or just do a quick stop/start my client program does not "see" any data

for a long time.

 

The shared memory segment is the old one because the client is still attached.

 

Code executing in gpsd:

 

shmexport.c

 

'tick' that goes into the bookends is a static (initialized to zero, correct?).

Incremented immediately and used in the bookends.

So everytime gpsd starts the tick value in the bookend will start at '1'.

 

Code executing in client:

 

libgps_shm.c

 

gps_shm_open() uses malloc() to allocate memory for privdata_t.

This contains the pointer to the shared memory segment and a

 

int tick

 

member. 

(Shouldn't 'tick' have been zeroed?)

 

gps_shm_waiting() checks that the bookend1 value is greater than the 'tick' in the privdata.

　

But the privdata->tick could be very large depending on how long the original gpsd instance was running.

 

 

In addition I believe there will be a wrap around problem when the bookend1 value wraps to a negative.

 

 

Best regards,

 

Michael Lum

 

Michael Lum (address@hidden) | STAR SOLUTIONS | Principal Software Engineer

4600 Jacombs Road, Richmond BC, Canada V6V 3B1 | +1.604.303.2315