-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I usually don't do this but there are some changes coming which people should be aware of and which deserve special testing. First, I spent a great deal of time on nscd. The version in the current FC3 test is quite different from old code and starting with the 2.3.3-50 glibc (not published yet) there will be another big change. The nscd in FC3 now supports persistent database. The information gathered cached is not lost when the nscd process is terminated. This means right after startup a lot of information is already available, no need to go to the services. Along with the change nscd was changed to reload data when the timeout time is reached. This means in general no delay here either. Entries which are in constant use probably won't leave the cache at all. To implement this lots of internals changed, especially the memory handling. And this is where testing is needed. The amount of memory available for caching is now directly dependent on the size of the hash table (look at the nscd.conf file). If the table is sized too small data cannot be stored. This is very different from the old behavior where a too-small hash table only meant that the performance degraded due to hash collisions. So my plea is, especially those of you who can run the code on machines with high usage of passwd, group, host information (multiuser machines, ftp/http servers), please give it a try. Use nscd --stat to review the statistics (ask if in doubt). It'll show you when the hash table is too small. I would like to find a reasonable default size. The already mentioned 2.3.3-50 version will bring another change. The communication between processes and nscd is radically different (read: it's *much* faster; one test suite is 100x faster). Here I am mostly concerned about robustness. The cache handling is very tricky. So again, people who could expose the code to high usage are invited to let me know whether the code works or not (please also report success). Also new in the last versions of glibc is stricter error checking in the memory handling code. The FC3 code today already aborts when it finds a problem. Before only a warning was issued and people tended to ignore this. Now the process is terminated in addition to the error message. The default can be changed with the MALLOC_CHECK_ environment variable (setting it to zero disables the checks). It is *highly* advised to not change the default and instead report/fix the problems. These are potentially fatal bugs which might also imply security risks. I think Warren at some point reported OO.org does start. It is the application's fault, so don't complain about glibc. Fix the code. In 2.3.3-50 I've added more tests and there might be yet more to come in future. Programs which seemed to have worked fine in the past might now crash because of the much stricter tests. Again, report/fix the problem. I _think_ I got the tests right. If something looks suspicious feel free to file a bug against glibc. But do this only if you have carefully investigated the situation and ideally if valgrind, mudflap, and perhaps efence all have not found a bug. Thanks for testing. - -- â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBQQ9k2ijCOnn/RHQRAjK9AJsF6EF5D7CJhro+IPf4Ufh+k/nNBACgqabe lQq/ZGf2d1uR/yYsXQuFjco= =xpBY -----END PGP SIGNATURE-----
