On Fri, 9 Oct 2009 09:26:27 +1100 (EST), Nathan Scott wrote:
nscott> Are there any of these that you think are critical for 3.0 Max?
I'd argue all of 'em or none:
* Increase table sizes for dbpmda's lexer
3.0.0 will simply not build on Solaris.
* Explicitly mark bitfield sign in pmUnits.
making pmUnits looks like seconds ^ 15 instead of 1/seconds unless
compiled with GCC.
* Treat UDP overflows as counter
Solaris only and fixes my botch.
* Deal with default lex on Solaris
make lexers actually work on Solaris - dbpmda gets its prompt back
* Don't change pointer types of pmCtime's arguments
is all platforms but Solaris is affected more because it causes
core dumps on Solaris (see below)
nscott> We have run a fair bit of QA on the current bits & deployed them
nscott> to quite a few test machines here, so unless there is something
nscott> pressing hiding in here, I'm thinking we should off for a 3.0.1
nscott> for these... is that OK?
As long as yerall understand that it means that 3.0.0 does not support
Solaris.
>> Don't change pointer types of pmCtime's arguments
nscott> This one has me nervous... was that observed on 64 bit Linux?
The code in tz.c is different between Solaris and Linux: on Solaris it
calls localtime which returns struct tm with year waaaaay up in the
future and that breaks asctime, on Linux asctime_r can deal with
future, so instead of core dump you get year 9057 from pmloglabel:
bozo:~/src/misc$ pmloglabel -l ~/tmp/eek
Log Label (Log Format Version 2)
Performance metrics from host sonya
commencing Wed Aug 26 19:32:02.665 9057
ending Mon Sep 21 19:32:50.674 2009
bozo:~/src/misc$ uname -a
Linux bozo 2.6.27-7-server #1 SMP Fri Oct 24 07:20:47 UTC 2008 x86_64 GNU/Linux
nscott> And isn't it going to introduce new compiler warnings (maybe
nscott> copying to interim variables of the right pointer type would
nscott> make this all safer?)
No new warnings - I've actually compiled this on Linux: in most cases
pmCtime gets the right pointer, either from struct timeval or from the
local variable of type time_t, the only place which was passing wrong
one was in pmloglabel which I've changed to use local stack variable
and just removed the cast - whoever added those casts in the first
place assumed that time will forever remain 32 bit integer.
max
|