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/
Re: cygwin bughunt (Jip-hee!)
On Fri, Feb 18, 2005 at 11:29:38AM +0100, David Dindorp wrote: Christopher Faylor wrote: The test were performed with 1.5.10-3, as newer versions call upon me all sorts of other problems and thus can't be pushed to the failing box right now. Btw, I urge everyone to try the latest cygwin snapshot! This quote comes from a thread that suggested cygwin had mind control powers. If that was really true, you'd be using a snapshot by now. Will do. Has the problem been found that results in this error?: *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 I don't know. You didn't produce a test case and I could never reproduce the problem. I did take a stab at fixing it and made some changes in that code so the error message will be different now, at least. 2) You can *try* a snapshot to see if it fixes your problem. Will do sort of implies that that was exactly the course of action I was contemplating :-). And asterisks around *try* implies that you should stop talking about it and start *doing* it. It is possible that this problem has been fixed by my recent attempts to correct the dreaded hyperthreading problem. However, if it hasn't been fixed, I'm not willing to debug problems in 1.5.10. It would be a fruitless endeavor. The code has changed in the last six months and, even if the problem was tracked down, we're not going to be releasing a new version of 1.5.10. If you want help, either use a snapshot or CVS. 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 (Jip-hee!)
Christopher Faylor wrote: Ah, yes! You're the you don't want people to debug cygwin because you aren't spoon feeding me debugging information guy! That is nowhere near what was said. I said you should provide debugging versions of Cygwin, since large software packages are hell to build. I was wrong in the case of Cygwin and I admitted my mistake. I don't know what your problem is - but I'll bet it's hard to pronounce. You're the guy who insisted on dropping back to 1.5.10! I remember now! I'm not dropping back, it's a customer system, and it's been running 1.5.10 for some time now. In the future, please provide more context if you really want to be helped, especially after almost a month of silence. Apologies. A month was the time it took to get the debug version through testing and to the affected system. I thought the version number and a specific location in the source code (as provided) would be enough information to at least get a pointer from you on whether it's a problem you've seen before. What else do you need? The test were performed with 1.5.10-3, as newer versions call upon me all sorts of other problems and thus can't be pushed to the failing box right now. Btw, I urge everyone to try the latest cygwin snapshot! Will do. Has the problem been found that results in this error?: *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 1) Regardless of whether the new versions call upon (you) all sorts of other problems, I doubt that anyone is going to spend any time tracking down problems in older versions. I'm not asking you to spend a lot of time on it. I just hope you could shed some light on the issue. Eg. have you seen hung Cygwin processes having to do with closing file descriptor 5 before? Any information on why it's closing file descriptor 5 (it's not used by the scripts) would be helpful too. 2) You can *try* a snapshot to see if it fixes your problem. Will do sort of implies that that was exactly the course of action I was contemplating :-). -- 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 (Jip-hee!)
Christopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. You are right; I was wrong. Building Cygwin is easy. (At least when it comes to newer versions :-p.) It even compiles under itself. *impressed*. It's been a few weeks, and I've tested with the debug version. Seems that it's hanging in some pipe related stuff, see GDB output further down. Other peculiarities noted: 1. When listing processes with PS, the hung process has the 'WINPID' in the cygwin PID column instead of the cyg PID. 2. The problem seems to only occur on one machine, which happens to be multi-processor (2*Xeon). At least it occurs very frequently on this box. I've seen a hang once on a UP machine. I tried to find more information about the process using Process Explorer, which seemingly triggers another strange condition - the CPU time of the process shot to 100%. It was looping in ntdll.dll!RtlConvertUiListToApiList+0x2fd. Here's backtraces from GDB (snipped a bit here and there). core dump 1 (gdb) info threads 3 process 3620 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 4236 0x77f839eb in ntdll!ZwReadFile () * 1 process 3832 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073b16 in fhandler_pipe::close() (this=0x616d15f0) --- at ../../../../winsup/cygwin/pipe.cc:103 #3 0x6109ac34 in close (fd=5) at winsup/cygwin/cygheap.h:304 #4 0x6108db7f in _sigfe () at winsup/cygwin/cygserver.h:82 = core dump 2 (gdb) info threads 3 process 4496 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 3796 0x77f839eb in ntdll!ZwReadFile () * 1 process 1528 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073b16 in fhandler_pipe::close() (this=0x616d0fd8) --- at ../../../../winsup/cygwin/pipe.cc:103 #3 0x6109ac34 in close (fd=5) at winsup/cygwin/cygheap.h:304 #4 0x6108db7f in _sigfe () at winsup/cygwin/cygserver.h:82 = core dump 3 (gdb) info threads 3 process 2424 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 4568 0x77f839eb in ntdll!ZwReadFile () * 1 process 4540 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073b16 in fhandler_pipe::close() (this=0x616d15f0) --- at ../../../../winsup/cygwin/pipe.cc:103 #3 0x6109ac34 in close (fd=5) at winsup/cygwin/cygheap.h:304 #4 0x6108db7f in _sigfe () at winsup/cygwin/cygserver.h:82 = The test were performed with 1.5.10-3, as newer versions call upon me all sorts of other problems and thus can't be pushed to the failing box right now. Btw, I urge everyone to try the latest cygwin snapshot! Will do. Has the problem been found that results in this error?: *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 -- 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 (Jip-hee!)
On Thu, Feb 17, 2005 at 02:23:42PM +0100, David Dindorp wrote: Christopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. You are right; I was wrong. Building Cygwin is easy. (At least when it comes to newer versions :-p.) It even compiles under itself. *impressed*. It's been a few weeks, and I've tested with the debug version. Er, who are you? **cgf checks archives Ah, yes! You're the you don't want people to debug cygwin because you aren't spoon feeding me debugging information guy! You're the guy who insisted on dropping back to 1.5.10! I remember now! In the future, please provide more context if you really want to be helped, especially after almost a month of silence. The test were performed with 1.5.10-3, as newer versions call upon me all sorts of other problems and thus can't be pushed to the failing box right now. Btw, I urge everyone to try the latest cygwin snapshot! Will do. Has the problem been found that results in this error?: *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 1) Regardless of whether the new versions call upon (you) all sorts of other problems, I doubt that anyone is going to spend any time tracking down problems in older versions. 2) You can *try* a snapshot to see if it fixes 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 (FAQ alert?)
Igor Pechtchanski wrote: Umm, that was my bad. The thing is, --enable-debugging really produces a developer debug version, with extra tracing, etc. If all you want is a version of DLL with all the symbols (i.e., unstripped), the regular build produces that as well. Cristopher Faylor wrote: ...and now you get to repeat these facts endlessly as people find your words in the archives and assume that they need use this option regardless of follow-on discussion or the FAQ. How about adding a line in the FAQ to the how to build cygwin (104) entry stating that the configure ; make mentioned does produce a Cygwin with all debugging symbols? And the link in the FAQ is wrong: How can I debug cygwin (entry 105) says: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102.; The above should point to entry 104, not 102. -- 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 (FAQ alert?)
Ack! Apologies for the formatting. The company I'm employed at uses Outlook (thereby MS-WORD) for e-mail. Here's what I wanted to say: The FAQ entry 105 links to entry 102 under how to compile. Shouldn't this point to 104 instead? -- 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 (FAQ alert?)
On Wed, 26 Jan 2005 14:29:29 +0100, David Dindorp wrote: How about adding a line in the FAQ to the how to build cygwin (104) entry stating that the configure ; make mentioned does produce a Cygwin with all debugging symbols? And the link in the FAQ is wrong: How can I debug cygwin (entry 105) says: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102.; The above should point to entry 104, not 102. Sorry, I'll fix this. -- 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 (FAQ alert?)
On Wed, 26 Jan 2005 14:36:50 -0800, Joshua Daniel Franklin wrote: On Wed, 26 Jan 2005 14:29:29 +0100, David Dindorp wrote: And the link in the FAQ is wrong: How can I debug cygwin (entry 105) says: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102.; The above should point to entry 104, not 102. Sorry, I'll fix this. Fixed. By the way, does anyone know exactly what Devel packages are required to build Cygwin? I used to just think install everything but now there's a lot of new X or GNOME related stuff. I know I've got more than I need installed, but I'm thinking that would be useful information for the FAQ and/or a README in CVS. binutils gcc make gettext-devel ?? -- 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 (FAQ alert?)
Joshua Daniel Franklin wrote: Fixed. By the way, does anyone know exactly what Devel packages are required to build Cygwin? I used to just think install everything but now there's a lot of new X or GNOME related stuff. I know I've got more than I need installed, but I'm thinking that would be useful information for the FAQ and/or a README in CVS. binutils gcc make gettext-devel ?? I was actually a little curious about this, so I did a little experiment. I sequestered away my normal Cygwin installation and started with a fresh install. Aside from the default base packages that setup.exe intstalls out of the gate, I found that I only had to actually select three packages in setup: gcc, make, and perl. (and Perl was required only for gendef it seems.) After doing that I was able to build the Cygwin DLL from the source package. Additional things may be required to build from a CVS checkout, I'm not sure. And of course the dependencies of those packages are required (i.e. gcc brings in w32api, binutils, mingw-runtime, ...; perl brings in crypt, expat, ...) but from a user standpoint if you're using setup those are apparently the only three individual packages you need to select. If you want an absolute list, here is my cygcheck -c for this test environment, which was the result of default install plus selecting gcc, make, and perl: Cygwin Package Information Package VersionStatus _update-info-dir 00231-1OK ash 20040127-1 OK base-files 3.2-1 OK base-passwd 2.1-1 OK bash 2.05b-16 OK binutils 20041229-1 OK bzip21.0.2-6OK coreutils5.2.1-5OK crypt1.1-1 OK cygutils 1.2.5-1OK cygwin 1.5.12-1 OK cygwin-doc 1.4-1 OK diffutils2.8.7-1OK editrights 1.01-1 OK expat1.95.8-1 OK findutils20041227-1 OK gawk 3.1.4-3OK gcc 3.3.3-3OK gcc-core 3.3.3-3OK gcc-g++ 3.3.3-3OK gcc-mingw-core 20040810-1 OK gcc-mingw-g++20040810-1 OK gdbm 1.8.3-7OK grep 2.5-1 OK groff1.18.1-2 OK gzip 1.3.5-1OK less 381-1 OK libbz2_1 1.0.2-6OK libcharset1 1.9.2-1OK libdb4.2 4.2.52-1 OK libgdbm 1.8.0-5OK libgdbm-devel1.8.3-7OK libgdbm3 1.8.3-3OK libgdbm4 1.8.3-7OK libiconv 1.9.2-1OK libiconv21.9.2-1OK libintl1 0.10.40-1 OK libintl2 0.12.1-3 OK libintl3 0.14.1-1 OK libncurses5 5.2-1 OK libncurses6 5.2-8 OK libncurses7 5.3-4 OK libncurses8 5.4-1 OK libpcre 4.1-1 OK libpcre0 4.5-1 OK libpopt0 1.6.4-4OK libreadline4 4.1-2 OK libreadline5 4.3-5 OK libreadline6 5.0-1 OK login1.9-7 OK make 3.80-1 OK man 1.5o1-1OK mingw-runtime3.7-1 OK mktemp 1.5-3 OK ncurses 5.4-1 OK perl 5.8.6-2OK readline 5.0-1 OK sed 4.1.2-1OK tar 1.13.25-5 OK termcap 20021106-2 OK terminfo 5.4_20041009-1 OK texinfo 4.7-2 OK w32api 3.2-1 OK which1.6-1 OK zlib 1.2.2-1OK Brian -- 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 (using snapshot)
Cristopher Faylor wrote: Again, this doesn't address your immediate concern. A snapshot is your best bet. Using the snapshot in the test environment, I now get these errors: sleep.exe (1924): *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 Any ideas why this occurs? Can you send your cygcheck output (as an attachment) and a sample script which demonstrates this problem? Sure, I can try and make a test case. But only if you care about it, because I've kinda dropped the snapshot idea for now, in favor of trying different versions of Cygwin or compiling using one of the 'src' packages. -- 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 (FAQ alert?)
Cristopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. On your particular system which is tuned to do precisely this, maybe. If it's as easy as you say, I'll spend some more time on it. Have you even tried it? No. For a couple of reasons. 1. Prior experience with compiling large open source projects have shown me that it usually takes intimate knowledge of the source code and what tools and operating system should be used in order to make a good compile. 2. Other peoples posting suggested compiling Cygwin is not a walk in the park. 3. I had no idea of the --enable-debugging option that creates a debug version, or any of the other requirements for making the source compile (I'm sure there exists some). 4. I hate to bug the list with stupid questions on how to compile Cygwin, when all I really need is to retrieve more debug information from a running system, not compile a new one. 5. Probably more reasons. Nobody cares, so I'm going to stop the listing here :-). I just tried a regular (non-debug) compile, compiling the freshest source that comes with the stock 1.5.10, using GCC etc. from 1.5.10. It stopped compiling with this error message: /winsup/cygwin/errno.cc:154: error: external linkage required for symbol 'const char* const _sys_errlist[]' because of 'dllexport' attribute. The cause for this particular compile error is probably some minor technicality, but add up a dozen of these, and I will soon have spent a month just trying to make myself a debug DLL to match my 1.5.10 :-(. I've seen advice elsewhere to simply migrate through Cygwin versions until I happen to bump into one that works with the application in question. With limited time on my hands (I can't devote a month to finding out how to compile Cygwin proper), I think that that's maybe the most viable solution so far?.. Otherwise I may put some more effort into the whole compilation thing. There's another version of the source that comes with stock 1.5.10 which so far only complains about missing 'w32api'-something, so maybe I'll have more luck with that. -- 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 (FAQ alert?)
On Tue, 25 Jan 2005, David Dindorp wrote: Cristopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. On your particular system which is tuned to do precisely this, maybe. If it's as easy as you say, I'll spend some more time on it. Have you even tried it? No. For a couple of reasons. [snip] 3. I had no idea of the --enable-debugging option that creates a debug version, or any of the other requirements for making the source compile (I'm sure there exists some). Umm, that was my bad. The thing is, --enable-debugging really produces a developer debug version, with extra tracing, etc. If all you want is a version of DLL with all the symbols (i.e., unstripped), the regular build produces that as well. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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 (FAQ alert?)
On Tue, Jan 25, 2005 at 04:07:18PM -0500, Igor Pechtchanski wrote: On Tue, 25 Jan 2005, David Dindorp wrote: Cristopher Faylor wrote: Actually, we do. We provide the source code. It's easy to build. On your particular system which is tuned to do precisely this, maybe. If it's as easy as you say, I'll spend some more time on it. Have you even tried it? No. For a couple of reasons. [snip] 3. I had no idea of the --enable-debugging option that creates a debug version, or any of the other requirements for making the source compile (I'm sure there exists some). Umm, that was my bad. The thing is, --enable-debugging really produces a developer debug version, with extra tracing, etc. If all you want is a version of DLL with all the symbols (i.e., unstripped), the regular build produces that as well. ...and now you get to repeat these facts endlessly as people find your words in the archives and assume that they need use this option regardless of follow-on discussion or the FAQ. 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 (FAQ alert?)
On Sat, Jan 22, 2005 at 03:42:15PM -0800, Joshua Daniel Franklin wrote: Yep, I missed that. It's gone, but with the other FAQ additions it moved: http://cygwin.com/faq/faq0.html#SEC104 On Sat, 22 Jan 2005 18:46:41 -0500, Christopher Faylor wrote: This feels vaguely like I'm programming in Fortran again. It would be nice (tm, (C), etc.) if there was some way to put permanent anchors in the FAQ so that we wouldn't have to rely on renumbered sections. Isn't there any way to accomplish that? Not that I know of with Texinfo, even the GNU Texinfo manual's HTML version uses numbered anchors: http://gnu.hands.com/manual/texinfo-4.0/html_chapter/texinfo_4.html#SEC35 I could do it with DocBook's FAQ stuff, as in this example: http://www.miwie.org/docbook-dsssl-faq.html#COLOUREDLINKS I'd kinda like to get everything in DocBook anyway. -- 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 (FAQ alert?)
OK the three FAQs beginning at http://cygwin.com/faq/faq0.html#SEC102 now read: How do I build Cygwin on my own? First, you need to get the Cygwin source. Ideally, you should check out what you need from CVS (http://cygwin.com/cvs.html). This is the preferred method for acquiring the sources. Otherwise, you can install the cygwin source package from the distribution. If you are trying to duplicate a cygwin release then you should just download the corresponding source package and use tar xjf to unpack it. This will unpack the sources into a directory named cygwin-x.y.z-n, where x.y.z-n correspond to the version numbering of the tar.bz2 package. tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 You must build cygwin in a separate directory from the source, so create something like a `build/' directory. You will also want to install to a temporary location: mkdir build mkdir /install cd build (../configure --prefix=/install -v; make) make.out make install install.log 21 Normally, this procedure ignore errors in building the documentation. which requires the `docbook-xml', `docbook-xsl', and `xmlto' packages. For more information on building the documentation, see the README included in the cygwin-doc package. To check a cygwin1.dll, run make check in the winsup/testsuite directory. If that works, install everything except the dll (if you can). Then, close down all cygwin programs (including bash windows, inetd, etc.), save your old dll, and copy the new dll to the correct place. Then start up a bash window, or run a cygwin program from the Windows command prompt, and see what happens. If you get the error shared region is corrupted it means that two different versions of cygwin1.dll are running on your machine at the same time. Remove all but one. I may have found a bug in Cygwin, how can I debug it (the symbols in gdb look funny)? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so we recommend trying the latest snapshot from http://cygwin.com/snapshots/ or build the DLL from CVS. To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). How can I compile Cygwin for an unsupported platform (PowerPC, Alpha, ARM, Itanium)? Unfortunately, this will be difficult. Exception handling and signals support semantics and args have been designed for x86 so you would need to write specific support for your platform. We don't know of any other incompatibilities. Please send us patches if you do this work! -- 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 (FAQ alert?)
On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). You must have missed my post where I said not to use the --enable-debugging option. Please remove the mention of the --enable-debugging option. This should only be done when you've been prompted to do so. It's for developers, not for normal users. 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 (FAQ alert?)
On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). On Sat, 22 Jan 2005 16:06:43 -0500, Christopher Faylor wrote: You must have missed my post where I said not to use the --enable-debugging option. Please remove the mention of the --enable-debugging option. This should only be done when you've been prompted to do so. It's for developers, not for normal users. Yep, I missed that. It's gone, but with the other FAQ additions it moved: http://cygwin.com/faq/faq0.html#SEC104 -- 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 (FAQ alert?)
On Sat, Jan 22, 2005 at 03:42:15PM -0800, Joshua Daniel Franklin wrote: On Sat, Jan 22, 2005 at 11:36:00AM -0800, Joshua Daniel Franklin wrote: To build a debugging version of the Cygwin DLL, you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102, adding the `--enable-debugging' option to `../configure'. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). On Sat, 22 Jan 2005 16:06:43 -0500, Christopher Faylor wrote: You must have missed my post where I said not to use the --enable-debugging option. Please remove the mention of the --enable-debugging option. This should only be done when you've been prompted to do so. It's for developers, not for normal users. Yep, I missed that. It's gone, but with the other FAQ additions it moved: http://cygwin.com/faq/faq0.html#SEC104 This feels vaguely like I'm programming in Fortran again. It would be nice (tm, (C), etc.) if there was some way to put permanent anchors in the FAQ so that we wouldn't have to rely on renumbered sections. Isn't there any way to accomplish that? 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
It's a bit more complicated than that, but thank you for the valuable input :-). Gary R. Van Sickle wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Dindorp Sent: Thursday, January 20, 2005 1:13 PM To: Cygwin List Subject: Re: cygwin bughunt Larry Hall wrote: I have the following suggestions/questions: 1. Did you try a Cygwin 1.5.12 or even a snapshot? No. I'm using 1.5.10, and it still smells *real* fresh, I think ;-). Step 1: Update Cygwin. Step 2: Step 3: Profit! -- Gary R. Van Sickle -- 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 (fyi)
Christopher Faylor wrote: David Dindorp wrote: The snapshots page says that it's a stripped version. Who should I trust, the snapshot page or the FAQ? You should trust me when I tell you that the snapshots haven't been stripped recently. You sound authoritative. I'll do that. There's an 8MB and 1MB version, I'll use the larger one. A new version using the debug dll is running in test environments, when it passes that it will be installed on the failing box. I'll be back when I have some better debug information :-). Thanks for all the helpful info (to all of you)! -- 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 (more FAQ stuff)
Joshua Daniel Franklin wrote: Well, how about this then: [snip] Here's my shot at what would've helped me a lot when I initially faced problems. Of course providing as much info as below will only leave you with more newbies crying 'cygwin_split_path() : 0x61073e06' or such. + More information. Good for newbies (like me). + Basically I think it was two different questions, so splitted them up. - Lengthier. I may have found a bug in Cygwin, how can I debug it? You can use GDB [link to GDB description?] to debug the failing application. Using the 'backtrace' command within GDB will tell you which, if any, cygwin functions are being executed at the time that your application is failing. GDB works on core files generated during segmentation faults or using the 'dumper.exe' utility. It can also debug live processes. In order to properly use GDB, you must have debugging symbols enabled, and (when using a core dump file) preferably run GDB on the machine where the failure occurred. See [next item] and [next next item]. GDB does not show any function names (only ???) when debugging core files? In order for GDB to look up function names, it needs to be able to find binary files that match the version(s) that was used when the core dump was generated. This usually means that the easiest way to get the correct output is to run GDB on the machine where the crash originally occurred. Also avoid upgrading that particular machine (Cygwin and OS) until you are done debugging. If you need to debug on a different machine, you can get the relevant DLL and EXE files from the original machine and stuff them in the same paths as they originally resided. Run GDB on the core file and run 'info dll' to get the names of the files needed. Alternatively, if using 'dumper.exe', do a verbose run and grab the filenames like this: dumper -d filename winpid | grep added module. The symbols in gdb are missing or look funny (eg. are just hex values)? Debugging symbols are stripped from distributed Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to follow the instructions at [/faq/faq_3.html#SEC102] to build your own debugging version. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is very welcome). Mangle and/or ridicule as you see fit :-). -- 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 (FAQ alert?)
On Jan 20 17:00, Pierre A. Humblet wrote: On Thu, Jan 20, 2005 at 12:47:33PM -0800, Joshua Daniel Franklin wrote: Sure, how about this: I've found a bug in Cygwin, how can I debug it? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ This must be modulated by the warnings on the snapshot page, so I would recommend an initial step: write to the list, describe the bug and ask for a recommended snapshot. Should we also provide an optional cygwin_debug package, with only an unstripped cygwin1.dll.debug ? I don't think so. I don't recall that any Linux distro contains a debug-enabled kernel. I guess, those who feel confident to debug the kernel (here: the Cygwin DLL), should be able to build their own debug version. 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 (FAQ alert?)
Christopher Faylor wrote: ..snip.. The snapshots page says that it's a stripped version. Who should I trust, the snapshot page or the FAQ? You should trust me when I tell you that the snapshots haven't been stripped recently. However, oops, this means that the advice of using a snapshot shouldn't go into the FAQ since this isn't a permanent arrangement. Out of curiosity, would it make sense to always build the snapshot with the debug info? Thinking about the 'hierarchy of ignorance' for want of a better term, does it require more knowledge to run gdb and give a sensible report or to build the dll and then do the same? I don't think I'm putting this very well, but it may make the FAQ easier if the standard advice is to load the snaphot and use that for debugging, it removes a separate layer of potential problems in building the dll. I suspect the people who would want a stripped snapshot to be more capable of producing it than those would may need to build one with debug info. Bill -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.tigris.org This e-mail transmission is strictly confidential and intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information and if you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this email in error, please reply to the sender as soon as possible and delete the message. Please note that we are able to, and reserve the right to, monitor e-mail communications passing through our network. The views expressed in this email are not that of the company unless specified within the message. The inclusion of this footnote indicates that the mail message and any attachments have been checked for the presence of known viruses. If you have any comments regarding our policy please direct them to [EMAIL PROTECTED] This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com -- 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 (FAQ alert?)
On Jan 21 11:18, Hughes, Bill wrote: I don't think I'm putting this very well, but it may make the FAQ easier if the standard advice is to load the snaphot and use that for debugging, it removes a separate layer of potential problems in building the dll. I suspect the people who would want a stripped snapshot to be more capable of producing it than those would may need to build one with debug info. IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. I'm wondering how somebody should be able to debug an application at all, if this person stumbles over using the compiler tools. 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 (FAQ alert?)
Corinna Vinschen wrote: On Jan 21 11:18, Hughes, Bill wrote: I don't think I'm putting this very well, but it may make the FAQ easier if the standard advice is to load the snaphot and use that for debugging, it removes a separate layer of potential problems in building the dll. I suspect the people who would want a stripped snapshot to be more capable of producing it than those would may need to build one with debug info. IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. I'm wondering how somebody should be able to debug an application at all, if this person stumbles over using the compiler tools. Which is why I asked, I suspect I was hoping there was a way to help newbies (like me in this respect) to generate useful reports in cases of suspected bugs for the more knowledgeable to read. Of course if there were such a way I would expect someone else to have thought of it, and so it's probably impracticable. Thanks for the reply, Bill -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.tigris.org This e-mail transmission is strictly confidential and intended solely for the person or organisation to whom it is addressed. It may contain privileged and confidential information and if you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. If you have received this email in error, please reply to the sender as soon as possible and delete the message. Please note that we are able to, and reserve the right to, monitor e-mail communications passing through our network. The views expressed in this email are not that of the company unless specified within the message. The inclusion of this footnote indicates that the mail message and any attachments have been checked for the presence of known viruses. If you have any comments regarding our policy please direct them to [EMAIL PROTECTED] This email has been scanned for all viruses by the MessageLabs Email Security System. For more information on a proactive email security service working around the clock, around the globe, visit http://www.messagelabs.com -- 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 (out-of-the-box debugging)
Bill Hughes wrote: I don't think I'm putting this very well, but it may make the FAQ easier if the standard advice is to load the snaphot and use that for debugging, it removes a separate layer of potential problems in building the dll. And there's still the issue that problems that are notoriously hard to debug, ie. transient/sporadic issues such as race conditions are subject to timing differences and therefore miniscule changes in code. A different compile will yield different results, and will seemingly correct some issues in some environments even if the bug in question has not been fixed. So even if it is usually the best thing to grab the newest snapshot to see if the problem should by chance be fixed, I think there is some problems that need to be debugged against the version on which they were discovered. Having a ready and available debug version built on the same PC and based on the same source as the stock Cygwin binaries is in this case the sane option, IMHO. (A separate symbols file that doesn't interfer with the binaries would as mentioned earlier be even better.) Personally, I of course have other reasons for wanting a ready-made debug version. Foremost, because I have Cygwin installed in production environments where I can't just go around and replace binaries with snapshot versions as I please. Things here and there could potentially break from release to release, and it seems that they tend to do :-) I can very well understand and accept if I contact the mailing list and get told, if you're not using the latest snapshot, you're gonna have to locate and pin your bugs yourself. It could even be a FAQ entry. But having a ready-made version available just makes life so much easier for people like me who - Don't have a clue how the Cygwin sources are arranged - Have no idea of the proper way compile it - Couldn't fix a compile error if the solution slapped me in the face - Will probably do something wrong, end up with a maimed binary and spam the list with new stupid questions on how to do proper compiles and fix bizarre compile-related problems. I'm of course happily ignoring the whole aspect of leaving out the debug version forces a bunch of people to learn the intimacies of the Cygwin source so that they are able to compile it, thereby increasing the number of potential Cygwin developers. Honestly I think that it's better to provide the debug version and thereby point people to the right location in the source code, than to force people to spend weeks trying to make a succesful compile first. Opinions probably vary on this.. To sum it up, Pros: + Debugging race conditions et al possible + Debugging production systems possible + Shorter time to locate bugs? + Saner bug reports? Cons: - Less people forced to learn themselves to compile Cygwin From my point of view, out-of-the-box debugging would be SO nice. Regards /david PS. I'm new to the newsgroup, and already being cocky. I'm sorry. -- 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 (using snapshot)
Again, this doesn't address your immediate concern. A snapshot is your best bet. Using the snapshot in the test environment, I now get these errors: rm.exe (2512): *** MapViewOfFileEx(0x1D0, in_h 0x1D0) failed, Win32 error 6 awk.exe (1164): *** MapViewOfFileEx(0x1B0, in_h 0x1B0) failed, Win32 error 6 cat.exe (2712): *** MapViewOfFileEx(0x34C, in_h 0x34C) failed, Win32 error 6 date.exe (2580): *** MapViewOfFileEx(0x19C, in_h 0x19C) failed, Win32 error 6 cp.exe (2512): *** MapViewOfFileEx(0x17C, in_h 0x17C) failed, Win32 error 6 sleep.exe (2688): *** MapViewOfFileEx(0x230, in_h 0x230) failed, Win32 error 6 awk.exe (1336): *** MapViewOfFileEx(0x234, in_h 0x234) failed, Win32 error 6 date.exe (2348): *** MapViewOfFileEx(0x350, in_h 0x350) failed, Win32 error 6 awk.exe (2180): *** MapViewOfFileEx(0x258, in_h 0x258) failed, Win32 error 6 date.exe (2712): *** MapViewOfFileEx(0x350, in_h 0x350) failed, Win32 error 6 awk.exe (2380): *** MapViewOfFileEx(0x348, in_h 0x348) failed, Win32 error 6 date.exe (2288): *** MapViewOfFileEx(0x350, in_h 0x350) failed, Win32 error 6 wc.exe (1116): *** MapViewOfFileEx(0x208, in_h 0x208) failed, Win32 error 6 sleep.exe (1924): *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 which.exe (2572): *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 Error: Required executable awk not found. Aborting... The last line is the script exiting because it can't find awk with if [ ! -x `which awk` ]. Error 6 means 'invalid handle'. Any ideas why this occurs? Regards /david -- 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 12:44:39PM +0100, Corinna Vinschen wrote: On Jan 20 17:00, Pierre A. Humblet wrote: This must be modulated by the warnings on the snapshot page, so I would recommend an initial step: write to the list, describe the bug and ask for a recommended snapshot. Should we also provide an optional cygwin_debug package, with only an unstripped cygwin1.dll.debug ? I don't think so. I don't recall that any Linux distro contains a debug-enabled kernel. I guess, those who feel confident to debug the kernel (here: the Cygwin DLL), should be able to build their own debug version. Except that Cygwin changes at a high rate. Debugging a transient problem that shows up on 1.5.12 with the current cvs is taking a gamble. There is a high probability you will first stumble on another bug. If you have a debug dll, you can debug from a dump, or use the debug dll in a production environment with just in time debugging enabled. Once the bug is found, you may conclude it's gone from cvs, but that's a firm (and satisfactory) conclusion. On the other hand if you can't reproduce the bug with cvs, you don't know if it's really gone ot if its likelihood is just reduced. Pierre -- 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 (fyi)
On Fri, Jan 21, 2005 at 10:38:35AM +0100, David Dindorp wrote: Christopher Faylor wrote: David Dindorp wrote: The snapshots page says that it's a stripped version. Who should I trust, the snapshot page or the FAQ? You should trust me when I tell you that the snapshots haven't been stripped recently. You sound authoritative. I'll do that. There's an 8MB and 1MB version, I'll use the larger one. The 8MB is a tar file. The 1MB is just the compressed dll. 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 (more FAQ stuff)
On Fri, Jan 21, 2005 at 10:47:20AM +0100, David Dindorp wrote: Joshua Daniel Franklin wrote: Well, how about this then: [snip] Here's my shot at what would've helped me a lot when I initially faced problems. Of course providing as much info as below will only leave you with more newbies crying 'cygwin_split_path() : 0x61073e06' or such. I don't think the cygwin FAQ should tell people how to debug. My intent for the FAQ was only to mention that normal cygwin DLLs do not contain enough information for a backtrace to be useful. I do not want to imply that we will help people debug either the cygwin DLL or their applications in gdb. I was just hoping to provide some clarification to people who already know about gdb but do not know that the cygwin DLL is stripped. Joshua, do you think you could rejigger the entry to just say something like the above? It doesn't have to be a long entry and it doesn't have to try to help people run the debugger. 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 01:15:53PM +0100, Corinna Vinschen wrote: On Jan 21 11:18, Hughes, Bill wrote: I don't think I'm putting this very well, but it may make the FAQ easier if the standard advice is to load the snaphot and use that for debugging, it removes a separate layer of potential problems in building the dll. I suspect the people who would want a stripped snapshot to be more capable of producing it than those would may need to build one with debug info. IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. I'm wondering how somebody should be able to debug an application at all, if this person stumbles over using the compiler tools. cgf, waves and points. See, Corinna is being mean here! It's not just me! (although I've made similar observations in the past) Maybe someone will prove me wrong but it seems likely that this is a basically an entry examination. If you can't figure out how to build cygwin, then you probably aren't going to provide much in the way of useful feedback if you had a debuggable version. I would also submit that, IMO, helping people run a debugger and figure things out in the debugger is an order of magnitude more difficult than providing basic tech support The debugger is only marginally more useful when the debugging symbols are available anyway. You still need the source code to do anything really worthwhile. 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 (FAQ alert?)
On Fri, 21 Jan 2005, Christopher Faylor wrote: On Fri, Jan 21, 2005 at 01:15:53PM +0100, Corinna Vinschen wrote: On Jan 21 11:18, Hughes, Bill wrote: I don't think I'm putting this very well, but it may make the FAQ easier if the standard advice is to load the snaphot and use that for debugging, it removes a separate layer of potential problems in building the dll. I suspect the people who would want a stripped snapshot to be more capable of producing it than those would may need to build one with debug info. IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. I'm wondering how somebody should be able to debug an application at all, if this person stumbles over using the compiler tools. cgf, waves and points. See, Corinna is being mean here! It's not just me! (although I've made similar observations in the past) She learned from the best... :-D Maybe someone will prove me wrong but it seems likely that this is a basically an entry examination. If you can't figure out how to build cygwin, then you probably aren't going to provide much in the way of useful feedback if you had a debuggable version. Pierre already submitted an argument against this (the likelihood of the bug may be reduced in CVS). Here's another argument: it is sometimes impractical to either replace the existing DLL or replicate the same exact environment for a debug version. Why not debug exactly what fails? Besides, since the releases aren't tagged in CVS (yes, that old quibble again), it's a gamble on whether you're even building the right version... I would also submit that, IMO, helping people run a debugger and figure things out in the debugger is an order of magnitude more difficult than providing basic tech support Agreed. So we don't teach them to debug, we simply provide them with debugging symbols. The debugger is only marginally more useful when the debugging symbols are available anyway. You still need the source code to do anything really worthwhile. Also agreed. But the source provided in the cygwin source package is worthless for debugging, since one can't build Cygwin from that source. If debugger symbols were available, that source would actually be useful. :-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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 (FAQ alert?)
On Jan 21 11:53, Igor Pechtchanski wrote: On Fri, 21 Jan 2005, Christopher Faylor wrote: On Fri, Jan 21, 2005 at 01:15:53PM +0100, Corinna Vinschen wrote: IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. I'm wondering how somebody should be able to debug an application at all, if this person stumbles over using the compiler tools. cgf, waves and points. See, Corinna is being mean here! It's not just me! (although I've made similar observations in the past) She learned from the best... :-D I'm slowly getting the drift ;-) 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 (FAQ alert?)
Corinna Vinschen wrote: IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. The only reason that the above is true is because you do not provide the means for people to debug the Cygwin DLL properly. I'm wondering how somebody should be able to debug an application at all, if this person stumbles over using the compiler tools. In the real world there is no strong binding between being able to compile a properly functioning Cygwin DLL, and being able to look through the source code, follow the developer's chain of thought and figuring out why things do not work given the appropriate debug information. You imply that in order to compile a working Cygwin, an intelligence quotient of X is required, while in order to debug it, a higher intelligence quotient X + Y is required. That's just not true. Entirely different sets of skills are involved. I'll admit though that being able to compile a functioning Cygwin makes debugging easier by removing a lot of the brain work required, and replacing it with simple trial-and-error. That approach is unfortunately just plain impossible when it comes to race conditions (eg.) or production systems. -- 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 11:53:25AM -0500, Igor Pechtchanski wrote: Also agreed. But the source provided in the cygwin source package is worthless for debugging, since one can't build Cygwin from that source. If debugger symbols were available, that source would actually be useful. :-) Huh? tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out This builds a cygwin DLL. Just tried it. Since all of your arguments were presupposing something to do with CVS, I assume that this addresses your concerns. You don't need CVS and I did not say that you had to use CVS. It does make sense to check CVS or a snapshot to see if your problem is fixed before you go to any effort trying to debug a problem, however. 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 (FAQ alert?)
On Fri, 21 Jan 2005, Christopher Faylor wrote: On Fri, Jan 21, 2005 at 11:53:25AM -0500, Igor Pechtchanski wrote: Also agreed. But the source provided in the cygwin source package is worthless for debugging, since one can't build Cygwin from that source. If debugger symbols were available, that source would actually be useful. :-) Huh? tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out This builds a cygwin DLL. Just tried it. Whoops! Apologies for providing outdated information... At some point this required a CVS version of w32api, IIRC. For the archives, adding --enable-debugging to ../configure above should build a debug version of the DLL. Since all of your arguments were presupposing something to do with CVS, I assume that this addresses your concerns. Yes, it does. You don't need CVS and I did not say that you had to use CVS. It does make sense to check CVS or a snapshot to see if your problem is fixed before you go to any effort trying to debug a problem, however. True, and others have made this point too. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote: tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out It does make sense to check CVS or a snapshot to see if your problem is fixed before you go to any effort trying to debug a problem, however. Great. Just put the above in the FAQ, plus some words about needing an unstripped dll. Pierre -- 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 02:26:39PM -0500, Igor Pechtchanski wrote: On Fri, 21 Jan 2005, Christopher Faylor wrote: On Fri, Jan 21, 2005 at 11:53:25AM -0500, Igor Pechtchanski wrote: Also agreed. But the source provided in the cygwin source package is worthless for debugging, since one can't build Cygwin from that source. If debugger symbols were available, that source would actually be useful. :-) Huh? tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out This builds a cygwin DLL. Just tried it. Whoops! Apologies for providing outdated information... At some point this required a CVS version of w32api, IIRC. For the archives, adding --enable-debugging to ../configure above should build a debug version of the DLL. I wouldn't suggest doing this unless you've been instructed to do so. This adds extra debugging hooks into cygwin which provide more strace output or pop up the debugger on certain types of situations. The goal here is to build a version of the DLL which is the same as the release. The DLL that gets produced by the above has debugging symbols so this is what is required. 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 02:45:44PM -0500, Pierre A. Humblet wrote: On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote: tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out It does make sense to check CVS or a snapshot to see if your problem is fixed before you go to any effort trying to debug a problem, however. Great. Just put the above in the FAQ, plus some words about needing an unstripped dll. Information about building the DLL is already in the FAQ. 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 02:47:20PM -0500, Christopher Faylor wrote: On Fri, Jan 21, 2005 at 02:45:44PM -0500, Pierre A. Humblet wrote: On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote: tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out It does make sense to check CVS or a snapshot to see if your problem is fixed before you go to any effort trying to debug a problem, however. Great. Just put the above in the FAQ, plus some words about needing an unstripped dll. Information about building the DLL is already in the FAQ. If you refer to http://cygwin.com/faq/faq0.html#SEC102 it has the apparently obsolete information about needing a separate w32api and it recommends to use cvs. Pierre -- 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 05:28:38PM -0500, Pierre A. Humblet wrote: On Fri, Jan 21, 2005 at 02:47:20PM -0500, Christopher Faylor wrote: On Fri, Jan 21, 2005 at 02:45:44PM -0500, Pierre A. Humblet wrote: On Fri, Jan 21, 2005 at 02:02:33PM -0500, Christopher Faylor wrote: tar xjf cygwin-1.5.12-1-src.tar.bz2 cd cygwin-1.5.12-1 mkdir build cd build (../configure; make) make.out It does make sense to check CVS or a snapshot to see if your problem is fixed before you go to any effort trying to debug a problem, however. Great. Just put the above in the FAQ, plus some words about needing an unstripped dll. Information about building the DLL is already in the FAQ. If you refer to http://cygwin.com/faq/faq0.html#SEC102 it has the apparently obsolete information about needing a separate w32api and it recommends to use cvs. You included the section where I said it was probably a good idea to use CVS or a snapshot. So, the FAQ is accurate there. You're right that the rest of it should be updated. However, if the fact that the cygwin FAQ entry is mildly inaccurate was a true stumbling block for people who wanted to debug the DLL, then I think we would have seen a complaint about it by now. I think it's pretty clear that the people who are clamoring for this don't really know what they want and assume that a dll with debugging symbols will either enable them to debug the dll without going through the awful rigors of building or they think they would have a better opportunity of having cygwin tech support look at their back traces. Neither is precisely true. However, I have already said that it is on my todo list to try to provide a debuginfo package for cygwin. It will show up in some future release. 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 (using snapshot)
On Fri, Jan 21, 2005 at 04:08:06PM +0100, David Dindorp wrote: Again, this doesn't address your immediate concern. A snapshot is your best bet. Using the snapshot in the test environment, I now get these errors: sleep.exe (1924): *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 which.exe (2572): *** MapViewOfFileEx(0x188, in_h 0x188) failed, Win32 error 6 Error: Required executable awk not found. Aborting... The last line is the script exiting because it can't find awk with if [ ! -x `which awk` ]. Error 6 means 'invalid handle'. Any ideas why this occurs? Can you send your cygcheck output (as an attachment) and a sample script which demonstrates this 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 07:04:50PM +0100, David Dindorp wrote: Corinna Vinschen wrote: IMHO you're looking from the wrong direction. People capable of debugging the Cygwin DLL are usually also capable of building it. The only reason that the above is true is because you do not provide the means for people to debug the Cygwin DLL properly. Actually, we do. We provide the source code. It's easy to build. Have you even tried it? 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/
cygwin bughunt
Does no-one have any information on this? Have I failed to follow the cygwin.com posting guidelines properly? Too little information? Help! :-) Regards /david -Original Message- Hi I need some information on how to debug Cygwin processes. We have a partially cygwin-based project, which are having some problems. The cygwin part of the project has some scripts running in a bash process. The scripts seem to run fine for a random amount of time. Sometimes it's mere minutes or hours, but most often it's a day or two. Suddenly, the script just halts. We had a similar problem once, where one of the cygwin processes ate 100% CPU, this was due to missing Cygwin registry keys. However none of the cygwin-based processes are gobbling up CPU, so this looks like it's perhaps a race condition more than it's an endless loop. The location inside the scripts seems to be less significant, however the problem seems to occur only when child 'bash' processes are in use. I'm guessing that the parent processes are just waiting for their child process, and so it's the inner-most child process that has hung. I've made 4 core dumps of the inner-most child process on 4 different occassions, see them at the bottom of this mail. cygwin_split_path(), getppid() and others seems to be represented in all of them. How can I find out what the problem is from here? Regards, David Here's gdb information from the core files. On my local pc, gdb says Previous frame identical to this frame (corrupt stack?). It doesn't do this when gdb is executed locally where the script ran.. Cygwin dll version 1.5.10. OS is Windows 2000 Service Pack 3 (5.00.2195). === 1st core dump === (gdb) info threads 3 process 2632 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 3776 0x77f839eb in ntdll!ZwReadFile () * 1 process 3648 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073e06 in cygwin_split_path () #3 0x6109afe4 in getppid () #4 0x0005 in ?? () #5 0x0001 in ?? () #6 0x0001 in ?? () = === 2nd core dump === (gdb) info threads 3 process 3720 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 2984 0x77f839eb in ntdll!ZwReadFile () * 1 process 3580 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073e06 in cygwin_split_path () #3 0x6109afe4 in getppid () #4 0x0005 in ?? () #5 0x0001 in ?? () #6 0x0001 in ?? () = === 3rd core dump === (gdb) info threads 3 process 3888 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 3656 0x77f839eb in ntdll!ZwReadFile () * 1 process 3596 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073e06 in cygwin_split_path () #3 0x6109afe4 in getppid () #4 0x0005 in ?? () #5 0x0001 in ?? () #6 0x0001 in ?? () = === 4th core dump === (gdb) info threads 3 process 4252 0x77e88785 in KERNEL32!GetModuleFileNameA () 2 process 3300 0x77f839eb in ntdll!ZwReadFile () * 1 process 4148 0x77f8376e in ntdll!ZwClose () (gdb) bt #0 0x77f8376e in ntdll!ZwClose () #1 0x77e87738 in KERNEL32!CloseHandle () #2 0x61073e06 in cygwin_split_path () #3 0x6109afe4 in getppid () #4 0x0005 in ?? () #5 0x0001 in ?? () #6 0x0001 in ?? () = -- 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
At 12:08 PM 1/20/2005, you wrote: Does no-one have any information on this? Apparently not. ;-) I have the following suggestions/questions: 1. Did you try a Cygwin 1.5.12 or even a snapshot? 2. Is this a local debug build of Cygwin or stock 1.5.10. If the latter, you might find building a debug version is more help. If there is a race issue here, you're going to need to work with the code to find it. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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
Larry Hall wrote: I have the following suggestions/questions: 1. Did you try a Cygwin 1.5.12 or even a snapshot? No. I'm using 1.5.10, and it still smells *real* fresh, I think ;-). Also, the problem only occurs on a customer system which unfortunately I can't go around and upgrade all the time just to see. I don't have regular access to it either. 2. Is this a local debug build of Cygwin or stock 1.5.10. If the latter, you might find building a debug version is more help. Stock 1.5.10. There's a debug version? These are the things I need to know! Found the how-to-debug-cygwin document buried deep in some bz2 file, I'll go read that now. In the above statement, you sort-of imply that building a debug version is wrong if using a stock version.. I should do what then? If there is a race issue here, you're going to need to work with the code to find it. That's what I'm basically trying to do. Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. But then I'm kinda stuck. Stuff that would be REALLY nice to know would for example be: - How do I find the call parameters to this function when it died? I poked around all the info locals/variables etc. commands in GDB and they basically just tell me that there's none to be found. - How do I translate cygwin_split_path() : 0x61073e06 to a source file name and a line number? Thank you for the suggestions (please bring more ;-))! /david -- 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 (FAQ alert?)
On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote: Larry Hall wrote: I have the following suggestions/questions: 1. Did you try a Cygwin 1.5.12 or even a snapshot? No. I'm using 1.5.10, and it still smells *real* fresh, I think ;-). Also, the problem only occurs on a customer system which unfortunately I can't go around and upgrade all the time just to see. I don't have regular access to it either. 2. Is this a local debug build of Cygwin or stock 1.5.10. If the latter, you might find building a debug version is more help. Stock 1.5.10. There's a debug version? These are the things I need to know! Found the how-to-debug-cygwin document buried deep in some bz2 file, I'll go read that now. In the above statement, you sort-of imply that building a debug version is wrong if using a stock version.. I should do what then? If there is a race issue here, you're going to need to work with the code to find it. That's what I'm basically trying to do. Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. I think this has come up often enough to be a FAQ. Joshua? In any event, you do need to either build a debugging version or, possibly, use a snapshot from http://cygwin.com/snapshots/ since those are currently built with debugging turned on. 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 (FAQ alert?)
On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote: Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote: Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. I think this has come up often enough to be a FAQ. Joshua? In any event, you do need to either build a debugging version or, possibly, use a snapshot from http://cygwin.com/snapshots/ since those are currently built with debugging turned on. Sure, how about this: I've found a bug in Cygwin, how can I debug it? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ -- 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 (FAQ alert?)
On Thu, Jan 20, 2005 at 12:47:33PM -0800, Joshua Daniel Franklin wrote: On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote: Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote: Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. I think this has come up often enough to be a FAQ. Joshua? In any event, you do need to either build a debugging version or, possibly, use a snapshot from http://cygwin.com/snapshots/ since those are currently built with debugging turned on. Sure, how about this: I've found a bug in Cygwin, how can I debug it? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ Poifect. 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 (FAQ alert?)
On Thu, 20 Jan 2005, Joshua Daniel Franklin wrote: On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote: Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote: Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. I think this has come up often enough to be a FAQ. Joshua? In any event, you do need to either build a debugging version or, possibly, use a snapshot from http://cygwin.com/snapshots/ since those are currently built with debugging turned on. Sure, how about this: I've found a bug in Cygwin, how can I debug it? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ The entry is good, but the title implies (*GASP*) that there may be bugs in Cygwin. I'd suggest something like I'm debugging within the Cygwin DLL space, and gdb shows garbage symbols. How do I debug Cygwin? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! The Sun will pass between the Earth and the Moon tonight for a total Lunar eclipse... -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT -- 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 (FAQ alert?)
On Thu, Jan 20, 2005 at 04:29:36PM -0500, Igor Pechtchanski wrote: On Thu, 20 Jan 2005, Joshua Daniel Franklin wrote: On Thu, Jan 20, 2005 at 08:12:31PM +0100, David Dindorp wrote: Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. On Thu, 20 Jan 2005 15:04:55 -0500, Christopher Faylor wrote: Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. I think this has come up often enough to be a FAQ. Joshua? In any event, you do need to either build a debugging version or, possibly, use a snapshot from http://cygwin.com/snapshots/ since those are currently built with debugging turned on. Sure, how about this: I've found a bug in Cygwin, how can I debug it? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ The entry is good, but the title implies (*GASP*) that there may be bugs in Cygwin. I'd suggest something like I'm debugging within the Cygwin DLL space, and gdb shows garbage symbols. How do I debug Cygwin? It is guaranteed that there are bugs in cygwin so I don't have any problems with using this terminology. However maybe it could be softented to something like I may have found a bug in Cygwin... An additional entry might be Why do the symbols look funny when I try to debug Cygwin? 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 (FAQ alert?)
On Thu, Jan 20, 2005 at 12:47:33PM -0800, Joshua Daniel Franklin wrote: Sure, how about this: I've found a bug in Cygwin, how can I debug it? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ This must be modulated by the warnings on the snapshot page, so I would recommend an initial step: write to the list, describe the bug and ask for a recommended snapshot. Should we also provide an optional cygwin_debug package, with only an unstripped cygwin1.dll.debug ? Pierre -- 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 (FAQ alert?)
David Dindorp wrote: Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. Christopher Faylor wrote: Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. Isn't there any way to compile the debugging symbols into a separate file that GDB could then play with if it wanted to? Joshua Daniel Franklin wrote: I think this has come up often enough to be a FAQ. Joshua? Sure, how about this: either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ Eep. Totally overlooked the entire FAQ. I apologize!!! The snapshots page says that it's a stripped version. Who should I trust, the snapshot page or the FAQ? Is it considered atrocious to just replace the DLL with a snapshot one and keep the EXE's from stock? Pierre A. Humblet wrote: Should we also provide an optional cygwin_debug package, with only an unstripped cygwin1.dll.debug ? I for one would be eternally grateful :-). FWIW, MySQL AB does the same with MyODBC (in the same 'package' though). I've found it useful a number of times. 'Arigato gozaimasu' *bows*. --david -- 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 (FAQ alert?)
On Fri, Jan 21, 2005 at 12:56:14AM +0100, David Dindorp wrote: David Dindorp wrote: Tracking it down with GDB to cygwin_split_path() : 0x61073e06 was easy. Christopher Faylor wrote: Since cygwin isn't built with debugging symbols, the symbols that you do see in gdb are basically meaningless. Isn't there any way to compile the debugging symbols into a separate file that GDB could then play with if it wanted to? Yes. But it doesn't work quite right on cygwin, or at least didn't the last time I looked at it. It's on my todo to revisit this at some point. However, that doesn't really solve your immediate concern. Joshua Daniel Franklin wrote: I think this has come up often enough to be a FAQ. Joshua? Sure, how about this: either build your own debugging version by following the instructions at http://cygwin.com/faq/faq_3.html#SEC102 or use a current snapshot from http://cygwin.com/snapshots/ Eep. Totally overlooked the entire FAQ. I apologize!!! The snapshots page says that it's a stripped version. Who should I trust, the snapshot page or the FAQ? You should trust me when I tell you that the snapshots haven't been stripped recently. However, oops, this means that the advice of using a snapshot shouldn't go into the FAQ since this isn't a permanent arrangement. Is it considered atrocious to just replace the DLL with a snapshot one and keep the EXE's from stock? No, not at all. Pierre A. Humblet wrote: Should we also provide an optional cygwin_debug package, with only an unstripped cygwin1.dll.debug ? I for one would be eternally grateful :-). FWIW, MySQL AB does the same with MyODBC (in the same 'package' though). I've found it useful a number of times. Again, this doesn't address your immediate concern. A snapshot is your best bet. 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
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Dindorp Sent: Thursday, January 20, 2005 1:13 PM To: Cygwin List Subject: Re: cygwin bughunt Larry Hall wrote: I have the following suggestions/questions: 1. Did you try a Cygwin 1.5.12 or even a snapshot? No. I'm using 1.5.10, and it still smells *real* fresh, I think ;-). Step 1: Update Cygwin. Step 2: Step 3: Profit! -- Gary R. Van Sickle -- 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 (FAQ alert?)
On Thu, 20 Jan 2005 19:24:03 -0500, Christopher Faylor wrote: However, oops, this means that the advice of using a snapshot shouldn't go into the FAQ since this isn't a permanent arrangement. Well, how about this then: I may have found a bug in Cygwin, how can I debug it (the symbols in gdb look funny)? Debugging symbols are stripped from distibuted Cygwin binaries, so any symbols that you see in gdb are basically meaningless. It is also a good idea to use the latest code in case the bug has been fixed, so you will need to follow the instructions at http://cygwin.com/faq/faq_3.html#SEC102 to build your own debugging version. You can also contact the mailing list for pointers (a simple test case that demonstrates the bug is always welcome). -- 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/
