delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DomainKey-Signature: | a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:message-id:date:from:mime-version:to:subject | |
:references:in-reply-to:content-type:content-transfer-encoding; | |
q=dns; s=default; b=G/raxLmJYmDLteu9TKgs6SYKAjK/527Kxr/n1uy1bP/ | |
y7txKqErSvIoqU+cXPnsiZajFTZeVlFEn9/zH+OjSgaIdebyFBa0qZms7zRFHsLF | |
GKvQbIcuI8STxZfXMOwqSqQ09XrIiQt6mMnVAm1EjqMqaEwM74NqzP+Pif++wgDA | |
= | |
DKIM-Signature: | v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id |
:list-unsubscribe:list-subscribe:list-archive:list-post | |
:list-help:sender:message-id:date:from:mime-version:to:subject | |
:references:in-reply-to:content-type:content-transfer-encoding; | |
s=default; bh=bKKeg8Y3zLeR+acbx7O5w7iNaiI=; b=aNmHheY5WOe29ACPu | |
p4UMORNpZCC1EcVSPFlfM1ujrcUmPZag8eLfW2jfxZ+awVxl/9s+i6XocMNbLi0l | |
MBQYQ2jLj8L5h/qW7z4oWOePjY2vt0gFHYLBQiiQz9jZKICxhKvUqsyHtA6/10VC | |
N562b+WNKy0C58/2AJQhFLemY4= | |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
X-Spam-SWARE-Status: | No, score=-1.9 required=5.0 tests=AWL,BAYES_50,KHOP_THREADED,RDNS_NONE autolearn=no version=3.3.1 |
Message-ID: | <51E74AB4.7010508@etr-usa.com> |
Date: | Wed, 17 Jul 2013 19:53:56 -0600 |
From: | Warren Young <warren AT etr-usa DOT com> |
User-Agent: | Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 |
MIME-Version: | 1.0 |
To: | Cygwin-L <cygwin AT cygwin DOT com> |
Subject: | Re: sqlite defect |
References: | <trinity-fdc5a0b5-6dcf-4fc0-9370-dd32a75fe928-1373654994500 AT 3capp-gmx-bs47>, <51E703FB DOT 1010300 AT etr-usa DOT com> <trinity-1068d666-3dec-43c9-8453-39c7cae3a94c-1374102947415 AT 3capp-gmx-bs33> |
In-Reply-To: | <trinity-1068d666-3dec-43c9-8453-39c7cae3a94c-1374102947415@3capp-gmx-bs33> |
On 7/17/2013 17:15, fger555 AT gmx DOT de wrote: > Von: "Warren Young" <warren AT etr-usa DOT com> >> try setting the new CYGWIN_SQLITE_LOCKING environment >> variable to "posix". > > Why isn't it the default? Because there are more native Windows programs based on SQLite than there are Cygwin programs based on SQLite. Since we cannot interoperate with both sets of programs at the same time, we chose to interoperate with the larger set by default. > I copied the mozilla places.sqlite bookmarks file to a backup directory This at least gives me a way to reproduce it. For anyone else who cares: $ cp ~/AppData/Roaming/Mozilla/Firefox/Profiles/*/places.sqlite /tmp (~/AppData is a symlink to the obvious location on my machine.) $ sqlite3 /tmp/places.sqlite .schema The query string can be anything that causes it to access the DB file. So, it can't just be ".quit", for example. I've done some strace diffing, and the problem seems to happen outside the Cygwin DLL, immediately after the new locking code is called: > read: 32768 = read(3, 0x80054620, 32768) > flock: 0 = flock(3, 8) > fhandler_pty_slave::write: pty0, write(0x40A502, 7) > fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms > fhandler_pty_slave::write: (654): pty output_mutex: acquired > fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released > write: 7 = write(2, 0x40A502, 7) > fhandler_pty_slave::write: pty0, write(0x80053FF0, 28) > fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms > fhandler_pty_slave::write: (654): pty output_mutex: acquired > fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released > write: 28 = write(2, 0x80053FF0, 28) > fhandler_pty_slave::write: pty0, write(0x40A50B, 1) > fhandler_pty_slave::write: (654): pty output_mutex (0xBC): waiting -1 ms > fhandler_pty_slave::write: (654): pty output_mutex: acquired > fhandler_pty_slave::write: (669): pty output_mutex(0xBC) released > write: 1 = write(2, 0x40A50B, 1) Distilled, what this says is that it successfully read()s from the DB file it has open (fd=3), then it successfully flock()s it, and then for reasons I don't understand, does 3 write()s to stderr. The mystery is what happens between lines 2 and 3, and for that I don't see anything for it but to dive back into the SQLite code. > Does the sqlite file contain a locking flag inside? Nothing so simple. Locking is handled at the OS and/or Cygwin DLL level. The build change between 3.7.16.2 and 3.7.17-3 is that we're now relying on new features in the Cygwin DLL to do Windows-style locking by default. Older versions of Cygwin SQLite bypassed the Cygwin DLL entirely for this, going straight to the Win32 API, thereby preventing the DLL from interposing itself for the "posix" case. > With the old version > I never had a problem to access the files. Yes, well, other people did have trouble with the old version, which is why we tried giving locking responsibility to the Cygwin DLL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |