X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org To: cygwin AT cygwin DOT com From: Achim Gratz Subject: Re: Promote sqlite 3.7.13-1 from test status? Date: Sat, 02 Mar 2013 08:53:18 +0100 Lines: 52 Message-ID: <87621ai6fl.fsf@Rainer.invalid> References: <502C0B7D DOT 10909 AT etr-usa DOT com> <20120816085016 DOT GB5536 AT calimero DOT vinschen DOT de> <502CCBB1 DOT 2070600 AT etr-usa DOT com> <20120816105507 DOT GD17546 AT calimero DOT vinschen DOT de> <502CE120 DOT 4050900 AT etr-usa DOT com> <20120816122654 DOT GG17546 AT calimero DOT vinschen DOT de> <502D1967 DOT 7090705 AT etr-usa DOT com> <20120816160656 DOT M21257 AT ds DOT net> <502D3A5C DOT 7010500 AT etr-usa DOT com> <00ad01cd7bf6$7cc68a50$76539ef0$@motionview3d.com> <1345169297 DOT 10004 DOT 10 DOT camel AT YAAKOV04> <87k3qmedzh DOT fsf AT Rainer DOT invalid> <51194F7F DOT 8050403 AT etr-usa DOT com> <87halio886 DOT fsf AT Rainer DOT invalid> <511967DD DOT 8030600 AT etr-usa DOT com> <87d2w6o6iq DOT fsf AT Rainer DOT invalid> <5119E08B DOT 6050909 AT etr-usa DOT com> <5131312B DOT 4000907 AT etr-usa DOT com> Mime-Version: 1.0 Content-Type: text/plain User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.93 (gnu/linux) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Warren Young writes: > I never have run the SQLite tests. I see, thanks for letting me know. That adds another unknown in that investigation, unfortunately. > At this point, I'm about to give up on it and ship an updated version > of my latetst test packages. That is, with FTS and such features > enabled, the Unix /tmp directory patch, and built in Windows mode. Yes, I guess that'd make sense. >> the testsuite does >> indeed produce a few of the dreaded disk I/O errors that seem to have >> serious consequences. > > How? The test result is different from the expected result, which might indicate that the wrong data is returned (no overt database corruption has happened, AFAICS). I haven't yet looked up what those tests are actually trying to do. > I mean, shouldn't the test suite be running only pure Cygwin programs, > on files accessed only via cygwin1.dll, with POSIX locking only? If > so, how can you run into locking errors? Since I can't know what to expect for the non-POSIX build (it might be that these errors are triggered someplace else), I don't know if they are a consequence of the (at the moment rather crude) changes I made. Also, "disk I/O error" can unfortunately mean a lot of things, not just locking, so even that is just an hypothesis at the moment. However, "Windows programs" are always involved since I can't switch (completely) off the virus scanner on the build machine. > The reason this saga started with locking errors is that we were > trying to mix POSIX and Windows native locking. That situation > shouldn't continue within the SQLite test suite. How do you know this wouldn't happen for the "normal Cygwin build? As I said, while sqlite3 builds in this case, the testsuite doesn't. The next step will be to try to use the testsuite from the POSIX build and use it with the sqlite3 for Cygwin. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs -- 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