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.
Hmm. I might try adding some buffer in MemoryContextAlloc() and see if that
changes anything. One thing that may be different is that NetBSD is 64 bit
clean. I don't think the other i386 systems are.
> I eyeballed the chkpass code and didn't see any sign of buffer overruns,
> but maybe it needs a harder look.
It's pretty simple. Not even indexing. In fact, I wondered if I should add
some just like my other type that does do indexing. That seemed to be the
only real difference between the two and the other works.
> Hm --- I guess another possible variable is behavior of the local
> crypt() function. Is NetBSD's crypt perhaps willing to return strings
> longer than 13 chars?
Well, the value that it stores is the correct 13 character DES string.
> Did you try CVS tip both with and without --enable-cassert? That turns
> on memory context checking which might alter the failure in interesting
> ways.
No difference. It seems that PostgreSQL is too good at catching the problem
before the assert macros see it.
--
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.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
