Re: sqlite3-3.7.15.1-1 packages to test
On 08/01/13 21:31, Warren Young wrote: I've made some SQLite 3.7.15.1-1 packages, and put them up for testing: I've done some more testing, but with little success. I ran the Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch, and again on sqlite3-3.7.13-1 with the new patch applied. In both cases, the Subversion tests plodded along nicely and then froze after about 10 hours. This means one of four things. In order of probability: - I am not invoking the Subversion tests properly. All I am doing is building and installing the required version of sqlite3, and then doing 'cygport prep compile check' on the Subversion sources; - I have some third-party piece of software (BLODA) that is interfering with the tests; - The Subversion tests themselves are susceptible to freezing, and this problem isn't anything to do with Cygwin or Warren's patch; - There is some lower-level issue (say in cygwin1.dll) that is affecting the tests - unlikely as this would affect many other packages also. So now I have run the Subversion tests on two different versions of sqlite3, each with and without the patch, and all with the same result :-( Note that I am starting the tests at different points during the day, so this isn't a problem caused by some scheduled event running at the same time each day. So apologies, but at least I gave it a try. If anyone can spot anything wrong in the above steps then do let me know and I'll try again. Cheers, Dave. -- 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
Re: sqlite3-3.7.15.1-1 packages to test
David Stacey writes: > I've done some more testing, but with little success. I ran the > Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch, > and again on sqlite3-3.7.13-1 with the new patch applied. In both > cases, the Subversion tests plodded along nicely and then froze after > about 10 hours. Is it still freezing in FS_TYPE=bdb? If so, shouldn't you be worried about BerkeleyDB rather than SQlite? I remember subversion being picky about the exact version of BerkeleyDB being used and me having to install a different one than I already had (but that's been a 1.6 version IIRC so things might have progressed). And yes, these tests take far too long. 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
Re: sqlite3-3.7.15.1-1 packages to test
On 20/01/13 10:45, Achim Gratz wrote: David Stacey writes: >I've done some more testing, but with little success. I ran the >Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch, >and again on sqlite3-3.7.13-1 with the new patch applied. In both >cases, the Subversion tests plodded along nicely and then froze after >about 10 hours. Is it still freezing in FS_TYPE=bdb? If so, shouldn't you be worried about BerkeleyDB rather than SQlite? I remember subversion being picky about the exact version of BerkeleyDB being used and me having to install a different one than I already had (but that's been a 1.6 version IIRC so things might have progressed). And yes, these tests take far too long. Thank you for your reply, Achim. Yes, the freeze happens when FS_TYPE=bdb. So if we're not concerned with this configuration (for the purposes of this thread at least), then I can change Subversion's cygport file so that we only test FS_TYPE=fsfs. This will have the happy side-effect of halving the amount of time taken to run the tests :-) If you agree that this sounds sensible then I'll run the tests again with that change to the cygport file. Cheers, Dave. -- 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
Dependency of package perl to libdb4.x
Hello, I installed a new cygwin with one additional package "perl". As dependency I got libdb4.5 installed. But the installed DB_File.dll has a dependency to cygdb-4.8.dll. After manually installing libdb4.8 it worked for me. I think the perl package should have a dependency to libdb4.8. But I cannot say if the dependency to libdb4.5 could be dropped. $ ldd /lib/perl5/5.14/i686-cygwin-threads-64int/auto/DB_File/DB_File.dll ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x7773) KERNEL32.DLL => /cygdrive/c/Windows/system32/KERNEL32.DLL (0x7747) KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x74f4) cygwin1.dll => /usr/bin/cygwin1.dll (0x6100) cygdb-4.8.dll => /usr/bin/cygdb-4.8.dll (0x6fbf) cygssp-0.dll => /usr/bin/cygssp-0.dll (0x6f51) cygperl5_14.dll => /usr/bin/cygperl5_14.dll (0x6f5c) cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x6ffc) cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6fb4) Kind regards, Bernhard Cygwin Configuration Diagnostics Current System Time: Sun Jan 20 18:06:14 2013 Windows 8 Ver 6.2 Build 9200 Path: E:\win-storebackup\cygwin\usr\local\bin E:\win-storebackup\cygwin\bin C:\Users\Benutzer2\Desktop\Tools C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 Output from E:\win-storebackup\cygwin\bin\id.exe UID: 18(SYSTEM) GID: 544(Administratoren) =544(Administratoren) 0(root) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'SYSTEM' PWD = '/cygdrive/e/win-storebackup' HOME = '/home/SYSTEM' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' APPDATA = 'C:\Windows\system32\config\systemprofile\AppData\Roaming' HOSTNAME = 'win8-ent-eval' SHELL = '/bin/sh' TERM = 'cygwin' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 107 Stepping 1, AuthenticAMD' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/home/SYSTEM' USERDOMAIN = 'WORKGGROUP' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' temp = 'C:\Windows\TEMP' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' TMP = '/tmp' USERNAME = 'WIN8-ENT-EVAL$' PROCESSOR_LEVEL = '15' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'de_DE.UTF-8' USERPROFILE = 'C:\Windows\system32\config\systemprofile' TZ = 'Europe/Berlin' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' PROCESSOR_ARCHITECTURE = 'x86' LOCALAPPDATA = 'C:\Windows\system32\config\systemprofile\AppData\Local' !C: = 'C:\Windows\System32' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' PROMPT = '$P$G' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PROCESSOR_REVISION = '6b01' !E: = 'E:\win-storebackup\cygwin\bin' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '1' COMPUTERNAME = 'WIN8-ENT-EVAL' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\e:\cygwin' e6c9ac06fd9488a0 = '\??\e:\cygwin\cygwin' 394119d5a9eadcfc = '\??\z:\win-storebackup\cygwin' f4d71da1ff13eee7 = '\??\E:\win-storebackup\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'e:\cygwin\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: 685dc4bb75d52efd Path: e:\cygwin (ORPHANED) System: Key: e6c9ac06fd9488a0 Path: e:\cygwin\cygwin (ORPHANED) System: Key: 394119d5a9eadcfc Path: z:\win-storebackup\cygwin System: Key: f4d71da1ff13eee7 Path: E:\win-storebackup\cygwin c: hd NTFS 14649Mb 76% CP CS UN PA FC d: cd CDFS 1009Mb 100%CS siduction e: hd NTFS 24999Mb 90% CP CS UN PA FC windows-daten z: net NTFS467946Mb 86% CP CS UN PAstorebackup E:\win-storebackup\cygwin / system binary,auto E:\win-storebackup\cygwin\bin /usr/bin system binary,auto E:\win-storebackup\cygwin\lib /usr/lib system binary,auto cygdrive prefix/cygdrive userbinary,auto Found: E:\win-storebackup\cygwin\bin\awk -> E:\win-storebackup\cygwin\bin\gawk.exe Found: E:\win-storebackup\cygwin\bin\bash.exe Found: E:\win-storebackup\cygwin\bin\cat.exe Found: E:\win-storebackup\cygwin\bin\cp.exe Not Found: cpp (good!) Not Found: crontab Found: E:\win-storebackup\cygwin\bin\find.exe Found: C:\Windows\system32\find.exe Warning: E:\win-storebackup\cygwin\bin\find.exe hides C:\Windows\system32\find.exe Not Found: gcc Not Found: gd
Re: Intermittent failures with ctrl-c
On 01/19/2013 12:58 AM, Christopher Faylor wrote: On Fri, Jan 18, 2013 at 03:11:03PM -0500, Tom Honermann wrote: On 01/16/2013 05:23 PM, Christopher Faylor wrote: On Wed, Jan 16, 2013 at 03:18:47PM -0500, Tom Honermann wrote: I managed to duplicate a hang by changing your .bat file to use "sleep 2" rather than false. I'm investigating now. I noticed that you checked in some additional changes on the 16th that look related to this, so I tested again with today's snapshot (20130118). I thought I sent a "try a snapshot" but I must have been hallucinating again. I was still able to produce hangs using the same test case. The symptoms are slightly different than I had seen previously. bash hung 2 out of the ~60 times I interrupted the test. No error messages were displayed this time. Upon pressing ctrl-c, bash hung for 60 seconds. I was then greeted with the "Terminate batch job" prompt and responding 'Y' terminated the process tree as expected. Pressing ctrl-c while bash was hung for that 60 seconds appeared to have no affect. The hang should be fixed in the upcoming snapshot. Snapshot 20130119 appears to have addressed most of the cases I've witnessed. However, I was still able to reproduce another case. As before, one of the processes is being left running when the rest are terminated. The "abandoned" process appears to be in a live-lock state with two threads (threads 1 and 2) running at 100%. Of particular interest is that each time I press ctrl-c in the cmd.exe console this process was spawned from, a new thread appears in the process even though this program is no longer a foreground process and all other Cygwin processes have terminated. The new threads never exit. Same test case as before. However, since reproducing this may be challenging, I dug in to try and get some details that might help with reproducing it. It looks like thread 1 was interrupted while in a call to free(). Both thread 1 and 2 appear to be stuck looping on calls to yield(). Thread 3 appears to be stuck in a call to WriteFile. I suspect thread 3 was created by the initial ctrl-c event, but I'm not able to get an accurate stack trace for this thread to prove that. Threads 4 and up correspond to new threads created for new ctrl-c events. The following stack traces correspond to the above mentioned snapshot with cygwin1.dbg (from cygwin1-20130119.dbg.bz2) in place. (gdb) thread 1 [Switching to thread 1 (Thread 5344.0x1878)] #0 0x7767fbfa in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll (gdb) bt #0 0x7767fbfa in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll #1 0x7767fbfa in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll #2 0x76792ed6 in KERNELBASE!GetThreadUILanguage () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll #3 0x61087581 in yield () at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/miscfuncs.cc:243 #4 0x610d6d9c in _sigfe () from /home/thonermann/cygwin/snapshot/usr/bin/cygwin1.dll #5 0x61083180 in free () at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/malloc_wrapper.cc:43 #6 0x0010 in ?? () #7 0x in ?? () (gdb) thread 2 [Switching to thread 2 (Thread 5344.0x1ac8)] #0 0x7767f99e in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll (gdb) bt #0 0x7767f99e in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll #1 0x7767f99e in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/SysWOW64/ntdll.dll #2 0x76793a5e in SetThreadPriority () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll #3 0x6108759b in yield () at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/miscfuncs.cc:244 #4 0x610d6eb4 in _cygtls::lock() () from /home/thonermann/cygwin/snapshot/usr/bin/cygwin1.dll #5 0x610302ee in sigpacket::setup_handler (this=0x95ac04, handler=0x6102fdc0 , siga=..., tls=0x28ce64) at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/exceptions.cc:796 #6 0x610319d8 in sigpacket::process (this=0x95ac04) at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/exceptions.cc:1266 #7 0x610dd2ac in wait_sig () at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/sigproc.cc:1389 #8 0x61003ea5 in cygthread::callfunc (this=0x6118b400, issimplestub=) at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/cygthread.cc:51 #9 0x6100442f in cygthread::stub (arg=0x6118b400) at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/cygthread.cc:93 #10 0x6100538d in _cygtls::call2 (this=, func=0x610043e0 , arg=0x6118b400, buf=0x6100551b <_cygtls::call(unsigned long (*)(void*, void*), void*)+91>) at /netrel/src/cygwin-snapshot-20130119-1/winsup/cygwin/cygtls.cc:99 #11 0x0095ff88 in ?? () #12 0x76a8339a in KERNEL32!BaseCleanupAppcompatCacheSupport () from /cygdrive/c/Windows/syswow64/kernel32.dll #13 0x6118b400 in cygthread::exi
