TDB on OpenBSD problem.

[Jeremy Allison]

On Tue, May 01, 2001 at 02:39:58PM -0400, Jason Coene wrote:
> Chris (and the samba team),
> 
> I ran the configure script as root.
> I manually installed this version (no make install). The files are not left
> over
> from the tdb test. I am using the release 2.2, not the development cvs.
> 
> Here's some more insight to the problem:
> 
> 	I have tried this on 3 OpenBSD systems. All were able to reproduce the
> problem.
> 	Even just doing tar zxvf archive; ./configure; make; make install on one
> machine
> 	proved to create the error within an hour of startup.
> 
> 	Debug level 3 does not reveal any real problems.
> 
> 	Even NMBD is producing the same problem, which leads me to believe strongly
> 	that it is a TDB problem, and not the smbd/nmbd/lib code that interfaces
> with the tdb database.
> 
> 	When i kill the thread that is causing the problem (or i i think is the
> problem
> 	because it is using 80% cpu time), the problem continues. A new thread is
> created
> 	and it continues increasing the size of the file and eating more cpu time.
> 
> 	When two clients connect concurrently, both threads (assuming one thread
> per client)
> 	create the problem.
> 
> Any Samba developers, or someone with good knowledge of the TDB system have
> any insight
> of what this may be? The problem files are connections.tdb (seems to be a
> NMB problem, gets big
> when i open network neighborhood and the server responds), locking.tdb
> (definetly SMB, it gets
> big when i open a file in explorer), and brlock.tdb (have not gotten into
> this yet, but it gets big :])
> 
> All of these files normally capped at 8kb grow to gigs in a matter of
> minutes...

The code that causes a tdb to grow is in tdb_expand() in tdb/tdb.c.
Can you instrument this code with DEBUG level zeros to try and track
down what is causing the gig expansion. That level of expansion would
point to a bug in the interaction between tdb and mmap or fcntl.

This problem hasn't been seen on other platforms as far as I know,
if you have a completely reproducible case for this I'm very interested
in helping you track it down.

Thanks,

		Jeremy Allison,
		Samba Team.