Re: svn commit: samba r22202 - in branches/SAMBA_3_0/source/nsswitch: .
Volker is clever :-). Use TDB_NOMMAP to prevent any wild pointer problems when validating the winbindd cache. Wish I'd have thought of that. Did you really see problems like this with any tdb file? If so, can you please send me the tdb file? tdb should be doing range checking on all offsets from the db. If it isn't, then we have a bug and should fix it. The range checking code is what triggers the tdb to grow automatically when needed, so it needs to be right even for non-corrupt databases. Cheers, Tridge
Re: svn commit: samba r22202 - in branches/SAMBA_3_0/source/nsswitch: .
On Fri, Apr 13, 2007 at 01:41:39PM +1000, [EMAIL PROTECTED] wrote: Did you really see problems like this with any tdb file? If so, can you please send me the tdb file? No, no winbindd access will produce such a tdb file. tdb should be doing range checking on all offsets from the db. If it isn't, then we have a bug and should fix it. The range checking code is what triggers the tdb to grow automatically when needed, so it needs to be right even for non-corrupt databases. I know - I did work on this code remember :-). The issue some (real) customers are seeing is with laptops (mainly I believe) going down hard - no shutdown. In that case without the equivalent of an msync it's easy to get a corrupted tdb state. Probably the real solution is to go to a transactional tdb for this cache file, but I started this code before transactional tdb existed and Volker did ask me to finish it. I'd imagine the speed isn't an issue but we should check. Jeremy.
Re: svn commit: samba r22202 - in branches/SAMBA_3_0/source/nsswitch: .
Jeremy, The issue some (real) customers are seeing is with laptops (mainly I believe) going down hard - no shutdown. In that case without the equivalent of an msync it's easy to get a corrupted tdb state. That wasn't my question. I don't doubt that it is possible to get a corrupt tdb file. What I am asking is if you have seen a corrupt tdb file that causes a 'wild pointer', and presumably a crash in the tdb code that is reading the file. The patch you applied implied that you thought we might get a file like that, and that disabling MMAP would avoid the segv. I shouldn't matter if you have the contents of /dev/random in a tdb file, it should not segv, no matter if using mmap or not (there is an exception to this, where the file is truncated out from under a running program accessing tdb via mmap - that is arguably a kernel bug, and is not relevant to the situation you are trying to fix). So if you do have a tdb file that when read using mmap causes a crash, please give me a copy. It implies that we have a real bug. Cheers, Tridge
Re: svn commit: samba r22202 - in branches/SAMBA_3_0/source/nsswitch: .
On Fri, Apr 13, 2007 at 02:36:51PM +1000, [EMAIL PROTECTED] wrote: That wasn't my question. I don't doubt that it is possible to get a corrupt tdb file. What I am asking is if you have seen a corrupt tdb file that causes a 'wild pointer', and presumably a crash in the tdb code that is reading the file. The patch you applied implied that you thought we might get a file like that, and that disabling MMAP would avoid the segv. I shouldn't matter if you have the contents of /dev/random in a tdb file, it should not segv, no matter if using mmap or not (there is an exception to this, where the file is truncated out from under a running program accessing tdb via mmap - that is arguably a kernel bug, and is not relevant to the situation you are trying to fix). So if you do have a tdb file that when read using mmap causes a crash, please give me a copy. It implies that we have a real bug. Ah, *now* I see - sorry. I didn't get it. No, I don't have a file like that - I haven't seen a wild pointer crash in the tdb code itself for a long long time :-). I'm thinking of the somewhat less robust code that is processing the tdb output data :-). Although some rather woolley thinking on my part did rather confuse the two :-). I will test this code with the contents of /dev/random though (prepended with a valid tdb header of course :-). Jeremy.
