Re: cygwin bughunt (snapshot)
Cristopher Faylor wrote: David Dindorp wrote: Bash seems to think that it's child has terminated prematurely. Has anyone experienced something similar? Being precise is one thing you could do. I tried my best. You could also provide cygcheck output as is suggested by http://cygwin.com/problems.html. cygcheck from the test box is attached. I thought it wouldn't be relevant, since I included all version numbers. Also, I modify the environment as the first thing when the script runs: SET CYGWIN=binmode check_case:relaxed codepage:ansi \ envcache notitle strip_title notty nontsec And also set PATH and LD_LIBRARY_PATH to point to the Cygwin 'bin' directory. Also, providing simple test cases which reproduce the problem would help. I really tried, but so far have not been able to produce a simple test case. My best guess right now is that it only occurs when load is high, or when the right timing conditions apply. I thought it was obvious that I include test cases for every bug where I'm able to produce one, especially since I posted one last week. Actually, I can't find the mail in the mailing list archives right now, although it is in my 'sent items'. Nobody replied to it either. Maybe it got blocked because of the attachments - it was a .sh script and a .bat script. Do you by any chance have some really dumb spam filter in place that blocks anything named eg. .bat ? :-) Subject of e-mail was testing snapshot, it mentioned 3 other bugs (something related to 'grep', something with sync_with_child). I'll try resending it, let me know if you'd rather try and find it in your (?) spam blocker. I just wasted some time trying to reproduce your environment since I assumed that you'd provided a script which could easily reproduce the problem and that this was a problem which was specific to the snapshot. I'm truly sorry. It is sort of specific to the snapshot, since the problem occurs at a different rate in older versions. Anyway, this sounds a lot like the bash problem which has been discussed here over the last several months (most heavily in the October time frame). If you aren't running bash-2.05b-17 then that's probably your problem. bash 3.0 is not good enough? I went through the archives for October (anything related to bash), but couldn't find anything that seems related to me. Would you mind pointing me in the right direction (subject, link, anything)? Cygwin Configuration Diagnostics Current System Time: Mon Feb 28 20:27:50 2005 Windows 2000 Server Ver 5.0 Build 2195 Service Pack 4 Path: C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\PROGRA~1\CHECKP~1\CPShared\R55\bin C:\PROGRA~1\CHECKP~1\CPShared\R55\lib C:\PROGRA~1\CHECKP~1\CPShared\R55\util C:\PROGRA~1\CHECKP~1\cpinfo\R55\bin C:\WINNT\FW1\R55\lib C:\WINNT\FW1\R55\bin `id' program not found `id' program not found SysDir: C:\WINNT\system32 WinDir: C:\WINNT Path = `C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\PROGRA~1\CHECKP~1\CPShared\R55\bin;C:\P KP~1\CPShared\R55\util;C:\PROGRA~1\CHECKP~1\cpinfo\R55\bin;C:\WINNT\FW1\R55\lib;C:\WINNT\FW1\R55\bin ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\Administrator\Application Data' CLIENTNAME = `DUBEX-DDI' CommonProgramFiles = `C:\Program Files\Common Files' COMPUTERNAME = `LOGEXPORT' ComSpec = `C:\WINNT\system32\cmd.exe' CPDIR = `C:\Program Files\CheckPoint\CPShared\R55' CPMDIR = `C:\WINNT\FW1\R55' FWDIR = `C:\WINNT\FW1\R55' FW_BOOT_DIR = `C:\WINNT\FW1\R55\boot' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\Administrator' LOGONSERVER = `\\LOGEXPORT' NUMBER_OF_PROCESSORS = `1' OS = `Windows_NT' Os2LibPath = `C:\WINNT\system32\os2\dll;' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 1 Stepping 2, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0102' ProgramFiles = `C:\Program Files' PROMPT = `$P$G' SESSIONNAME = `RDP-Tcp#58' SHARED_LOCAL_PATH = `C:\PROGRA~1\CHECKP~1\CPShared\R55\database' SUDIR = `C:\WINNT\FW1\R55\sup' SUROOT = `C:\SUroot' SystemDrive = `C:' SystemRoot = `C:\WINNT' TEMP = `C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\2' TMP = `C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\2' USERDOMAIN = `LOGEXPORT' USERNAME = `Administrator' USERPROFILE = `C:\Documents and Settings\Administrator' windir = `C:\WINNT' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0 HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00 (default) = `C:' unix = `/'
Re: cygwin bughunt (snapshot)
On Tue, Mar 01, 2005 at 09:08:04AM +0100, David Dindorp wrote: Cristopher Faylor wrote: Christopher Anyway, this sounds a lot like the bash problem which has been discussed here over the last several months (most heavily in the October time frame). If you aren't running bash-2.05b-17 then that's probably your problem. bash 3.0 is not good enough? If you are running your own version of bash, then all bets are off. I thought that bash-2.05b-17 was the current version but it is actually a test version designed to handle the problem that you are apparently describing. I'll follow up in cygwin-apps to see why this version is still in test. I went through the archives for October (anything related to bash), but couldn't find anything that seems related to me. Would you mind pointing me in the right direction (subject, link, anything)? Sorry, no. I'm not going to do an archive search for you. Maybe someone else will accommodate you. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
On Tue, Mar 01, 2005 at 07:58:53AM -0500, Christopher Faylor wrote: I went through the archives for October (anything related to bash), but couldn't find anything that seems related to me. Would you mind pointing me in the right direction (subject, link, anything)? Sorry, no. I'm not going to do an archive search for you. Maybe someone else will accommodate you. Ok. I was wrong. It wasn't in the October archives and didn't immediately see anything obvious. I assumed that there was a discussion in that month because that's when the newer version of bash was uploaded. So, I looked in the archives for the release announcement for the test version of bash-2.05b-17 and quickly found this: http://cygwin.com/ml/cygwin/2004-09/threads.html#00781 cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
On Tue, Mar 01, 2005 at 08:35:30AM -0500, Christopher Faylor wrote: On Tue, Mar 01, 2005 at 07:58:53AM -0500, Christopher Faylor wrote: I went through the archives for October (anything related to bash), but couldn't find anything that seems related to me. Would you mind pointing me in the right direction (subject, link, anything)? Sorry, no. I'm not going to do an archive search for you. Maybe someone else will accommodate you. Ok. I was wrong. It wasn't in the October archives and didn't immediately see anything obvious. It is obviously too early for me to be sending email. What I meant to say above is: I looked in the October archives and didn't immediately see anything obvious. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
Christopher Faylor wrote (quotes rearranged wildly): If you are running your own version of bash, then all bets are off. Just double-checked. BASH_VERSION='2.05b.0(1)-release'. I thought I was running 3.00 on Cygwin (I am on all other platforms), but apparently I was just making an ass of myself on a public mailing list (again?) stating that I was. Well, actually, it's first real embarassing now that I have to admit it. Well, not have to, but anyway, there you have it. *hum*. Ok. I was wrong. It wasn't in the October archives and didn't immediately see anything obvious. It is obviously too early for me to be sending email. *laugh* :-D. The cygwin list. It's mean but it's funny =). So, I looked in the archives for the release announcement for the test version of bash-2.05b-17 and quickly found this: http://cygwin.com/ml/cygwin/2004-09/threads.html#00781 Thank you very much! I thought that bash-2.05b-17 was the current version but it is actually a test version designed to handle the problem that you are apparently describing. Fixed? Ooh! I'm currently dancing around like an ogre with a brain disease over the good news, but once I sober up I'll install it right away and let the list know if it helps. Might take a week or so, hope it won't be a month like the last time. Once again, thank you very much for your help so far. Also goes to the rest of you guys, of course. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin bughunt (snapshot)
Original Message From: David Dindorp Sent: 01 March 2005 15:17 Christopher Faylor wrote (quotes rearranged wildly): If you are running your own version of bash, then all bets are off. Just double-checked. BASH_VERSION='2.05b.0(1)-release'. I thought I was running 3.00 on Cygwin (I am on all other platforms), but apparently I was just making an ass of myself on a public mailing list (again?) Welcome to our world! You're going to fit in just fine! cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
Dave Korn wrote: David Dindorp wrote: Just double-checked. BASH_VERSION='2.05b.0(1)-release'. I thought I was running 3.00 on Cygwin (I am on all other platforms), but apparently I was just making an ass of myself on a public mailing list (again?) Welcome to our world! Version number impediment is what keeps us together. The version number, as reported by bash, on the 2.05b-17 I just downloaded is: BASH_VERSION='2.05b.0(1)-release'. Hum. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
On Tue, Mar 01, 2005 at 04:42:52PM +0100, David Dindorp wrote: Dave Korn wrote: David Dindorp wrote: Just double-checked. BASH_VERSION='2.05b.0(1)-release'. I thought I was running 3.00 on Cygwin (I am on all other platforms), but apparently I was just making an ass of myself on a public mailing list (again?) Welcome to our world! Version number impediment is what keeps us together. The version number, as reported by bash, on the 2.05b-17 I just downloaded is: BASH_VERSION='2.05b.0(1)-release'. Hum. Oh well. Time to install U/WIN? cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin bughunt (snapshot)
Original Message From: Christopher Faylor Sent: 01 March 2005 15:49 On Tue, Mar 01, 2005 at 04:42:52PM +0100, David Dindorp wrote: Dave Korn wrote: David Dindorp wrote: Just double-checked. BASH_VERSION='2.05b.0(1)-release'. I thought I was running 3.00 on Cygwin (I am on all other platforms), but apparently I was just making an ass of myself on a public mailing list (again?) Welcome to our world! Version number impediment is what keeps us together. The version number, as reported by bash, on the 2.05b-17 I just downloaded is: BASH_VERSION='2.05b.0(1)-release'. Hum. Oh well. Time to install U/WIN? cgf Micro$fot are thinking of renaming that. It's now going to be called THEY/WIN/WE/ALL/LOSE. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
On Mar 1 16:02, Dave Korn wrote: Oh well. Time to install U/WIN? Micro$fot are thinking of renaming that. It's now going to be called THEY/WIN/WE/ALL/LOSE. You mean Interix, don't you? U/Win is from ATT. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
In the meanwhile, does anybody have any comments to offer regarding this? (Besides stop asking, that is...) Bash hangs. Both occurrences have been at the same specific script line, and both produce similar gdb output. Script line: lffields[$counter]=`echo $lfline|cut -d'|' -f$fieldno` Last executed line - hung script no. 1: +++ cut '-d|' -f5 Last executed line - hung script no. 2: +++ cut '-d|' -f1 Backtrace, dumped process 1: #0 0x77f8a1eb in ntdll!ZwSetInformationThread () #1 0x7c4fb5bf in SetThreadPriority () #2 0x610035c6 in getprogname () #3 0x6105ad27 in cygwin_split_path () #4 0x61019478 in cygwin_internal () #5 0x6107bc25 in getppid () #6 0x6107ba4d in getppid () #7 0x610723ff in cygwin1!aclcheck () #8 0x0042562a in ?? () #9 0x0005 in ?? () #10 0x0022cf20 in ?? () #11 0x0080 in ?? () #12 0x610749bb in writev () Backtrace, dumped process 2: #0 0x77f8a1eb in ntdll!ZwSetInformationThread () #1 0x7c4fb5bf in SetThreadPriority () #2 0x610035c6 in getprogname () #3 0x6105ad27 in cygwin_split_path () #4 0x61019478 in cygwin_internal () #5 0x6107bc25 in getppid () #6 0x6107ba4d in getppid () #7 0x610723ff in cygwin1!aclcheck () #8 0x0042562a in ?? () #9 0x0005 in ?? () #10 0x0022cf20 in ?? () #11 0x0080 in ?? () #12 0x610749bb in writev () -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
Bash seems to think that it's child has terminated prematurely. Has anyone experienced something similar? Evidence: See the order of execution in the script below, compare with what bash does (further below). Version: snapshot 20050226 / bash 3.0. If I'm grossly missing anything from my error reports, could you please point it out? Thank you... Script: == tar --remove-files --ignore-failed-read -cvf \ $arcrfname $arcsourcedir cerr=$? sleep 30 if [ $cerr -ne 0 ]; then echo `date +'%Y-%m-%d %H:%M:%S'`: TAR error $cerr. fi if [ -f $arcrfname ]; then echo `date +'%Y-%m-%d %H:%M:%S'`: TAR OK. else echo `date +'%Y-%m-%d %H:%M:%S'`: TAR failed. fi == Log file: == +++ tar --remove-files --ignore-failed-read -cvf \ /0007-02-2005-02-28-14-05-06-readyarchive_quick.tar ready-quick +++ cerr=0 +++ sleep 30 +++ '[' 0 -ne 0 ']' +++ '[' -f 0007-02-2005-02-28-14-05-06-readyarchive_quick.tar ']' date '+%Y-%m-%d %H:%M:%S' tar: Removing leading `/' from member names /var/ready-quick/ /var/ready-quick/file1 /var/ready-quick/file2 /var/ready-quick/file3 /var/ready-quick/file4 /var/ready-quick/file5 +++ echo '2005-02-28 14:05:07: TAR failed.' == -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin bughunt (snapshot)
Original Message From: David Dindorp Sent: 28 February 2005 17:54 Evidence: See the order of execution in the script below, compare with what bash does (further below). Log file: == +++ tar --remove-files --ignore-failed-read -cvf \ /0007-02-2005-02-28-14-05-06-readyarchive_quick.tar ready-quick Hmm. You appear to have told tar to create the output archive in the root directory of the filing system. +++ cerr=0 +++ sleep 30 +++ '[' 0 -ne 0 ']' +++ '[' -f 0007-02-2005-02-28-14-05-06-readyarchive_quick.tar ']' Hmm. You appear to be testing for the existence of said archive in the current working directory, which I strongly suspect is /var. I would _expect_ the -f test to fail in this case, although I'm at a loss as to why $arcrfname would have had a slash at the beginning when you passed it to the tar command but has now somehow lost that slash date '+%Y-%m-%d %H:%M:%S' tar: Removing leading `/' from member names /var/ready-quick/ /var/ready-quick/file1 /var/ready-quick/file2 /var/ready-quick/file3 /var/ready-quick/file4 /var/ready-quick/file5 +++ echo '2005-02-28 14:05:07: TAR failed.' Hmm. The fact that the stderr output is buffered somewhere along the line and only now emerges may be entirely a red herring. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
Dave Korn wrote: Hmm. You appear to have told tar to create the output archive in the root directory of the filing system. Hm, actually $arcrfname contains a full path, including /cygdrive/c/... I cut it from the script and output because it made it entirely unreadable (partly related to my mailer cutting everything at character position 73). The entire path (not screwed up by me) is: /cygdrive/c/agent/agent/var/tmp/0007-02-2005-02-28-14-05-06-readyarchive _quick.tar Which is checked for, and in most cases the script runs correctly. But once in a while, it does this thing. When I notice it and check up on it later on, the TAR file sits right where it should. Sorry for the confusion. Good spotting though =). By the way, the backslashes escaping the long lines are my doing too. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
On Mon, Feb 28, 2005 at 06:53:50PM +0100, David Dindorp wrote: Bash seems to think that it's child has terminated prematurely. Has anyone experienced something similar? Evidence: See the order of execution in the script below, compare with what bash does (further below). Version: snapshot 20050226 / bash 3.0. If I'm grossly missing anything from my error reports, could you please point it out? Thank you... http://cygwin.com/problems.html Script: == tar --remove-files --ignore-failed-read -cvf \ $arcrfname $arcsourcedir cerr=$? sleep 30 if [ $cerr -ne 0 ]; then echo `date +'%Y-%m-%d %H:%M:%S'`: TAR error $cerr. fi if [ -f $arcrfname ]; then echo `date +'%Y-%m-%d %H:%M:%S'`: TAR OK. else echo `date +'%Y-%m-%d %H:%M:%S'`: TAR failed. fi == It's difficult to see how this could be an actual run of the above script. Log file: == +++ tar --remove-files --ignore-failed-read -cvf \ /0007-02-2005-02-28-14-05-06-readyarchive_quick.tar ready-quick ^^^ +++ cerr=0 +++ sleep 30 +++ '[' 0 -ne 0 ']' +++ '[' -f 0007-02-2005-02-28-14-05-06-readyarchive_quick.tar ']' ^^ What happened to the leading slash? date '+%Y-%m-%d %H:%M:%S' tar: Removing leading `/' from member names /var/ready-quick/ ^ Where did the /var come from? It wasn't mentioned in the output above. FWIW, when I try this, everything works as expected. It's difficult to see how this could be executed out of order unless your tar and/or sleep are not standard cygwin programs. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
Cristopher Faylor wrote: David Dindorp wrote: Bash seems to think that it's child has terminated prematurely. Has anyone experienced something similar? Evidence: See the order of execution in the script below, compare with what bash does (further below). Version: snapshot 20050226 / bash 3.0. [...] It's difficult to see how this could be an actual run of the above script. I snipped irrelevant parts of the output, eg. long paths. (FYI, the original log file is ~ 341.000 lines of output.) [...] What happened to the leading slash? Busted! Damn... [...] FWIW, when I try this, everything works as expected. It's difficult to see how this could be executed out of order unless your tar and/or sleep are not standard cygwin programs. It does work 90% of the time. Under Cygwin 1.5.10, the problem is also there, and *MUCH* worse. tar.exe, gzip.exe and sleep.exe are from *cough* 1.5.10 *cough*. I was told that it doesn't matter as long as the Cygwin DLL is a fresh nightly. I'll replace them with 1.5.12-1's and catch the error again (prolly in a couple of days or so) if that's better? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot)
On Mon, Feb 28, 2005 at 07:44:46PM +0100, David Dindorp wrote: Cristopher Faylor wrote: David Dindorp wrote: Bash seems to think that it's child has terminated prematurely. Has anyone experienced something similar? Evidence: See the order of execution in the script below, compare with what bash does (further below). Version: snapshot 20050226 / bash 3.0. [...] It's difficult to see how this could be an actual run of the above script. I snipped irrelevant parts of the output, eg. long paths. (FYI, the original log file is ~ 341.000 lines of output.) [...] What happened to the leading slash? Busted! Damn... [...] FWIW, when I try this, everything works as expected. It's difficult to see how this could be executed out of order unless your tar and/or sleep are not standard cygwin programs. It does work 90% of the time. Under Cygwin 1.5.10, the problem is also there, and *MUCH* worse. tar.exe, gzip.exe and sleep.exe are from *cough* 1.5.10 *cough*. I was told that it doesn't matter as long as the Cygwin DLL is a fresh nightly. I'll replace them with 1.5.12-1's and catch the error again (prolly in a couple of days or so) if that's better? There is no such thing as a 1.5.12-1 version of tar. You asked what you could do to report problems. Being precise is one thing you could do. You could also provide cygcheck output as is suggested by http://cygwin.com/problems.html . Also, providing simple test cases which reproduce the problem would help. I just wasted some time trying to reproduce your environment since I assumed that you'd provided a script which could easily reproduce the problem and that this was a problem which was specific to the snapshot. Apparently that is not the case. Anyway, this sounds a lot like the bash problem which has been discussed here over the last several months (most heavily in the October time frame). If you aren't running bash-2.05b-17 then that's probably your problem. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin bughunt (snapshot...)
Christopher Faylor wrote: If that was really true, you'd be using a snapshot by now. Ok, ok, I can take a hint (sort of). I'll give up trying to drill down bugs in 1.5.10. Has the problem been found that results in this error?: MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 At first glance, it seems to be gone. Great! So far a couple of things have popped up in testing. Only one of them is a new item since I started using the 20050221 snapshot. It has occurred 2 times over 2 days so far, so I feel that it is reproducible. Bash hangs. Both occurrences have been at the same specific script line, and both produce similar gdb output. Script line: lffields[$counter]=`echo $lfline|cut -d'|' -f$fieldno` Script line - process 592: +++ echo '0007-02-2005-01-29-22-15-24-xferslowevlog.log|0|1107034112|1107034112|1 107034675|1107035470' +++ cut '-d|' -f5 Script line - process 3164: +++ echo '0007-02-2005-02-10-06-02-55-xferslowevlog.log|0|1108012113|-1|110801244 7|1108012465' +++ cut '-d|' -f1 Backtrace, dumped process 592: #0 0x77f8a1eb in ntdll!ZwSetInformationThread () #1 0x7c4fb5bf in SetThreadPriority () #2 0x610035c6 in getprogname () #3 0x6105ad27 in cygwin_split_path () #4 0x61019478 in cygwin_internal () #5 0x6107bc25 in getppid () #6 0x6107ba4d in getppid () #7 0x610723ff in cygwin1!aclcheck () #8 0x0042562a in ?? () #9 0x0005 in ?? () #10 0x0022cf20 in ?? () #11 0x0080 in ?? () #12 0x610749bb in writev () Backtrace, dumped process 3163: #0 0x77f8a1eb in ntdll!ZwSetInformationThread () #1 0x7c4fb5bf in SetThreadPriority () #2 0x610035c6 in getprogname () #3 0x6105ad27 in cygwin_split_path () #4 0x61019478 in cygwin_internal () #5 0x6107bc25 in getppid () #6 0x6107ba4d in getppid () #7 0x610723ff in cygwin1!aclcheck () #8 0x0042562a in ?? () #9 0x0005 in ?? () #10 0x0022cf20 in ?? () #11 0x0080 in ?? () #12 0x610749bb in writev () (I'm obviously a n00b with gdb. The similar output could be a side effect from debugging the processes?..) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
