Re: sqlite defect

[Warren Young <warren at etr-usa dot com>]

On 7/17/2013 17:15, fger555@gmx.de wrote:
> Von: "Warren Young" <warren@etr-usa.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