Source: xapian-core Severity: grave Tags: upstream patch Justification: causes non-serious data loss
[A note on the severity - whether the data loss is serious or non-serious depends how Xapian is being used. In my experience, it's more common to use it to index data which is stored in another system (to provide a full text search), rather than as the canonical storage for data. If that's the case, then you can reindex the data (though for a lot of data that can take significant time, but if Xapian is the canonical data store, then the data loss is serious.] Xapian's uses fcntl() file locks to enforce a single-writer model, and the locking code attempts to work around the semantics of fcntl() whereby closing *any* fd on the lock file in the same process releases the lock. It does this by using a child process to hold the lock, but there's a flaw - it closes all unwanted fds in the child process (for the usual reasons that daemons do), but this is done *after* obtaining the fcntl() lock and so if the lock file is open as one of those fds, the child no longer holds the lock. Unfortunately this case is exactly what happens if multiple threads of the same process try to open a database for writing concurrently, and a simple test program shows that you can easily corrupt a database in this way. The fix is to simply close the unwanted file handles before trying to obtain the fcntl() lock. This has been fixed in upstream SVN, and should be in 1.2.13 (the next 1.2.x release): http://trac.xapian.org/changeset/16938/branches/1.2/xapian-core/backends/flint_lock.cc Cheers, Olly -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash
signature.asc
Description: Digital signature
