On August 28, 2002 09:23 am, Tom Lane wrote:
> The behavior looks a lot like a memory clobber, so perhaps the key
> variable is some difference in malloc's allocation strategy, causing
> two items to be adjacent in NetBSD where they are not on the other
> platforms we've tried.
Here's some other wackiness. The following is various encrypted passwords
split for convenience of analyzing them along with the hex version of the big
number in the error. The OK ones were ones that didn't trigger the error.
The first line following that is the last byte in the number in hex and
binary. The next is the first character of the second chunk of the password. Note how the integer basically is the 4
bytesof the second chunk except for
the first byte which differs in a somewhat regular way. Looks like some sort
of bit mask operation somewhere.
wvx8 42kQ 34jyY (OK)
0x34 00110100
Q/Jz mdRb HSwE. 0x62526471
0x71 01110001
0x6d 01101101
ccIx mriB VsviU 0x42697271
0x71 01110001
0x6d 01101101
wsnr TAub uIelw 0x62754158
0x58 01011000
0x54 01010100
tGep W3d5 EX5pU 0x3564335b
0x5b 01011011
0x57 01010111
gJTk uYzh fb3LM 0x687a5979
0x79 01111001
0x75 01110101
EfFt qWDL RgVjY 0x4c445775
0x75 01110101
0x71 01110001
My2J GCTv 8A3GI 0x7654434b
0x4b 01001011
0x47 01000111
uWPk 7xcQ ZpTi. 0x5163783b
0x3b 00111011
0x37 00110111
AlD5 naNP oDKdc (OK)
0x6e 01101110
>
> I eyeballed the chkpass code and didn't see any sign of buffer overruns,
> but maybe it needs a harder look.
Hmm. I did give it a harder look and look what jumped out. Both chkpass_out
and chkpass_rout return PG_RETURN_CSTRING but chkpass_out builds a standard c
string while chkpass_rout builds a variable text structure. That can't be
right. It's odd that this always worked before. It seems to me that
chkpass_rout should be changed to build a c string like chkpass_out given the
name of the return macro. I tried that and it made no difference. I'm not
entirely surprised since I never used the chkpass_rout function in any of the
tests.
Is it possible that my thinking is wrong and I should be creating a text type
for both?
Still doesn't explain why no one else sees this though.
Oh, one more datapoint - the error only happens on vacuum analyze, not just
vacuum. Not sure what that means exactly.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
