Re: [gpsd-dev] What is our current bug state?

[Frank Nicholas]

I just did another test on my Mac Pro, OS X 10.10, (2 x 6-core Xeon X5680)

http://ark.intel.com/products/47916/Intel-Xeon-Processor-X5680-12M-Cache-3_33-GHz-6_40-GTs-Intel-QPI?q=X5680

I left the pad & delay as “shipped” of .03 & 1.  It passed:

Regression test successful: no errors in 89 tests (0 not found).

-n Elapsed time: 

1206

I noticed this:

Processing test/daemon/tcp-test.log

gpsfake: socket error [Errno 57] Socket is not connected.

Processing test/daemon/tcp-torture.log

gpsfake: socket error [Errno 57] Socket is not connected.

This was also present in the run on my MacBook Pro, I just didn’t notice.  Is this the case where it tries to allocate a port not in use, and “collides”?

And as expected, with the PAD & DELAY set to zero (0), the test fail.

On Feb 2, 2015, at 2:15 PM, Frank Nicholas <address@hidden> wrote:

On Feb 2, 2015, at 12:35 PM, Eric S. Raymond <address@hidden> wrote:

Please test head with WRITE_PAD and CLOSE_DELAY zeroed.  It looks
now as though O_NONBLOCK may have been the culprit behind that problem too.

Current behavior is to open with O_NOBLOCK, set CLOCAL, then use fcntl to
clear O_NONBLOCK.  This seems to work fine even if no VTIME is set!

Mac OS X, 10.10 (Yosemite), MacBook Pro, Intel Core i7-4850HQ (quad core, w/hyper-threading)

http://ark.intel.com/products/76086/Intel-Core-i7-4850HQ-Processor-6M-Cache-up-to-3_50-GHz?q=4850HQ

I did a ‘git pull’.  I’m not sure how to see what revision it was, but the latest commit was “ef39b1cd848a006751b1d30c931056a5790e3116”.

I zeroed out the WRITE_PAD & CLOSE_DELAY, and had mostly failure:

Regression test FAILED: 87 errors in 89 tests total (0 not found).

-n Elapsed time: 

107

I set the WRITE_PAD & CLOSE_DELAY back to how they were (.03 & 1) for OS X, and it passed:

Regression test successful: no errors in 89 tests (0 not found).

-n Elapsed time: 

1200

In the failed tests, it appears the the input file being tested was spit out in the terminal window.  Is that intentional if a test fails, or is it a byproduct of a failed test?

Any additional information you would like?  Any other testing you want performed?  The Apple developer tools allow me to turn off cores on the fly, if we think this might be related to SMP.

Thanks,

Frank