gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Last known 3.12 blocker solved


From: Hal Murray
Subject: Re: [gpsd-dev] Last known 3.12 blocker solved
Date: Sat, 14 Feb 2015 21:00:10 -0800

> Bug not reproducing for me.  Maybe you have something stale in a ~/bin
> directory? 

Let me start over.  There is something(s) I don't understand going on in the 
SHM area.

I'm assuming the following sequence should do the right thing:
  git clone/pull
  scons
  scons check
  scons install
and that it should work with or without an old or current version of gpsd 
already being installed and/or running.


Part of the problem is that I was forgetting to add "chrpath=yes" when I ran 
scons.  Apologies for all the noise and wild geese.  (I was trying to avoid 
wild geese by making sure I was using a clean test environment.  My working 
directory has that in a script so I don't forget.)

You might look into fixing chrpath to default to yes if chrpath is installed 
and/or giving a loud warning if scons check will be run against a non-local 
library.

There was a some discussion of this area a while ago.  I thought the 
non-chrpath mode was that "scons" linked with the local libraries and "scons 
install" relinked with the to-be installed libraries.  Mumble.  Maybe I'll 
remove chrpath from a system so somebody tests that case.


Starting over...

Starting with no gpsd and empty SHM, scons check leaves:
key        shmid      owner      perms      bytes      nattch     status      
0x4e545032 778436608  murray     666        80         0                      

0x4e545033 778469377  murray     666        80         0                      

0x4e545034 778502146  murray     666        80         0                      

0x4e545035 778534915  murray     666        80         0                      

0x4e545036 778567684  murray     666        80         0                      

0x4e545037 778600453  murray     666        80         0                      

0x47505344 778633222  murray     666        8060       0                      

Is that what you expect?
Note that xxx0 and xxx1 are missing and that it's using 0x47505344 (not xxx5).

./regress-driver test/daemon/tcp-test.log
works and doesn't add anything to SHM

GPSD_SHM_KEY=0x47505345 ./regress-driver test/daemon/tcp-test.log
adds an un-keyed chunk of SHM:
...
0x47505344 778633222  murray     666        8060       0                      

0x00000000 778665991  murray     666        8060       0                      


It adds a segment for each test:
GPSD_SHM_KEY=0x47505345 ./regress-driver test/daemon/tcp-test.log 
test/daemon/tcp-test.log test/daemon/tcp-test.log
...
0x47505344 778633222  murray     666        8060       0                      

0x00000000 778665991  murray     666        8060       0                      

0x00000000 778698760  murray     666        8060       0                      

0x00000000 778731529  murray     666        8060       0                      

0x00000000 778764298  murray     666        8060       0                      


Starting over with an empty SHM.
GPSD_SHM_KEY=0x47505345 ./regress-driver test/daemon/tcp-test.log 
test/daemon/tcp-test.log test/daemon/tcp-test.log
leaves:
key        shmid      owner      perms      bytes      nattch     status      
0x4e545032 779255808  murray     666        80         0                      

0x4e545033 779288577  murray     666        80         0                      

0x4e545034 779321346  murray     666        80         0                      

0x4e545035 779354115  murray     666        80         0                      

0x4e545036 779386884  murray     666        80         0                      

0x4e545037 779419653  murray     666        80         0                      

0x00000000 779452422  murray     666        8060       0                      

0x00000000 779485191  murray     666        8060       0                      

0x00000000 779517960  murray     666        8060       0                      

(Note no 0x47505344)


After cleaning up SHM and starting gpsd 3.11:
key        shmid      owner      perms      bytes      nattch     status      
0x4e545030 778862592  root       600        80         1                      

0x4e545031 778895361  root       600        80         1                      

0x4e545032 778928130  root       666        80         1                      

0x4e545033 778960899  root       666        80         1                      

0x47505344 778993668  root       666        31532      1                      


After scons check (no errors)
key        shmid      owner      perms      bytes      nattch     status      
0x4e545030 778862592  root       600        80         1                      

0x4e545031 778895361  root       600        80         1                      

0x4e545032 778928130  root       666        80         1                      

0x4e545033 778960899  root       666        80         1                      

0x47505344 778993668  root       666        31532      1                      

0x4e545034 779026437  murray     666        80         0                      

0x4e545035 779059206  murray     666        80         0                      

0x4e545036 779091975  murray     666        80         0                      

0x4e545037 779124744  murray     666        80         0                      


After:
GPSD_SHM_KEY=0x47505345 ./regress-driver test/daemon/tcp-test.log 
test/daemon/tcp-test.log test/daemon/tcp-test.log
key        shmid      owner      perms      bytes      nattch     status      
0x4e545030 778862592  root       600        80         1                      

0x4e545031 778895361  root       600        80         1                      

0x4e545032 778928130  root       666        80         1                      

0x4e545033 778960899  root       666        80         1                      

0x47505344 778993668  root       666        31532      1                      

0x4e545034 779026437  murray     666        80         0                      

0x4e545035 779059206  murray     666        80         0                      

0x4e545036 779091975  murray     666        80         0                      

0x4e545037 779124744  murray     666        80         0                      

0x00000000 779157513  murray     666        8060       0                      

0x00000000 779190282  murray     666        8060       0                      

0x00000000 779223051  murray     666        8060       0                      



Cleaning up SHM and switching to:
gpsd: 3.12~dev (revision 2015-02-03T01:41:22.55)
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x4e545030 779550720  root       600        80         1                      

0x4e545031 779583489  root       600        80         1                      

0x4e545032 779616258  root       666        80         1                      

0x4e545033 779649027  root       666        80         1                      

0x4e545034 779681796  root       666        80         1                      

0x4e545035 779714565  root       666        80         1                      

0x4e545036 779747334  root       666        80         1                      

0x4e545037 779780103  root       666        80         1                      

0x47505344 779812872  root       666        7388       1                      


./regress-driver test/daemon/tcp-test.log says:
Testing the daemon...
Processing test/daemon/tcp-test.log
gpsd:ERROR: shmget(1196446532, 8060, 0666) failed: Invalid argument
gpsd:ERROR: shared-segment creation failed,
Regression test successful: no errors in 1 tests (0 not found).
(Note that didn't get counted as an error.)

I'll leave that running on tom so you can try it.

My Linux man page for shmget says under errors:
       EINVAL A new segment was to be created and size < SHMMIN or size > SHM-
              MAX, or no new segment was to be created, a segment  with  given
              key  existed, but size is greater than the size of that segment.
I think that explains why it worked with 3.11 but not a 2 week old 3.12-dev.  
The fundamental problem is that it's using the wrong key.  The shmget error 
is just a symptom that goes off in the right environment.

GPSD_SHM_KEY=0x47505345 ./regress-driver test/daemon/tcp-test.log
works and leaves an un-keyed segment like above.
...
0x47505344 779812872  root       666        7388       1                      

0x00000000 779845641  murray     666        8060       0                      



How many bugs/quirks are in this tangle?

  why is scons check using a SMH key of 0x47505344

  should scons check be deleting SHM segments?

  why is a manual test leaving un-keyed segments?

  "shared-segment creation failed" doesn't get counted as an error.

There is an additional problem of a test run stomping on SHM used by 
production gpsd/ntpd.  Does the test mode actually do anything with those SHM 
segments?  Does the data from the test stream get written there, possibly 
feeding bogus data to ntpd?  (it only polls once a second)


-- 
These are my opinions.  I hate spam.






reply via email to

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