[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.
- [gpsd-dev] Last known 3.12 blocker solved, Eric S. Raymond, 2015/02/14
- Re: [gpsd-dev] Last known 3.12 blocker solved, Hal Murray, 2015/02/14
- Re: [gpsd-dev] Last known 3.12 blocker solved, Eric S. Raymond, 2015/02/14
- Re: [gpsd-dev] Last known 3.12 blocker solved,
Hal Murray <=
- Re: [gpsd-dev] Last known 3.12 blocker solved, Eric S. Raymond, 2015/02/15
- Re: [gpsd-dev] Last known 3.12 blocker solved, Hal Murray, 2015/02/15
- Re: [gpsd-dev] Last known 3.12 blocker solved, Eric S. Raymond, 2015/02/15
- Re: [gpsd-dev] Last known 3.12 blocker solved, Hal Murray, 2015/02/15
- Re: [gpsd-dev] Last known 3.12 blocker solved, Eric S. Raymond, 2015/02/16
- Re: [gpsd-dev] Last known 3.12 blocker solved, Gary E. Miller, 2015/02/16
- Re: [gpsd-dev] Last known 3.12 blocker solved, Hal Murray, 2015/02/15
- Re: [gpsd-dev] Last known 3.12 blocker solved, Eric S. Raymond, 2015/02/15
- Re: [gpsd-dev] Last known 3.12 blocker solved, Gary E. Miller, 2015/02/16
- Re: [gpsd-dev] Last known 3.12 blocker solved, Hal Murray, 2015/02/15