Re: [gpsd-dev] ✘GPSD_API

[Fred Wright]

On Thu, 14 Apr 2016, Gary E. Miller wrote:
> On Thu, 14 Apr 2016 15:52:27 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > > My use case is 'scons check' which uses shmget().  The SHM that
> > > scons check uses is not the same SHM that NTP uses.
> >
> > In that case you might have to resort to strace. :-)
>
> Which sadly does not tell me where the bad code is.  I suspect it is in
> Python somewhere.

Seems unlikely.

> To save me reading Python which I am nto good at, can you tell me the
> order that regress-driver starts binaries during a test?

The only thing regress-driver does is run gpsfake and filter and compare
the output.  If you're at the regress-driver level, you're probably
already doing:

        ./regress-driver <some logfile>

The code at regress-driver:132 runs the actual gpsfake command; a
simplified version of that is:

        GPSD_HOME=. ./gpsfake -1 -p <logfile>

Note that without redirection, all the output goes to the terminal, but
your case is probably dying quickly enough for that not to matter.

The code that actually runs the daemon is at gps/fake.py:484; you could
patch in

        print(self.spawncmd)

just before that to see exactly what command it's using.  Or break there
in pdb, if you know how to use pdb.

AFAIK, no "binary" other than gpsd itself is run for the test, and the
Python code has no knowledge of SHM at all.  The regress-driver shell
script (line 43) has:

        export GPSD_SHM_KEY=0x47505345

That's to avoid conflicting with a running gpsd, but otherwise it knows
nothing about SHM.

Is it possible that gpsd is getting confused between the standard SHM key
value and the value from the environment?

Fred Wright