We appear to have also been hit by this bug Firstly, the bug is seemingly only triggered by GETPWBYNAME cached entities whose cached key (ie what the process tried to getpwnam()) does not match pw->pw_name.
Looking at pwdcache.c shows that for records of this type, cache_addpw creates a copy of the key for use with cache_add(), however cache_add() itself (in cache.c) uses pointer arithmatic which makes assumptions about the "key" argument and table->data coming from the same memory allocation which I'm not certain are valid. The code is pretty poorly commented and arcane. But I'll try to pick more up when I get time. -- Colm MacCárthaigh Public Key: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
