"D'Arcy J.M. Cain" <darcy@druid.net> writes:
>> Could you try CVS tip on one of the boxes where you see the failure?
>> That'd help to narrow down the issue.
> Same issue. It must be a NetBSD issue but I can't think what.
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.
I eyeballed the chkpass code and didn't see any sign of buffer overruns,
but maybe it needs a harder look.
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?
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.
regards, tom lane
