Re: GNU Make 4.0.1 ??? infinite loop on startup
On 2013-10-27 14:51, Christopher Faylor wrote: I downloaded the source code for the above and ran into the problem pretty quickly. make was allocating an ever-increasing amount of memory due to a problem with the processing of eight bit characters with the high-bit set. That caused the character to be interpreted as negative and that caused negative indexing off an array. The upcoming make-4.0-2 release should fix this problem. Was this a problem with the upstream source? Or just a problem with the cygwin build of it? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GNU Make 4.0.1 ??? infinite loop on startup
On 2013-11-02 12:36, Rolf Campbell wrote: On 2013-10-27 14:51, Christopher Faylor wrote: I downloaded the source code for the above and ran into the problem pretty quickly. make was allocating an ever-increasing amount of memory due to a problem with the processing of eight bit characters with the high-bit set. That caused the character to be interpreted as negative and that caused negative indexing off an array. The upcoming make-4.0-2 release should fix this problem. Was this a problem with the upstream source? Or just a problem with the cygwin build of it? Nevermind, just looked it up myself. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: make-4.0-1 (x86 and x86_64)
On 2013-10-11 13:12, Christopher Faylor wrote: I've made a new version of make available for installation. This is a refresh against the newly released make-4.0. The appropriate contents of the NEWS file for this snapshot are below. [...] * New command line option: --output-sync (-O) enables grouping of output by target or by recursive make. This is useful during parallel builds to avoid mixing output from different jobs together giving hard-to-understand results. Original implementation by David Boyce d...@boyski.com. Reworked and enhanced by Frank Heckenbach f.heckenb...@fh-soft.de. Windows support by Eli Zaretskii e...@gnu.org. Whenever I try this under cygwin, I get an error output fcntl(): Invalid argument, even with extremely trivial makefiles and invocations. Make seems to work correctly, but produces error output. echo -e 'all:\n\ttouch $@' m.mk make -O -f m.mk Produces this output: fcntl(): Invalid argument touch all I've tried this using both the 32-bit version and 64-bit version of cygwin 1.7.25 with the same results. Cygwin Configuration Diagnostics Current System Time: Mon Oct 14 14:11:21 2013 Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1 Running in Terminal Service session Path: C:\cygwin64\usr\local\bin C:\cygwin64\bin C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common C:\Program Files (x86)\Intel\iCLS Client C:\Program Files\Intel\iCLS Client C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Program Files (x86)\Common Files\Acronis\SnapAPI C:\Windows\System32\WindowsPowerShell\v1.0 C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files\TortoiseSVN\bin Output from C:\cygwin64\bin\id.exe UID: 1002(rcampbell) GID: 513(None) 513(None) 0(root) 544(Administrators) 555(Remote Desktop Users) 545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows USER = 'rcampbell' PWD = '/home/rcampbell' HOME = '/home/rcampbell' HOMEPATH = '\Users\rcampbell' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Users\rcampbell\AppData\Roaming' ProgramW6432 = 'C:\Program Files' HOSTNAME = 'rolfcampbell' SHELL = '/bin/bash' TERM = 'xterm-256color' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 58 Stepping 9, GenuineIntel' WINDIR = 'C:\Windows' PUBLIC = 'C:\Users\Public' OLDPWD = '/c/ProgramData/Microsoft/Windows/Start Menu/Programs/Cygwin' USERDOMAIN = 'ROLFCAMPBELL' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\ProgramData' windows_tracing_flags = '3' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' !:: = '::\' temp = 'C:\Users\RCAMPB~1\AppData\Local\Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' TMP = '/tmp' USERNAME = 'rcampbell' PROCESSOR_LEVEL = '6' ProgramFiles(x86) = 'C:\Program Files (x86)' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'en_US.UTF-8' USERPROFILE = 'C:\Users\rcampbell' CLIENTNAME = 'ENDLISNIS2' TZ = 'America/Toronto' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\ROLFCAMPBELL' CommonProgramW6432 = 'C:\Program Files\Common Files' PROCESSOR_ARCHITECTURE = 'AMD64' LOCALAPPDATA = 'C:\Users\rcampbell\AppData\Local' HISTCONTROL = 'ignoredups' ProgramData = 'C:\ProgramData' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' HOMEDRIVE = 'C:' COMSPEC = 'C:\Windows\system32\cmd.exe' SYSTEMROOT = 'C:\Windows' PRINTER = 'Microsoft XPS Document Writer (redirected 2)' PROCESSOR_REVISION = '3a09' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '8' SESSIONNAME = 'RDP-Tcp#0' COMPUTERNAME = 'ROLFCAMPBELL' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin64' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin64' HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin\Installations (default) = '\??\c:\cygwin' 783841dc939c0d2e = '\??\C:\Users\rcampbell\Downloads\john179w2\john179' 884da10f51cc3e15 = '\??\D:\cygwin.old' HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: e022582115c10879 Path: C:\cygwin64 c: hd NTFS 68503Mb 85% CP CS UN PA FC OS d: hd NTFS464453Mb 39% CP CS UN PA FC Data e: hd NTFS 44029Mb 89% CP CS UN PA FC VM g: cd N/AN/A
Re: [ANNOUNCEMENT] Updated: make-4.0-1 (x86 and x86_64)
On 2013-10-14 09:35, Andrey Repin wrote: I've tried this using both the 32-bit version and 64-bit version of cygwin 1.7.25 with the same results. Is this happens under mintty or native windows console? Both. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] updated: unison2.40, unison2.45
On 2012-12-10 11:49, Andrew Schulman wrote: The Unison packages for Cygwin have been updated: unison2.40, unison2.45 - new upstream minor updates. Is there any chance you could release a 64-bit build of unison? I've been using the 64-bit build of cygwin for a couple weeks now, and the only package that I regularly use that I couldn't find was unison. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SVN and executable permissions
On 2012-12-05 20:24, Burton Samograd wrote: bartels bart...@mailme.ath.cx writes: Is there way to specify to svn on the command line or though a config file that these types of files should automatically have executable permissions? svn propset svn:executable *your file Any idea why this has to be done with the command line version of svn and not with Tortise? TortoiseSVN lets Windows manage the ACLs for the files checked out. Under most circumstances, this means that *all* files have executable permissions. Cygwin's svn only sets executable permissions if the svn-property is set. This is not a bug in either cygwin, svn, or tortoiseSvn. They just work differently. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.15: svn disk I/O error
On 2012-06-27 14:17, David Rothenberger wrote: Anyway, I'll have a new release available shortly built against the latest SQLite package, so others that want to use TortoiseSVN can try it. I just upgraded to the -5 package, and turned the TSVN icon caching back on, and it very quickly failed in the same way as the -3 package. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.15: svn disk I/O error
On 2012-06-19 05:29, Adam Dinwoodie wrote: Rolf Campbell wrote: $ svn up Updating '.': svn: E200030: disk I/O error, executing statement 'RELEASE s6' svn: E200030: sqlite: unable to open database file svn: E200030: sqlite: unable to open database file $ svn cleanup svn: E200030: disk I/O error, executing statement 'RELEASE s79' snip I've had the same problem, and have found a solution: this appears for me to be an interaction with TortoiseSVN, which I have on my machine and which is entirely unaware of Cygwin. Disabling TortoiseSVN's icon cache has completely resolved the issue for me. You can do this by running TortoiseSVN's Settings program, going to Icon Overlays, and selecting None under Status cache, then hitting Apply. That may explain why Rolf's been hitting this despite apparently having no AV installed. Adam That's a very interesting discovery. I certainly am using TortoiseSVN. There must be some interaction between the most recent version of sqlite and TortoiseSVN's status scanner. I've been playing around with sqlite versions and I've confirmed what others have stated that it's only a problem with v3.7.12.1 and NOT a problem with v3.7.3. I've upgraded back to v3.7.12.1 and disabled TortoiseSVN's icon scanner. It appears to resolve the problem for me as well. I would hate to add TortoiseSVN to the BLODA. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.15: svn disk I/O error
On 2012-06-15 06:37, Warren Young wrote: On 6/14/2012 4:00 PM, Garrison, Jim (ETW) wrote: Why would you think that a disk I/O error was either anti-virus or Cygwin related and not... a disk I/O error? Have you looked in your event logs for errors? It is indeed AV related -- a race between SQLite and AV That's one possibility, but check this out: http://stackoverflow.com/questions/11007024/ tl;dr: someone made the problem go away by rolling my recent 3.7.12 release back to the prior 3.7.3 version. I doubt the problem is in the upstream changes between .3 and .12. I'm more worried about the build option changes. SQLite has a lot of Windows-specific code in it, plus some Cygwin-specific code, too. The build changes override some things to force it to believe it's being built for a more generic POSIX type system. It may be both things: the build option changes that force more I/O calls to go through Cygwin instead of direct to the Win32 API could be tickling BLODA bugs. Yet another possibility is that the build option changes cause a subtle ABI change that will be fixed when SVN is rebuilt against it. Also, I don't think I'm running any A/V software (Windows keeps nagging me that my system is *not* running A/V). I uninstalled it to see if that was the problem before reporting it to this list. Also#2: I'm seeing this problem on a Win7x64 machine, but I also have a WinXPx32 machine which has started exhibiting the same symptoms. That one *is* running Symantec A/V (which I've never had trouble with before). It's a work machine, and I don't have permissions to uninstall A/V, but I'll see if I can convince the IT guy to uninstall it for a while to see if that resolves the problem. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.15: svn disk I/O error
On 2012-06-15 06:37, Warren Young wrote: It is indeed AV related -- a race between SQLite and AV That's one possibility, but check this out: http://stackoverflow.com/questions/11007024/ tl;dr: someone made the problem go away by rolling my recent 3.7.12 release back to the prior 3.7.3 version. I doubt the problem is in the upstream changes between .3 and .12. I'm more worried about the build option changes. SQLite has a lot of Windows-specific code in it, plus some Cygwin-specific code, too. The build changes override some things to force it to believe it's being built for a more generic POSIX type system. It may be both things: the build option changes that force more I/O calls to go through Cygwin instead of direct to the Win32 API could be tickling BLODA bugs. Yet another possibility is that the build option changes cause a subtle ABI change that will be fixed when SVN is rebuilt against it. I've rolled my machine back to to .3 and I'll see if it fixes my system too. Unfortunately, I'm not able to reproduce the problem *at all* this morning with any version of anything. I guess I'll wait and see for now. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin 1.7.15: svn disk I/O error
Recently, I've noticed cygwin svn getting a LOT of errors during operations. I think this started when upgrading from 1.7.14 to 1.7.15, but I can't say for sure. The nature of these errors are as follows: $ svn up Updating '.': svn: E200030: disk I/O error, executing statement 'RELEASE s6' svn: E200030: sqlite: unable to open database file svn: E200030: sqlite: unable to open database file $ svn cleanup svn: E200030: disk I/O error, executing statement 'RELEASE s79' Sometimes the errors happen, sometimes not. It seems to be about 50% of the time svn has this type of error now. I've tried running the exact same version of SVN (the command-line version shipped with TourtoiseSVN) on the exact same working copies and I don't have any errors. I'm not running any anti-virus (I was, but I uninstalled it a couple of days ago to make sure it wasn't causing this trouble). Cygwin Configuration Diagnostics Current System Time: Thu Jun 14 20:43:04 2012 Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1 Running under WOW64 on AMD64 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Windows\System32\WindowsPowerShell\v1.0 C:\Program Files (x86)\Intel\Services\IPT C:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\OEM\DLLShared C:\Program Files (x86)\Common Files\Roxio Shared\OEM\12.0\DLLShared C:\Program Files (x86)\Roxio\OEM\AudioCore C:\Program Files\TortoiseSVN\bin Output from C:\cygwin\bin\id.exe UID: 1001(rcampbell) GID: 513(None) 513(None)545(Users) SysDir: C:\Windows\system32 WinDir: C:\Windows HOME = 'C:\cygwin\home\rcampbell' PWD = '/home/rcampbell' USER = 'rcampbell' ALLUSERSPROFILE = 'C:\ProgramData' APPDATA = 'C:\Users\rcampbell\AppData\Roaming' COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files' COMPUTERNAME = 'DWI-A3380' COMSPEC = 'C:\Windows\system32\cmd.exe' CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files' CommonProgramW6432 = 'C:\Program Files\Common Files' DXSDK_DIR = 'C:\Program Files\Microsoft DirectX SDK (March 2009)\' FP_NO_HOST_CHECK = 'NO' HOMEDRIVE = 'C:' HOMEPATH = '\Users\rcampbell' HOSTNAME = 'dwi-a3380' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' LANG = 'en_US.UTF-8' LOCALAPPDATA = 'C:\Users\rcampbell\AppData\Local' LOGONSERVER = '\\DWI-A3380' MANPATH = '/usr/local/man:/usr/share/man:/usr/man:' NUMBER_OF_PROCESSORS = '8' OLDPWD = '/c/svn/5.6' OS = 'Windows_NT' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC' PRINTER = 'CutePDF Writer' PROCESSOR_ARCHITECTURE = 'x86' PROCESSOR_ARCHITEW6432 = 'AMD64' PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 42 Stepping 7, GenuineIntel' PROCESSOR_LEVEL = '6' PROCESSOR_REVISION = '2a07' PROGRAMFILES = 'C:\Program Files (x86)' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\' PUBLIC = 'C:\Users\Public' ProgramData = 'C:\ProgramData' ProgramFiles(x86) = 'C:\Program Files (x86)' ProgramW6432 = 'C:\Program Files' SESSIONNAME = 'Console' SHELL = '/bin/bash' SHLVL = '1' SYSTEMDRIVE = 'C:' SYSTEMROOT = 'C:\Windows' TEMP = 'C:\cygwin\tmp' TERM = 'xterm' TMP = 'C:\cygwin\tmp' TZ = 'America/New_York' USERDOMAIN = 'DWI-A3380' USERNAME = 'rcampbell' USERPROFILE = 'C:\Users\rcampbell' VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\' VS90COMNTOOLS = 'C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\Tools\' WINDIR = 'C:\Windows' _ = '/usr/bin/cygcheck' temp = 'C:\Users\RCAMPB~1\AppData\Local\Temp' tmp = 'C:\Users\RCAMPB~1\AppData\Local\Temp' windows_tracing_flags = '3' windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin User: Key: c5e39b7a9d22bafb Path: C:\cygwin c: hd NTFS121311Mb 68% CP CS UN PA FC OS d: hd NTFS 1907726Mb 9% CP CS UN PA FC New Volume e: cd N/AN/A z: net NTFS 1907727Mb 8% CP CS UN PA FC Warning: Mount entries should not have a trailing (back)slash C:\cygwin/ system binary,auto C:\ /c system binary D:\ /d system binary E:\ /e system binary F:\ /f system binary G:\ /g system binary
Re: cygwin 1.7.15: svn disk I/O error
On 2012-06-14 15:55, Christopher Faylor wrote: On Thu, Jun 14, 2012 at 03:48:05PM -0400, Rolf Campbell wrote: $ svn cleanup svn: E200030: disk I/O error, executing statement 'RELEASE s79' Sometimes the errors happen, sometimes not. It seems to be about 50% of the time svn has this type of error now. I've tried running the exact same version of SVN (the command-line version shipped with TourtoiseSVN) on the exact same working copies and I don't have any errors. I'm not running any anti-virus (I was, but I uninstalled it a couple of days ago to make sure it wasn't causing this trouble). Why would you think that a disk I/O error was either anti-virus or Cygwin related and not... a disk I/O error? Have you looked in your event logs for errors? cgf I thought it might be anti-virus related because I read another message about someone having a similar problem and he thought it might be anti-virus related. But now I can't find where I was reading that message anymore. Anyway, another reason is because I only experience this error when I use the cygwin version of SVN. Other versions do not run into any errors when accessing the exact same working copies. I just checked my event logs and I don't see any system errors related to I/O. The only error today is about failing to start the PBADRV service. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: v1.7.10 -- forked process died unexpectedly
On 2012-02-08 11:41, marco atzeri wrote: On 2/8/2012 5:30 PM, Rolf Campbell wrote: I get these sporadic failures in my build system after upgrading to 1.7.10. I can't reproduce these consistently, seems to happen randomly every few dozen builds. mkdir -p output/device/1110/source/ 0 [main] make 7900 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741819, errno 11 make: vfork: Resource temporarily unavailable See http://cygwin.com/faq.html at 4.44. How do I fix fork() failures? and related /usr/share/doc/rebase/README Regards Marco Yeah, I normally would rebaseall after seeing a forking issue, but this one wasn't a familiar error message. But I guess the new cygwin version just has slightly different error messages to indicate a need for rebasing. I don't know if this is a good idea, but what if this type of error message included a suggestion to try rebaseall? Might stop messages like mine in the future. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
v1.7.10 -- forked process died unexpectedly
I get these sporadic failures in my build system after upgrading to 1.7.10. I can't reproduce these consistently, seems to happen randomly every few dozen builds. mkdir -p output/device/1110/source/ 0 [main] make 7900 fork: child -1 - forked process died unexpectedly, retry 0, exit code -1073741819, errno 11 make: vfork: Resource temporarily unavailable Cygwin Configuration Diagnostics Current System Time: Wed Feb 08 11:26:50 2012 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Intel\DMIX C:\Program Files\ActivIdentity\ActivClient C:\WINDOWS\system32\WindowsPowerShell\v1.0 C:\Program Files\TortoiseSVN\bin Output from C:\cygwin\bin\id.exe UID: 1009(Rolf) GID: 513(None) 513(None) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'Rolf' PWD = '/c/svn/5-FPGA' HOME = '/home/Rolf' HOMEPATH = '\Documents and Settings\Rolf' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\Rolf\Application Data' HOSTNAME = 'Rolf' DXSDK_DIR = 'C:\Program Files\Microsoft DirectX SDK (March 2009)\' OnlineServices = 'Online Services' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' WINDIR = 'C:\WINDOWS' Platform = 'BPC' OLDPWD = '/c/svn/5' USERDOMAIN = 'ROLF' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' TEMP = '/tmp' VS90COMNTOOLS = 'c:\Program Files\Microsoft Visual Studio 9.0\Common7\Tools\' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'Rolf' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\Rolf' CLIENTNAME = 'Console' TI_SIM_DIR = 'C:\Program Files\Texas Instruments\ccsv4/simulation_csp_omap4/bin/configurations/' TI_CCS_SIM = 'C:\Program Files\Texas Instruments\ccsv4/simulation_csp_omap4/env/ccs/drivers/' XDCROOT = 'C:/Program Files/Texas Instruments/xdctools_3_20_05_76' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\ROLF' CHESSROOT = 'C:\Program Files\Texas Instruments\ccsv4/simulation_csp_omap4/bin/configurations/licenses/' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'CutePDF Writer' PROCESSOR_REVISION = '170a' CCSV4_PHOTON_INSTALL_DIR = 'C:\Program Files\Texas Instruments\ccsv4/simulation/bin/components/photon' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' TI_DIR = 'C:\Program Files\Texas Instruments\ccsv4' SESSIONNAME = 'Console' COMPUTERNAME = 'ROLF' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\Cygwin (default) = (unsupported type) HKEY_CURRENT_USER\Software\NVIDIA Corporation\Global\nView\WindowManagement\xwin\Exceptions\cygwin/x X rl (default) = 0x HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations (default) = '\??\C:\cygwin' ebb4ed95d390b12f = '\??\C:\Program Files\Bugzilla' 185045abbe9b4289 = '\??\C:\Documents and Settings\Rolf\Application Data\Mozilla\Firefox\Profiles\msppduk2.default\extensions\jsobr...@zscaler.com\platform' HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup (default) = 'C:\cygwin' obcaseinsensitive set to 1 Cygwin installations found in the registry: System: Key: c5e39b7a9d22bafb Path: C:\cygwin System: Key: ebb4ed95d390b12f Path: C:\Program Files\Bugzilla System: Key: 185045abbe9b4289 Path: C:\Documents and Settings\Rolf\Application Data\Mozilla\Firefox\Profiles\msppduk2.default\extensions\jsobr...@zscaler.com\platform (ORPHANED) c: hd NTFS152624Mb 98% CP CS UN PA FC d: cd N/AN/A e: fd N/AN/A f: fd FAT32 1882Mb 14% CP
Re: automated cygwin install
On 2011-09-09 09:52, Andrew Schulman wrote: In a new installation, we have to write an (ugh) MSDOS CMD script, since bash isn't available. One way around that would be to install just the base, then run a bash script, but I decided to bite the bullet and write a CMD script that would do it all in one go. Here's what mine looks like: setup.exe ^ --no-shortcuts ^ --quiet-mode ^ --disable-buggy-antivirus ^ --packages ^ aria2,^ atool,^ autoconf,^ automake,^ autossh,^ and so on. Two things to notice: * The caret (^) character at the end of every line is CMD's line continuation character. (Maybe you already knew that, but not being very experienced with CMD, I had to look around to find it out.) * The list of package names is comma-delimited. This doesn't seem to be documented anywhere in the setup help, but the --packages option expects a comma-delimited list of package names. If you space-delimit them, only the first one will be installed and the rest will be ignored. Nirvana. A one-click new Cygwin installation, with all of my favorite packages. I hope it's useful to others. I did something similar a few weeks ago but the trouble I had with running in either semi-unattended or fully unattended mode; there is no initial progress display before it starts to parse the .ini file(s). Since I'm running this from a shortcut, on a network drive, it sits with no indication (at all) that you even correctly double-clicked for between 5 and 10 seconds. People get frustrated and think they didn't properly launch it and try it again, and again, and again only to have 4 or 5 windows eventually pop up. I wish there was a way to get setup to show *something*, anything (even just a splash screen) during a semi-unattended mode before it shows the .ini parsing progress -- to reassure the user that something is happening. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Can't install from ports server (Was: Re: Debug info broken for gcc-4.5.0 (experimental))
On 2011-07-06 04:29, Yaakov (Cygwin/X) wrote: GCC 4.5.3 and GDB 7.2 are available in Ports in the meantime. Yaakov I don't know who maintains the ports server, but when I try to use the instructions on http://sourceware.org/cygwinports/ , and use http://downloads.sourceforge.net/cygwin-ports as my mirror, setup crashes right after downloading setup.bz2. If I use the ftp version as my mirror, things seem to work ok. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Strange cygpath behavior.
On 2011-06-24 11:44, Fahlgren, Eric wrote: Marco atzeri wrote: you are right, but it is not very useful to translate a windows path in a windows path ... On the contrary, it is exceedingly useful to be able to transform long names (with spaces) into short-form names without spaces. $ cygpath -sm $PROGRAMFILES That is only useful on systems that have 8.3 filenames enabled. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: fdisk on cygwin
On 2011-06-17 10:27, PRASANTH RAJAGOPAL wrote: Here is my mount info: *J* is the SD card in SD slot and *K* is the USB stick. PRajagop@PRAJAGOP-L02 /proc $ cat mounts D:/CYgWin/bin /usr/bin ntfs binary,auto 1 1 D:/CYgWin/lib /usr/lib ntfs binary,auto 1 1 D:/CYgWin / ntfs binary,auto 1 1 C: /cygdrive/c ntfs binary,posix=0,user,noumount,auto 1 1 D: /cygdrive/d ntfs binary,posix=0,user,noumount,auto 1 1 I: /cygdrive/i udf binary,posix=0,user,noumount,auto 1 1 J: /cygdrive/j vfat binary,posix=0,user,noumount,auto 1 1 K: /cygdrive/k vfat binary,posix=0,user,noumount,auto 1 1 X: /cygdrive/x ntfs binary,posix=0,user,noumount,auto 1 1 On Fri, Jun 17, 2011 at 7:01 PM, PRASANTH RAJAGOPAL prasanth...@gmail.com wrote: Now I have a problem that the SD card (inserted in to SD slot) is not getting seen from fdisk. A USB stick can be seen though. Note that the card is detected and works properly when accessed from WIndows Vista. I also saw the correct drive J appears in /cygdrive. Yeah, I've seen this before. Some drivers for built-in SD-card readers use *special* drivers that somehow avoid having the raw device visible in the normal way. The way I got around it was to use an external, USB-based card reader. IIRC, the raw disk device doesn't even show up in the disk manager application (under the XP Administrative Tools control panel program), which means this is probably not a cygwin bug. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: {xz/liblzma-devel/liblzma1}-4.999.9beta-11
On 2010-04-17 11:57, Charles Wilson wrote: On 4/17/2010 10:42 AM, Rolf Campbell wrote: This release will not compress a file with multiple hard links, even when forced. I'm running an NTFS drive, and my source file has 2 hard-links to it. Running xz -9evf source.txt prints: xz: source.txt: Input file has more than one hard link, skipping When using 4.999.9beta-10, it correctly compresses that file. Thanks for the report. I'll investigate and report it upstream. -- Chuck Did you ever get a response about this? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygcheck bug: symlinks with unix paths are wrongly resolved
On 2010-10-19 19:17, Arseny Slobodyuk wrote: [snip...] a...@dstar ~ $ ln -s `which cmd.exe` cmd.exe a...@dstar ~ $ cygcheck ./cmd.exe - D:\OTHERBIN\cygwin\cygdrive\d\WINDOWS\system32\cmd.exe cygcheck: could not find './cmd.exe' cygcheck is not a cygwin application, it's a native windows application, so it does not know how to resolve unix paths. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.7 ln .exe magic
test case--- From bash, in an empty directory: $ ln /bin/ls t $ ls t.exe Why does the resulting hard link have a '.exe' suffix on it? I thought that cygwin .exe magic was only appending when listing a file? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fwd: Windows File permissions are not being inherited - Cygwin 1.7 - Windows 7
On 2010-09-01 04:00, Harie Ram wrote: The issue that I am currently facing is : the modify permissions given to the INSTALLDIR C:\Cygwin using the msi lock permission table is being inherited through all the subfolders and files. Any new manually created folders and files anywhere within C:\Cygwin via Windows explorer or via the Cygwin Bash Shell are inheriting permissions. But any new installations done by the user by choosing a package from the Cygwin list are not inheriting the permissions. The installed user who installs the package has full permissions to delete/modify the folder and its contents . But the local admin/administrator/system does not have permissions. It gives an access denied error. These 3 user groups administrators/system/users are not even being listed in the security properties of those installed folders. AFAIK, Cygwin uses POSIX style file permissions, which do not support any type of inherited file permissions. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: associating device names with cygdrive directories
On 2010-08-26 07:26, Corinna Vinschen wrote:
I have another one:
$ for F in /dev/s* ; do echo $F$(cygpath -w $F) ; done
/dev/sda\\.\PhysicalDrive0
/dev/sda1
\\.\STORAGE#Volume#{781f8bd6-7d0d-11de-8012-806e6f6e6963}#0010#{53f5630d-b6bf-11d0-94f2-00a0c91efb8b}
/dev/sda2\\.\Volume{781f8bda-7d0d-11de-8012-806e6f6e6963}
/dev/sda3\\.\D:
but there are two problems.
Up to the current Cygwin 1.7.6 the info from /proc/partitions is
incomplete for non-privileged users. I just checked in a patch to
Cygwin which allows the full partition info also for non-priv'ed users.
Apart from that, the output of cygpath -w for devices isn't overly
helpful yet. I look into improving that a bit.
Corinna
When I run echo /dev/s*, I only get /dev/shm /dev/stderr /dev/stdin
/dev/stdout, how/why is yours showing the drive devices?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Wrong/ inconsistent responses from diff
On 2010-08-23 09:57, Fergus wrote: Somehow diff identifies differences in two identical binary files. In the following example two duplicate files are located (i) in my home directory (/m/home/user) and (ii) at the root of a different drive (D:). [snip] ~ diff -s INTERVAL.pdf /d/INTERVAL.pdf Files INTERVAL.pdf and /d/INTERVAL.pdf differ ~ diff -s ./INTERVAL.pdf /d/INTERVAL.pdf Files ./INTERVAL.pdf and /d/INTERVAL.pdf differ ~ diff -s ~/INTERVAL.pdf /d/INTERVAL.pdf Files /home/user/INTERVAL.pdf and /d/INTERVAL.pdf differ ~ diff -s /home/user/INTERVAL.pdf /d/INTERVAL.pdf Files /home/user/INTERVAL.pdf and /d/INTERVAL.pdf differ ~ diff -s /m/home/user/INTERVAL.pdf /d/INTERVAL.pdf Files /m/home/user/INTERVAL.pdf and /d/INTERVAL.pdf are identical Using XP Pro SP3. This happens with the current cygwin1.dll and the snapshot dated 20100822. Fergus Try using diff --binary -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 2010-08-20 07:56, Corinna Vinschen wrote: Thanks for the new strace. After some more experimenting I was finally able to reproduce the issue. The other problem you reported, about df(*), lead me onto the right track. I've checked my changes in to CVS. For testing I provided another test DLL: I tried both df and find using the new test dll and everything worked perfectly. Thanks for the quick response. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 2010-08-19 12:28, Eric Blake wrote: On 08/19/2010 08:43 AM, Corinna Vinschen wrote: Hmm, digging through Cygwin's readdir code, I have a vague idea. Eric, does find honor the struct dirent d_type flag? I'm wondering if d_type is erroneously set to DT_REG for some reason. If so, we could find this out by augmenting the debug output in the Cygwin DLL. find (but not oldfind) relies heavily on the d_type flag. If that flag is incorrect, it could explain why find gets lost. Could you repeat the experiment with 'oldfind' and see if that behaves better? oldfind displays all 100,000 files. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin 1.7.6: find skipping over some directories on NTFS mount points
On 2010-08-19 18:37, Andrey Repin wrote: If ATI is the junction (reparse point, or however you call it) to a top-level directory on another partition, this behavior could be explained by exiting through the window: process enter the partition from the doors (junction), dig it, then trying to exit from real path, which is, indeed, at the root of partition. So the process finds itself at the top-level and gracefully dies considering work done. A wild guess, however. Unfortunitely, ATI is not the reparse point. The root of the mounted file system is the 3 directory where ATI sits. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
cygwin 1.7.6: df shows wrong (different?) drive information
When I run df -h dir where dir is part of a native-NTFS-mounted-drive, then df prints details about the root drive (not the mounted drive). This acts differently if the drive is *also* mounted as a separate top-level drive. In that case, if you specify the mount point itself, it prints information about the root drive, but if you specify any subdir, then it prints the correct drive information. For example (not actual output): Drive 0, 100G: mounted as C:\ Drive 1, 200G: mounted as C:\1 Drive 2, 300G: mounted as C:\2 and D:\ df -h /cygdrive/c = 100G df -h /cygdrive/c/1 = 100G df -h /cygdrive/c/1/subdir = 100G df -h /cygdrive/c/2 = 100G df -h /cygdrive/c/2/subdir = 300G In cygwin 1.7.5, the output was 100G, 200G, 200G, 300G, and 300G respectively. I should point out that I'm still using that special snapshot Corinna made for me, not the stock 1.7.6. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Should mintty's copy-on-select option be on by default?
On 2010-07-29 08:02, Andy Koppe wrote: On 29 July 2010 08:24, JOHNER Jean 066030 wrote: Thank you for all the answers to my original request below. This was very instructive. In conclusion: - to get middle-mouse paste of the selection with Mintty, Options/Mouse/copy on select had to be checked, which is not the default. Middle button paste really does work fine by default. It pastes whatever is in the clipboard. However, when you select something, it is not automatically placed in the clipboard unless you enable 'Copy on select'. This is a difference in approach between Windows and X11: in X, the selection is automatically made available for pasting, whereas in Windows you need to explicitly copy it to the clipboard using the Copy menu command or one of its keyboard shortcuts. The Windows approach has the advantage that you can select something without clobbering the clipboard content. It has the disadvantage that an additional action is required when you just want to copypaste. Mintty currently defaults to the Windows approach. I've seen enough questions about this though that I'm thinking about changing this. Selecting without copying isn't actually much use in mintty, because the only other thing you can do with a selection is to try to 'Open' it. And I guess most users do come from a Unixy background. Opinions? Andy I've been a Windows user for most of my life, but I still prefer copy-on-select for a terminal. I vote for it being the default. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-23.2-1
On 2010-05-10 06:22, Ken Brown wrote: New releases of the emacs, emacs-X11, and emacs-el packages are now available, 23.2-1, leaving 23.1-10 as previous. I've been using the native W32 port of emacs for years. I tried using the native cygwin build of it and ran into a problem: I can't seem to bind all key combinations. - Alt+F3 (or Alt+any F-key) seem to have no effect at all. - Ctrl+Alt+Shift+5: I bind it using (global-set-key (kbd C-M-% ...), but pressing Ctrl+Alt+Shift+5 results in emacs complaining that M-[ 1 ; 8 u is undefined. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-23.2-1
On 2010-05-13 16:45, Ken Brown wrote: On 5/13/2010 4:31 PM, Rolf Campbell wrote: On 2010-05-10 06:22, Ken Brown wrote: New releases of the emacs, emacs-X11, and emacs-el packages are now available, 23.2-1, leaving 23.1-10 as previous. I've been using the native W32 port of emacs for years. I tried using the native cygwin build of it and ran into a problem: I can't seem to bind all key combinations. - Alt+F3 (or Alt+any F-key) seem to have no effect at all. - Ctrl+Alt+Shift+5: I bind it using (global-set-key (kbd C-M-% ...), but pressing Ctrl+Alt+Shift+5 results in emacs complaining that M-[ 1 ; 8 u is undefined. Are you using emacs in the Cygwin console? If so, many key combinations won't work as you expect. This is documented in /usr/share/doc/Cygwin/emacs.README. You'll have better luck running emacs in mintty. Or for an interface that is more like the native Win32 build, run emacs under X11. Ken Sorry, I should have been more clear, I'm running in mintty. [reading emacs.README ...] Oh, I see. Is there any way to bind the resulting key codes? Can I use M-[ 1 ; 8 u as a key to bind? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: {emacs,emacs-X11,emacs-el}-23.2-1
On 2010-05-13 17:13, Rolf Campbell wrote: On 2010-05-13 16:45, Ken Brown wrote: On 5/13/2010 4:31 PM, Rolf Campbell wrote: On 2010-05-10 06:22, Ken Brown wrote: New releases of the emacs, emacs-X11, and emacs-el packages are now available, 23.2-1, leaving 23.1-10 as previous. I've been using the native W32 port of emacs for years. I tried using the native cygwin build of it and ran into a problem: I can't seem to bind all key combinations. - Alt+F3 (or Alt+any F-key) seem to have no effect at all. - Ctrl+Alt+Shift+5: I bind it using (global-set-key (kbd C-M-% ...), but pressing Ctrl+Alt+Shift+5 results in emacs complaining that M-[ 1 ; 8 u is undefined. Are you using emacs in the Cygwin console? If so, many key combinations won't work as you expect. This is documented in /usr/share/doc/Cygwin/emacs.README. You'll have better luck running emacs in mintty. Or for an interface that is more like the native Win32 build, run emacs under X11. Ken Sorry, I should have been more clear, I'm running in mintty. [reading emacs.README ...] Oh, I see. Is there any way to bind the resulting key codes? Can I use M-[ 1 ; 8 u as a key to bind? To answer my own question: Yes, you can use (global-set-key (kbd M-[ 1 ; 8 u ...)) to bind Ctrl+Alt+Shift+5 in mintty. So, now that I know a better work-around, is this a bug in cygwin, mintty, or cygwin-emacs? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygwin with microsoft remote desktop
On 2010-05-02 06:57, Eric Friedman wrote: Hi all, I am using windows remote desktop to access cygwin on a remote machine with a disk on my local computer remote mounted, via remote desktop. On the remote machine this disk shows up under my computer but is not assigned a drive letter. How do I access it from within cygwin? I can't use \cygwin\letter, since there is no drive letter. If I could get from cygwin bash to my computer on the remote machine that would probably work. thanks, Eric Use //tsclient/letter. For example, to access your local C drive, use //tsclient/C. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ImageMagick shared libraries missing?
On 2010-04-22 01:37, Sivaram Neelakantan wrote: Larry Hall (Cygwin)reply-to-list-only...@cygwin.com writes: On 4/21/2010 11:17 PM, Sivaram Neelakantan wrote: 'cygcheck montage' and 'cygcheck convert' should tell you the missing DLLs. Then usehttp://cygwin.com/packages/ or 'cygcheck -p /bin/foo.dll' to find the package to install. If I had to guess, I'd say you're looking for the libImagemagick1 package if you're just missing the ImageMagick- specific DLLs. Thanks, that worked. It gave me cyggomp-1.dll as not found. I got that and the libImagemagick1 library through the setup from the repository and all is well now. sivaram I've been having the same problem. And while I'm sure that would fix my problem too, this must mean that there is a dependency error for the ImageMagick tools. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] Updated: {xz/liblzma-devel/liblzma1}-4.999.9beta-11
On 2010-04-11 11:54, Charles Wilson wrote: This is routine update to a more recent git snapshot. [[ compiled using gcc-4.3.4-3 ]] CHANGES (since 4.999.9beta-10) o Update to 2010-Apr-01 git snapshot Wed Mar 31 16:47:25 2010 +0300 a1f7a986b8d708f9290da9799ca1b8d7082fad3e o Rebuild using gcc4, against official cygwin-1.7.x release. o Upstream: - Documentation updates - Fix option parsing bug in xz - Fix installation issue on cygwin/mingw. - lzmainfo bugfixes - New lzma_filters_copy(), lzma_physmem(), and io_pread() APIs. - Behavioral modification for filter chain initialization/update: Technically, this is a ABI change, but to date is is only used internally, so I didn't bump the DLL number. - xz now supports --info-memory and --robot options, and a rudimentary implemenation of --list. - Fix various liblzma bugs - liblzma now relies on auto-import, for MinGW/Cygwin - Never accept (or output) compressed data from a tty - xzgrep now supports filenames with spaces This release will not compress a file with multiple hard links, even when forced. I'm running an NTFS drive, and my source file has 2 hard-links to it. Running xz -9evf source.txt prints: xz: source.txt: Input file has more than one hard link, skipping When using 4.999.9beta-10, it correctly compresses that file. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.3: remote bash process left after ssh connection dropped
I run an ssh session between two machines which auto-reconnects when the connection is dropped (it's really just a bash while look that calls ssh). My problem is that after a while, I get an error about being unable to create a tty on the remote system (I'm sorry, but I don't have the exact wording of the error). When I investigated the remote system, I found there were 64 orphaned, bash processes running. Their TTY field in ps -a output nicely listed every number from 0 to 63. Every orphaned bash had it's PPID set to 1. It looks to me like when the remote machine (sshd) lost it's ssh connection, it left bash running and terminated itself. That left one of the TTY's occupied each time until it hit the system limit (which was apparently 64). I expected the bash processes to disappear with sshd process that created them. Is this: 1) A problem with my setup that can be remedied. 2) A problem with cygwin. 3) A problem with ssh. 4) Design intent. Cygwin Configuration Diagnostics Current System Time: Wed Apr 07 11:12:56 2010 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Running in Terminal Service session Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Program Files\Microsoft Office\OFFICE11\ C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Common Files\GTK\2.0\bin C:\Program Files\GNU\GnuPG\pub C:\WINDOWS\system32\WindowsPowerShell\v1.0 F:\QNX641\host\win32\x86\usr\bin C:\Program Files\QNX Software Systems\bin C:\Program Files\TortoiseSVN\bin C:\Program Files\Klocwork\Klocwork 8.1 Server\bin C:\Program Files\Klocwork\Klocwork 8.1 User\bin Output from C:\cygwin\bin\id.exe UID: 13689(rcampbell)GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 1008(Debugger Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS MAKEFLAGS = '-IF:/QNX641/target/qnx6/usr/include' USER = 'rcampbell' PWD = '/f/Quantum' HOME = '/home/rcampbell' HOMEPATH = '\Documents and Settings\rcampbell' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\rcampbell\Application Data' SSH_AGENT_PID = '2992' HOSTNAME = 'rcampbell' VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' QNX_CONFIGURATION = 'C:\Program Files\QNX Software Systems' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 11, GenuineIntel' WINDIR = 'C:\WINDOWS' QNX_JAVAHOME = 'F:\QNX641\_jvm' OLDPWD = '/home/rcampbell' USERDOMAIN = 'DRAGONWAVE' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' SSH_AUTH_SOCK = '/tmp/ssh-gSHBjU2928/agent.2928' USERNAME = 'rcampbell' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\rcampbell' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\KERMIT' PROCESSOR_ARCHITECTURE = 'x86' VISUALSVN_SERVER = 'C:\Program Files\VisualSVN Server\' SHLVL = '1' QNX_TARGET = 'F:/QNX641/target/qnx6' USERDNSDOMAIN = 'DRAGONWAVEINC.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' QNX_HOST = 'F:/QNX641/host/win32/x86' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'Nelson on clapton.dragonwaveinc.com (from DWI-A2535)' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0f0b' HUDSON_HOME = 'F:/hudson' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\' COMPUTERNAME = 'RCAMPBELL' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 c__altera_72sp1_quartus_bin_cygwin_bin_cygwin1_dll HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\Cygwin (default) = (unsupported type) HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\Cygwin-X (default) = (unsupported type) HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags
Re: Ctrl-D often does not successfully exit rxvt and close it down
On 2010-03-31 04:50, Fergus wrote: Ctrl-D fails to close down an rxvt terminal window and I am left with the terminal window showing $ exit and not shutting down. The incidence of failures is today about 80%. Anybody else? 1 Now indistinguishably close to 100% but not actually guaranteed. 2 Still unable to identify any pattern or common items in the task history in any session where Ctrl-D fails to exit. 3 X-ing the rxvt terminal window does not close it: I have to use End Task in Windows Task Manager. 4 Re-installing rxvt made no difference. 5 Reverting to [prev] made no difference. Uncertain whether a recent rebaseall might have triggered the problem (the only high-level platform-related task I have recently undertaken) I took the last possible option: 6 Wiping and then re-installing Cygwin entire made no difference. 7 The problem does NOT occur on 1.5. 8 The problem does not occur when exiting a bash terminal: only rxvt. I am using XP Pro SP3 on FAT32. Attached: cygcheck -srv. Any insights/ suggestions/ similar experiences welcome. Thank you. Fergus I had a similar problem when I upgraded to 1.7. I never found a solution and ended up switching to mintty instead of rxvt. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7.1: terminal not passing Ctrl-C to sub-sub cygwin processes
From within cygwin python, if I call os.system running a cygwin sub-process, and I hit Ctrl-C while that cygwin sub-process is running, the Ctrl-C does nothing (absolutely nothing -- nothing is printed, nothing terminates, no sound is made -- it's as if I didn't press the key at all). I've attached a simple script which easily reproduces the situation. When I run the script as ./ctrlc.py 0, Ctrl-C kill the process, but when I run it with an argument of 1 or more, hitting Ctrl-C has no effect. I have not testing this with anything other than python, but I have a feeling that it's not python related. Cygwin Configuration Diagnostics Current System Time: Fri Jan 15 10:16:37 2010 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Running in Terminal Service session Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\Program Files\Microsoft Office\OFFICE11\ C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Microsoft SQL Server\90\Tools\binn\ C:\Program Files\Common Files\GTK\2.0\bin C:\Program Files\GNU\GnuPG\pub C:\Program Files\QNX Software Systems\bin C:\WINDOWS\system32\WindowsPowerShell\v1.0 F:\QNX641\host\win32\x86\usr\bin Output from C:\cygwin\bin\id.exe UID: 13689(rcampbell)GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 1008(Debugger Users) 10513(Domain Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS MAKEFLAGS = '-IF:/QNX641/target/qnx6/usr/include' USER = 'rcampbell' PWD = '/home/rcampbell' HOME = '/home/rcampbell' HOMEPATH = '\Documents and Settings\rcampbell' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\rcampbell\Application Data' SSH_AGENT_PID = '3028' HOSTNAME = 'rcampbell' VS71COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Tools\' QNX_CONFIGURATION = 'C:\Program Files\QNX Software Systems' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 11, GenuineIntel' WINDIR = 'C:\WINDOWS' QNX_JAVAHOME = 'F:\QNX641\_jvm' OLDPWD = '/usr/bin' USERDOMAIN = 'DRAGONWAVE' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' LIB = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\' SSH_AUTH_SOCK = '/tmp/ssh-IwBSPf3500/agent.3500' USERNAME = 'rcampbell' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\rcampbell' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\CLAPTON' PROCESSOR_ARCHITECTURE = 'x86' VISUALSVN_SERVER = 'C:\Program Files\VisualSVN Server\' SHLVL = '1' QNX_TARGET = 'F:/QNX641/target/qnx6' USERDNSDOMAIN = 'DRAGONWAVEINC.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' QNX_HOST = 'F:/QNX641/host/win32/x86' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'Fleury on kermit (from DWI-A2535)' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0f0b' HUDSON_HOME = 'F:/.hudson' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' NUMBER_OF_PROCESSORS = '2' INCLUDE = 'C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\' COMPUTERNAME = 'RCAMPBELL' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 c__altera_72sp1_quartus_bin_cygwin_bin_cygwin1_dll HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\Cygwin (default) = (unsupported type) HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs\Cygwin-X (default) = (unsupported type) HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = 'C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/f (default) = 'F:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/mp3 (default) = 'F:\mp3' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/share (default) = 'C:\cygwin\home\rcampbell\share' flags = 0x000a
Re: 1.7.1: terminal not passing Ctrl-C to sub-sub cygwin processes
On 2010-01-15 18:22, Christopher Faylor wrote: On Fri, Jan 15, 2010 at 05:00:37PM -0500, Rolf Campbell wrote: From within cygwin python, if I call os.system running a cygwin sub-process, and I hit Ctrl-C while that cygwin sub-process is running, the Ctrl-C does nothing (absolutely nothing -- nothing is printed, nothing terminates, no sound is made -- it's as if I didn't press the key at all). [snip] It probably isn't. From the linux man page: NAME system - execute a shell command SYNOPSIS #includestdlib.h int system(const char *command); DESCRIPTION system() executes a command specified in command by calling /bin/sh -c command, and returns after the command has been completed. During execution of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored. cgf Thanks for setting me straight. When I change my script to use os.popen, ^C gets propagated to sub-processes. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Un-attended install ALL
Vinod K Gupta wrote: We have a local mirror of selected packages from which we install cygwin on user machines. When we perform un-attended installation using setup.exe -q -L -l -R... the installer installs only the Base packages. How can we tell setup to install ALL available packages? Vinod Modify the setup.ini on your local mirror to have every package in the Base category. -- 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: Bash 3.1.17(8) CR/LF problem
Malcolm Nixon wrote: * Some translate files to a Local format (CR/LF on Windows). FCOL, what on earth does an rcs think it's playing at, tampering with your data? Any rcs that doesn't give you back exactly what you put into it is just plain buggy. Nobody asked for a automatically mangle my data whether I want you to or not feature. This is a Perforce 'feature' if you wish to call it that. Perforce will translate files you have specified as 'Text' to whatever 'Text' means on the local system - LF on Unixes and CR/LF on Windows. One potential workaround would be to declare the script files as binary files so they aren't touched, but then you loose the ability to diff. You can disable that 'feature' in your client settings. I'm running bash scripts checked into a perforce repository in the new bash just fine with that feature disabled. -- 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: simply cygwin1.dll
When I've had this problem, it's been a permission issue. If you use wget or some other cygwin tool to download the snapshot, then it will not set the exec permissions. But when you copy a file using explorer, it will set the exec permissions. Christopher Layne wrote: May seem sort of newbish, but I just noticed that one cannot move cygwin1.dll into place after removing the old one. For instance, if I download a snapshot to some tmp directory, exit all cygwin related apps and use explorer to move the new dll from the tmp to c:\cygwin\bin - I'll get the standard crop of bad dll related failures. However if I *copy* the file (ctrl-drag) things work fine. I presume this is some kind of windows dll manipulation thing or is it just my system? -cl -- 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/
coreutils 5.97; mkdir -p; mkdir: cannot create directory `name': File exists
I believe there is a race-condition in mkdir -p. Specifically, if the directory does not exist *yet* when stat is called on line #98 of coreutils-5.97/lib/mkdir-p.c, but the directory *does* exist by the time line #190 of the same file calls mkdir(), then the program will error with File exists. I hit this occasionally when doing parallel builds. Cygwin Configuration Diagnostics Current System Time: Tue Aug 22 14:18:34 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: D:\cygwin\usr\local\bin D:\cygwin\bin D:\cygwin\bin D:\cygwin\usr\X11R6\bin C:\Program Files\Python24\ D:\cygwin\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Perforce C:\Program Files\Code Collaborator Client Output from D:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell)GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) 14591(dr-john-spicer)12700(s-rnd-all) 12536(s-software-all) 12532(s-software-node) Output from D:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell)GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) 14591(dr-john-spicer)12700(s-rnd-all) 12536(s-software-all) 12532(s-software-node) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'rcampbell' PWD = '/tmp' HOME = '/home/rcampbell' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\rcampbell' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\rcampbell\Application Data' HOSTNAME = 'desk-rcampbell' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 4 Stepping 7, GenuineIntel' WINDIR = 'C:\WINDOWS' GHS_LMWHICH = 'elan' WINDOWID = '6940208' OLDPWD = '/usr/src' USERDOMAIN = 'TROPICNETWORKS' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' TEMP = '/cygdrive/d/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' USERNAME = 'rcampbell' PROCESSOR_LEVEL = '15' GHS_LMHOST = '@server2,server1' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' USERPROFILE = 'C:\Documents and Settings\rcampbell' ULTRAMON_LANGDIR = 'C:\Program Files\UltraMon\Resources\en' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\EXCHANGE' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' COLORFGBG = '0;default;15' USERDNSDOMAIN = 'TROPICNETWORKS.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py;.pyw' HOMEDRIVE = 'C:' GHS_LMQ_METHOD = '0' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/d/Temp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = '\\spooler\135MC-4th' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0407' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' P4CONFIG = '.p4config' COMPUTERNAME = 'DESK-RCAMPBELL' COLORTERM = 'rxvt-xpm' _ = '/usr/bin/cygcheck' 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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'D:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = 'C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d (default) = 'C:\d' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'D:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'D:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 40954Mb 25% CP CS UN PA FC Mirror d: hd NTFS 70645Mb 44% CP CS UN PA FC Stripe e: cd N/AN/A D:\cygwin / system binmode C: /c system binmode C:\d /d system binmode D:\cygwin/bin /usr/bin system binmode D:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: D:\cygwin\bin\awk.exe Found: D:\cygwin\bin\bash.exe Found: D:\cygwin\bin\cat.exe Found: D:\cygwin\bin\cp.exe Found: D:\cygwin\bin\cpp.exe Not Found: crontab Found: D:\cygwin\bin\find.exe Found: D:\cygwin\bin\gcc.exe Not Found: gdb Found: D:\cygwin\bin\grep.exe Found: D:\cygwin\bin\kill.exe Found: D:\cygwin\bin\ld.exe Found: D:\cygwin\bin\ls.exe Found: D:\cygwin\bin\make.exe Found: D:\cygwin\bin\mv.exe Not Found: patch Found:
Re: coreutils 5.97; mkdir -p; mkdir: cannot create directory `name': File exists
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 From: Rolf Campbell I believe there is a race-condition in mkdir -p. Specifically, if the directory does not exist *yet* when stat is called on line #98 of coreutils-5.97/lib/mkdir-p.c, but the directory *does* exist by the time line #190 of the same file calls mkdir(), then the program will error with File exists. I hit this occasionally when doing parallel builds. Are you sure you have the right line numbers? The cygwin version of lib/mkdir-p.c is patched in coreutils-5.97-1; but even the upstream version takes great pains that this is not a race - yes, the directory can be created between the time it is statted and the mkdir, but the mkdir takes this into account by trying to chdir into the directory on failure, before giving up with an error message to the user that the file exists. I will need a stronger argument to believe that there is a race, in which case, the upstream maintainers would probably like to hear it too. Oops, after closer inspection, the problem was with my makefile. *sigh* -- 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: cygwin1.dll possible bug
Gland Vador wrote: Eric Blake wrote: What about the newest one? I have tried almost all snapshots available on this page. I went until the oldest in order to track on which snapshot it broke. The newest one doesn't work for me. When I launch a dos batch file in the bash, it tries to execute it line by line and not calling the cmd.exe. Warning: this is a me too message. For those of your emotionally sensitive to this type of message, you should probably just skip this message. This is something that I've noticed about the newer snapshots too, running .bat files dies on @ECHO command not found (and every other DOS batch file construct). -- 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/
1.5.20s (20060206): Ctrl+C, rxvt and non-cygwin programs
1. Run bash in rxvt. 2. Run strace sleep 10. 3. Press Ctrl+C. Nothing seems to receive the ^C at all (both strace and sleep run to completion). I cannot reproduce this problem using bash in a windows console. This is not a regression from 1.5.19. But I recall it working a while ago (whatever that means). It is not limited to strace, it seems to happen with any non-cygwin program. -Rolf Cygwin Configuration Diagnostics Current System Time: Tue Feb 07 14:56:16 2006 Windows XP Professional Ver 5.1 Build 2600 Service Pack 2 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Common Files\GTK\2.0\bin C:\PROGRA~1\ATT\Graphviz\bin C:\Program Files\QuickTime\QTSystem\ Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell)GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell)GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'rcampbell' PWD = '/tmp' HOME = '/home/rcampbell' MAKE_MODE = 'unix' HOMEPATH = '\Documents and Settings\rcampbell' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\rcampbell\Application Data' HOSTNAME = 'desk-rcampbell2' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 15 Model 3 Stepping 3, GenuineIntel' WINDIR = 'C:\WINDOWS' TEXDOCVIEW_txt = 'cygstart %s' TEXDOCVIEW_dvi = 'cygstart %s' WINDOWID = '4819432' OLDPWD = '/home/rcampbell' USERDOMAIN = 'TROPICNETWORKS' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' TEMP = '/tmp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' QTJAVA = 'C:\Program Files\Java\jre1.5.0_06\lib\ext\QTJava.zip' USERNAME = 'rcampbell' TEXDOCVIEW_pdf = 'cygstart %s' PROCESSOR_LEVEL = '15' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' TEXDOCVIEW_html = 'cygstart %s' USERPROFILE = 'C:\Documents and Settings\rcampbell' CLIENTNAME = 'Console' PS1 = '\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\OTTDC2' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' COLORFGBG = '0;default;15' TROPIC_UNIQUE_ID = '156' USERDNSDOMAIN = 'TROPICNETWORKS.COM' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.pyo;.pyc;.pyw;.py' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = '\\spooler\135MC-4th' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0303' CLASSPATH = 'C:\Program Files\Java\jre1.5.0_06\lib\ext\QTJava.zip' TEXDOCVIEW_ps = 'cygstart %s' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' DISPLAY = ':0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' P4CONFIG = '.p4config' COMPUTERNAME = 'DESK-RCAMPBELL2' COLORTERM = 'rxvt-xpm' _ = '/usr/bin/cygcheck' 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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin (default) = 'C:\cygwin\bin' flags = 0x004a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = 'C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d (default) = 'C:\d' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/tmp (default) = 'D:\tmp' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin\bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 38162Mb 54% CP CS UN PA FC d: hd NTFS 1Mb 14% CP CS UN PA FC sata e: hd NTFS 1Mb 1% CP CS UN PA FC sata2 f: hd NTFS112632Mb 10% CP CS UN PA FC raid C:\cygwin / system binmode C:\cygwin\bin /bin system binmode,cygexec C: /c system binmode C:\d /d system binmode D:\tmp /tmp system binmode C:\cygwin\bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found:
Re: how to get a coredump [was RE: Asterisk Cygwin]
Christopher Faylor wrote: Add error_start:/usr/bin/dumper.exe to your CYGWIN environment variable. Is there a reason why this isn't the default? -- 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: 1.5.12 ssh hangs on some machines when stdout has content
Igor Pechtchanski wrote: As I've said before, http://cygwin.com/ml/cygwin/2004-04/msg00086.html. This result from the search I suggested looks promising, if only to get the setup options: http://www.maths.lth.se/help/windows/cygwin/. See also /var/log/setup.log after setup --help (yes, it does support this). HTH, I mostly don't see any output from setup --help. I tried deleting the setup log files from /var/log and ran setup --help, but no files were created in /var/log. It also doesn't work if the files exist. I'm pretty sure it's not a permission problem cause if I run setup without any arguments it creates the log files just fine. The weirdest thing is that it worked once for me about 10 minutes ago. I'm running version 2.510.2.2. -- 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: SETUP: In-use files have been replaced
Herb Martin wrote: I didn't install Exim 4.54 into another location; someone else mentioned an alternate locationa and I (perhaps incorrectly) mentioned that I had downloaded and compiled it FROM another location. The make install was run normally and the specially compiled (make options) is in the default (/usr/bin) location. All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. There is no way to do that. You will have to either *install* it in a different directory or continue doing what you have been doing. -- 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/
cygrunsrv --list Access is denied (Was: Re: SETUP: In-use files have been replaced)
Eric Blake wrote:
I use this handy little script on my machine to help me stop
(and restart) all services:
$ cat serv
#!/bin/bash
usage='serv: manage cygwin services during cygwin upgrades
usage: serv {--help|--stop|--start}'
case $# in
1) case $1 in
--help|-h) echo $usage; exit 0 ;;
--stop) for service in `cygrunsrv --list` inetd ; do
echo stopping $service
cygrunsrv --stop $service || echo problems with $service ;;
done ;;
--start) for service in `cygrunsrv --list` inetd ; do
echo starting $service
cygrunsrv --start $service || echo problems with $service
done ;;
esac ;;
*) echo $usage; exit 1 ;;
esac
Every time I try to list services using cygrunsrv, I get an error:
$ cygrunsrv --list
cygrunsrv: Error enumerating services: OpenService: Win32 error 5:
Access is denied.
Cygwin Configuration Diagnostics
Current System Time: Tue Oct 18 15:38:30 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Common Files\GTK\2.0\bin
C:\Program Files\Perforce
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root) 544(Administrators) 545(Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root) 544(Administrators) 545(Users)
10513(Domain Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
USER = `rcampbell'
PWD = `/tmp'
HOME = `/home/rcampbell'
MAKE_MODE = `unix'
HOMEPATH = `\Documents and Settings\rcampbell'
MANPATH = `/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
HOSTNAME = `desk-rcampbell2'
TERM = `xterm'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 3, GenuineIntel'
WINDIR = `C:\WINDOWS'
WINDOWID = `4819216'
OLDPWD = `/home/rcampbell'
USERDOMAIN = `TROPICNETWORKS'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
TEMP = `/tmp'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
USERNAME = `rcampbell'
PROCESSOR_LEVEL = `15'
FP_NO_HOST_CHECK = `NO'
SYSTEMDRIVE = `C:'
USERPROFILE = `C:\Documents and Settings\rcampbell'
CLIENTNAME = `Console'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = `\\OTTDC1'
PROCESSOR_ARCHITECTURE = `x86'
SHLVL = `1'
COLORFGBG = `0;default;15'
TROPIC_UNIQUE_ID = `156'
USERDNSDOMAIN = `TROPICNETWORKS.COM'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `C:'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
TMP = `/tmp'
SYSTEMROOT = `C:\WINDOWS'
PRINTER = `\\spooler\135MC-4th'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0303'
INFOPATH = `/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = `C:\Program Files'
DISPLAY = `:0'
COSMIC = `t'
NUMBER_OF_PROCESSORS = `2'
SESSIONNAME = `Console'
P4CONFIG = `.p4config'
COMPUTERNAME = `DESK-RCAMPBELL2'
COLORTERM = `rxvt-xpm'
_ = `/usr/bin/cygcheck'
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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/a
(default) = `A:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin
(default) = `C:\cygwin\bin'
flags = 0x004a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
(default) = `C:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d
(default) = `C:\d'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/tmp
(default) = `D:\tmp'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:\cygwin\bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:\cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
c: hd NTFS 38162Mb 55% CP CS UN PA FC
d: hd NTFS152632Mb 14% CP CS UN PA FC MegaFast
C:\cygwin / system binmode
A: /a system binmode
C:\cygwin\bin /bin system binmode,cygexec
C: /c system binmode
C:\d /d system binmode
D:\tmp /tmp system binmode
C:\cygwin\bin /usr/bin system binmode
C:\cygwin/lib
Re: Windows update vs. cygrunsrv
Eric Blake wrote: I don't know it this was unique to my machine, but am reporting it in case anyone else runs into the same issue. When running Microsoft update today, on Win2k, the patch for Security Update for DirectX 9 for Windows 2000 (KB904706) hung during installation, with an instance of cygrunsrv hogging 100% CPU, until I had stopped every last one of my cygrunsrv processes. I don't know what the Microsoft update was trying to do to running services during the update, but it obviously didn't interact very well with cygrunsrv. Anyways, since stopping everything allowed the installation to proceed, and the required reboot brought up a working system, I don't know if it is worth trying to patch cygrunsrv to behave nicer in the presence of whatever the Windows upgrade was throwing at it. Rather, I'm just posting this as a sort of FYI for anyone else that might encounter the same behavior. I updated 3 machines: 2 XP boxes an 1 Win2k box. All 3 were running cygrunsrv and sshd. I only experienced problems on the Win2k box. cygrunsrv hogged the cpu until I killed it, then sshd hogged the cpu until I killed it. After killing those processes, the update proceeded without issue and after the restart everything (including ssh) was working fine. -- 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: sshd install problems | WinXP Pro system
Evan Cooch wrote: 2. modifed the env variables by adding a variable named CYGWIN with value ntsec tty Not necessary. Then why is it specified in http://pigtail.net/LRP/printsrv/cygwin-sshd.html Because that web page is wrong, that's why. -- 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/
1.5.17: chroot-ed make adds // to ${MAKE}
I'm trying to do a chroot-ed make which uses the content of the ${MAKE}
variable. What I'm finding is the value of ${MAKE} has two slashes '//'
at the beginning, so any attempt to use it failes (looks like a network
share).
I've created a directory, expanded cygwin-1.5.17-1.tar.bz2 into it, then
copied make.exe (from the cygwin package). And a few other dlls that
were needed by cygwin1.dll (intl/conv). When I run:
$ chroot . usr/bin/make.exe all
echo //usr/bin/make
make: echo: Command not found
make: *** [all] Error 127
I know that that error code has to do with echo.exe not existing, but
I'm only concerned with the extra '/' added to ${MAKE}. My makefiles
that run sub-makes use it and fail.
--makefile--
all:
echo ${MAKE}
Cygwin Configuration Diagnostics
Current System Time: Tue Jun 14 14:46:07 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root) 544(Administrators) 545(Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root) 544(Administrators) 545(Users)
10513(Domain Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
USER = `rcampbell'
PWD = `/tmp/cyg'
HOME = `/home/rcampbell'
MAKE_MODE = `unix'
HOMEPATH = `\Documents and Settings\rcampbell'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
HOSTNAME = `desk-rcampbell2'
TERM = `xterm'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 3, GenuineIntel'
WINDIR = `C:\WINDOWS'
WINDOWID = `4819272'
OLDPWD = `/tmp'
USERDOMAIN = `TROPICNETWORKS'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
TEMP = `/tmp'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
USERNAME = `rcampbell'
PROCESSOR_LEVEL = `15'
FP_NO_HOST_CHECK = `NO'
SYSTEMDRIVE = `C:'
USERPROFILE = `C:\Documents and Settings\rcampbell'
CLIENTNAME = `Console'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = `\\EXCHANGE'
PROCESSOR_ARCHITECTURE = `x86'
SHLVL = `1'
COLORFGBG = `0;default;15'
TROPIC_UNIQUE_ID = `156'
USERDNSDOMAIN = `TROPICNETWORKS.COM'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `C:'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
TMP = `/tmp'
SYSTEMROOT = `C:\WINDOWS'
PRINTER = `\\spooler\135MC-4th'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0303'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
PROGRAMFILES = `C:\Program Files'
DISPLAY = `:0'
COSMIC = `t'
NUMBER_OF_PROCESSORS = `2'
SESSIONNAME = `Console'
P4CONFIG = `.p4config'
COMPUTERNAME = `DESK-RCAMPBELL2'
COLORTERM = `rxvt-xpm'
_ = `/usr/bin/chroot'
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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/a
(default) = `A:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin
(default) = `C:\cygwin\bin'
flags = 0x004a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin/cygcheck
(default) = `C:\cygwin\bin\cygcheck'
flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin/cygcheck.exe
(default) = `C:\cygwin\bin\cygcheck.exe'
flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin/strace
(default) = `C:\cygwin\bin\strace'
flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin/strace.exe
(default) = `C:\cygwin\bin\strace.exe'
flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
(default) = `C:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d
(default) = `D:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:\cygwin\bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin/cygcheck
(default) = `C:\cygwin\bin\cygcheck'
flags = 0x001a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts
v2\/usr/bin/cygcheck.exe
(default) =
Re: 1.5.17: chroot-ed make adds // to ${MAKE}
Rolf Campbell wrote:
I'm trying to do a chroot-ed make which uses the content of the ${MAKE}
variable. What I'm finding is the value of ${MAKE} has two slashes '//'
at the beginning, so any attempt to use it failes (looks like a network
share).
I've created a directory, expanded cygwin-1.5.17-1.tar.bz2 into it, then
copied make.exe (from the cygwin package). And a few other dlls that
were needed by cygwin1.dll (intl/conv). When I run:
$ chroot . usr/bin/make.exe all
echo //usr/bin/make
make: echo: Command not found
make: *** [all] Error 127
I know that that error code has to do with echo.exe not existing, but
I'm only concerned with the extra '/' added to ${MAKE}. My makefiles
that run sub-makes use it and fail.
--makefile--
all:
echo ${MAKE}
I tried to over-ride the MAKE (and MAKE_COMMAND) variable from the
command line, which fixed this specific problem, but I'm left with
another problem. Even if you override MAKE and MAKE_COMMAND, you still
get an error:
$ chroot . usr/bin/make.exe -Rr all MAKE=/usr/bin/make.exe
MAKE_COMMAND=/usr/bin/make.exe
makefile:4: m.mk: No such file or directory
echo t m.mk
make: //usr/bin/make: Command not found
You can specify chroot . /usr/bin/make.exe ... and it will work, but
it should also work without that leading slash.
--makefile--
all:
echo ${MAKE}
include m.mk
m.mk:
echo t m.mk
--
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: Unison 2.10.2 fast update check broken?
Marcus Picasso wrote: Seems that Cygwin port of the unison file synchronizer does not do the -fastcheck very well. Transcript follows: ... Can somebody confirm / explain this behaviour? I have a large tree that I'm synchronizing across two hard-disks, and got suspicious when re-running synchronization takes longer than expected. The above transcript functions as expected using linux or native Win32 unison builds. Regards, -Marcus. I have noticed a change in how -fastcheck which seems to be caused by my upgrade from cygwin 1.5.14 - 1.5.16. I tried doing a unison sync between a maching running 1.5.14 and a machine running 1.5.16 when I noticed the 1.5.16 machine spent a lot of time grinding the disk. So, I upgraded the 1.5.14 machine to 1.5.16 and it too went from a 10 second scan time to a half hour of heavy disk access. Cygwin Configuration Diagnostics Current System Time: Sun May 01 13:04:20 2005 Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINNT\system32 C:\WINNT C:\WINNT\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell)GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell)GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINNT\system32 WinDir: C:\WINNT HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `PCRCAMPBELL3' COMSPEC = `C:\WINNT\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `pcrcampbell3' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\PCRCAMPBELL3' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `1' OLDPWD = `/home/rcampbell' OS2LIBPATH = `C:\WINNT\system32\os2\dll;' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 6 Model 8 Stepping 6, GenuineIntel' PROCESSOR_LEVEL = `6' PROCESSOR_REVISION = `0806' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINNT' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `xterm' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TROPIC_UNIQUE_ID = `156' USERDNSDOMAIN = `tropicnetworks.com' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINNT' WINDOWID = `168188080' _ = `/usr/bin/cygcheck' 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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d (default) = `d:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/e (default) = `E:' flags = 0x001a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/f (default) = `f:' flags = 0x010a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options c: hd NTFS 19069Mb 84% CP CS UN PA FC d: cd N/AN/A f: netN/AN/A C:\cygwin / system binmode C: /c system binmode d: /d system binmode E: /e system binmode,exec f: /f system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found:
rsync throttling (Was: children of init ignore STOP and CONT signals)
Sam Inala wrote: Cygwin 1.5.12(0.116/4/2) on W2K SP4 Not all signals are ignored. The TERM and INT signals correctly terminate the process. I would like to send STOP and CONT to throttle the CPU usage of a rsync process. I want to avoid spawning a bash process to start rsync because it is started from a Windows process. If I invoke a shell process to invoke rsync, it will be difficult to get the windows process id so I can translate it to a cygwin process id and send it a signal. Any suggestions? Use --bwlimit=KBPS. This should indirectly throttle cpu usage. This won't have an impact on the initial cpu-usage if you specify -c to force check-summing of all files. -- 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: gmake -r -p -n problem on fast computers: erroneous thread activa tion
Upgrade your cygwin to the newest snapshot, that has that problem fixed. Guerte Yves-r57319 wrote: Hi, I have problems with gmake on the new computers I use (and not with the same Cygwin version with older computers). I do gmake -r -p -n and parse the output to get some variables content. The problem occurs when a variable is computed using the $(shell ...) command. I shortened the makefile and wrote a small script that shows the problem. Use example (put test.mk and run_test_simple.csh at the same place): run_test_simple.csh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 1 [exiting thread] gmake 1912 cygthread::stub: erroneous thread activation Thanks for your help. Best regards, Yves -- run_test_simple.csh file -- #!/usr/bin/tcsh -f # I create multiple empty files # mkdir -p test_src set i=0 while ($i = 363) touch test_src/$i.c @ i++ end # I build a gmake output reference file # gmake -f test.mk -r -p -n | grep 'SRC_WITH_MAIN *:=' liste_simple.ref set n=0 set i=0 # And I repeat calling gmake # while ( $n == 0 ) # sleep 1 @ i++ echo -n $i gmake -f test.mk -r -p -n | grep 'SRC_WITH_MAIN *:=' liste_simple.txt set n=`diff -wBq liste_simple.txt liste_simple.ref | wc -l` end cp liste_simple.txt liste-differ_simple.txt exit 0 -- test.mk file --- SRC_DIR := test_src C_EXT = c CPP_EXT = cpp SRC_EXTLIST = $(C_EXT) $(CPP_EXT) SRC_FILES:= $(foreach EXT,$(SRC_EXTLIST),$(wildcard $(SRC_DIR)/*.$(EXT))) SRC_WITH_MAIN:= $(shell ls -1 $(SRC_FILES)) all : ; @printf '%s\n' $(SRC_WITH_MAIN) -- 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: hyperthreading fix try #2
Christopher Faylor wrote: I'm not claiming that it is right now. I haven't tried a make -j test yet. I just thought it was time to release another try on the world again: http://cygwin.com/snapshots/ To help preserve my tenuous grasp on sanity, please reply to *this thread* when reporting problems. Please don't start a new thread. Just reply here so that mailing list threading is preserved and I can easily check for all success or error reports. As before, any kind of report is welcome but it is unlikely that I'm going to spend a lot of time debugging problems that I can't reproduce. cgf My make -j test has been running for a while with no failures, and beyond that, this seems to fix a long-standing problem for me having to do with more excessive parallelization make -j100 issues. -Rolf -- 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/
20050208 snapshot = yay! (Was: Re: hyperthreading fix, try #1)
Rolf Campbell wrote: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf I've tried yesterday's snapshot with my test-case, and with my real build system. So far, things look very good. -Rolf -- 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: 20050208 hyperthreading bug is back ?
CV wrote: Summary: I reported before that the 20050206 snapshot appeared to fix the hyperthreading bug for me. Now it seems that the next snapshot 20050208 broke it again. Result: --- after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL And it appears I spoke too early before. I too, still see a problem: 1424 [exiting thread] make 2052 cygthread::stub: erroneous thread activation, name is NULL. None of my simple test cases seems to fail, but in the guts of a 2-hour build, I get that error message and things grind to a halt. -Rolf -- 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: 20050208 hyperthreading bug is back ?
CV wrote: Rolf Campbell thats.unpossible at gmail.com writes: CV wrote: after 700 to 1000 files bash hangs with the following error message: 2 [exiting thread] bash 3328 cygthread::stub: erroneous thread activation, name is NULL And it appears I spoke too early before. I too, still see a problem: 1424 [exiting thread] make 2052 cygthread::stub: erroneous thread activation, name is NULL. None of my simple test cases seems to fail, but in the guts of a 2-hour build, I get that error message and things grind to a halt. OK, but then it would perhaps be interesting to know if the 20050206 snapshot works for you there - or, in case it fails, whether the error is the same or different ? Cheers CV The 0206 snapshot is DOA in my tests. -- 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: hyperthreading fix, try #1
Volker Bandke wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rolf, a) Your test case fails on my machine as well, right at the beginning b) I seem to remember that there was/is a separate problem with make - -j, even on non-hyperthreasd machines. Unfortunately I cannot search the mailing list right now due to some error (that possibly has to do with cygwin.com's earlier breakdown. I do remember a sentence somewhere like We don't recommend that you use 'make -j' as it seems to be broken c) Running your testcase with '-j1' instead of '-j2' does not fail on my machine Thanks for you info Volker. Here's what I've figured out: This test does fail (in the same way) on non-hyperthreaded machines (Win2000Pro on a PIII). But, this is a regression from 1.5.12 (that test runs fine on the non-HT machine with 1.5.12. There was (maybe still is) a problem with running make -j without the max task counter, but make -j2 has always worked very well on non-ht machines. I will try out some other snapshots and see if I can narrow down the time when this showed up later today. -Rolf -- 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: hyperthreading fix, try #1
Christopher Faylor wrote:
[...]
Anyway, I took a look at the pipe handling code for the 457th time and
this time I saw a couple of obvious flaws in my logic. The
synchronization was all off.
Fixing that seems to have fixed my hyperthreading problems. I have run
three invocations of the scripts for four days without a hiccup.
Previously, I had problems within minutes.
I'm not naive enough to think that I've solved all of the hyperthreading
problems but I would like people to try today's snapshot (or any
snapshot newer than today's) and report on whether it solves the problem
or not. If it doesn't, please provide as simple a test case as possible
so that I can duplicate the problem.
Using the new snapshot (Feb 6th), the problem is still present, and in
fact, occurs much more quickly and reliably on my system. This is a
modified test case from my original report. Just put makefile and t.sh
in the same dir, run ./t.sh. On my 2.8GHz HT P4, it locks up within
the first second very consistantly. My output look like this:
==output===
$ ./t.sh
Loop 1
: Begin 0.pp 1
: Begin 1.pp 1
$ ./t.sh
: Begin 0.pp
: Begin 1.pp
CYGWIN_NT-5.1
SHELL = /bin/sh
testuname: 0.pp 1.pp 2.pp 3.pp 4.pp 5.pp 6.pp 7.pp 8.pp 9.pp 10.pp 11.pp 12.pp
13.pp 14.pp 15.pp 16.pp 17.pp 18.pp 19.pp 20.pp 21.pp 22.pp 23.pp 24.pp 25.pp
26.pp 27.pp 28.pp 29.pp 30.pp 31.pp 32.pp 33.pp 34.pp 35.pp 36.pp 37.pp 38.pp
39.pp 40.pp 41.pp 42.pp 43.pp 44.pp 45.pp 46.pp 47.pp 48.pp 49.pp 50.pp 51.pp
52.pp 53.pp 54.pp 55.pp 56.pp 57.pp 58.pp 59.pp 60.pp 61.pp 62.pp 63.pp 64.pp
65.pp 66.pp 67.pp 68.pp 69.pp 70.pp 71.pp 72.pp 73.pp 74.pp 75.pp 76.pp 77.pp
78.pp 79.pp 80.pp 81.pp 82.pp 83.pp 84.pp 85.pp 86.pp 87.pp 88.pp 89.pp 90.pp
91.pp 92.pp 93.pp 94.pp 95.pp 96.pp 97.pp 98.pp 99.pp 100.pp 101.pp 102.pp
103.pp 104.pp 105.pp 106.pp 107.pp 108.pp 109.pp 110.pp 111.pp 112.pp 113.pp
114.pp 115.pp 116.pp 117.pp 118.pp 119.pp 120.pp 121.pp 122.pp 123.pp 124.pp
125.pp 126.pp 127.pp 128.pp 129.pp 130.pp 131.pp 132.pp 133.pp 134.pp 135.pp
136.pp 137.pp 138.pp 139.pp 140.pp 141.pp 142.pp 143.pp 144.pp 145.pp 146.pp
147.pp 148.pp 149.pp 150.pp 151.pp 152.pp 153.pp 154.pp 155.pp 156.pp 157.pp
158.pp 159.pp 160.pp 161.pp 162.pp 163.pp 164.pp 165.pp 166.pp 167.pp 168.pp
169.pp 170.pp 171.pp 172.pp 173.pp 174.pp 175.pp 176.pp 177.pp 178.pp 179.pp
180.pp 181.pp 182.pp 183.pp 184.pp 185.pp 186.pp 187.pp 188.pp 189.pp 190.pp
191.pp 192.pp 193.pp 194.pp 195.pp 196.pp 197.pp 198.pp 199.pp 200.pp 201.pp
202.pp 203.pp 204.pp 205.pp 206.pp 207.pp 208.pp 209.pp 210.pp 211.pp 212.pp
213.pp 214.pp 215.pp 216.pp 217.pp 218.pp 219.pp 220.pp 221.pp 222.pp 223.pp
224.pp 225.pp 226.pp 227.pp 228.pp 229.pp 230.pp 231.pp 232.pp 233.pp 234.pp
235.pp 236.pp 237.pp 238.pp 239.pp 240.pp 241.pp 242.pp 243.pp 244.pp 245.pp
246.pp 247.pp 248.pp 249.pp 250.pp 251.pp 252.pp 253.pp 254.pp 255.pp 256.pp
257.pp 258.pp 259.pp 260.pp 261.pp 262.pp 263.pp 264.pp 265.pp 266.pp 267.pp
268.pp 269.pp 270.pp 271.pp 272.pp 273.pp 274.pp 275.pp 276.pp 277.pp 278.pp
279.pp 280.pp 281.pp 282.pp 283.pp 284.pp 285.pp 286.pp 287.pp 288.pp 289.pp
290.pp 291.pp 292.pp 293.pp 294.pp 295.pp 296.pp 297.pp 298.pp 299.pp 300.pp
%.pp::
: Begin $@ ${C}
@uname
: End $@ ${C}
#!/bin/bash
while true; do
make -rRj2
C=$(($C+1))
done
Cygwin Configuration Diagnostics
Current System Time: Mon Feb 07 00:59:22 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
544(Administrators) 545(Users) 10513(Domain Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
HOME = `C:\cygwin\home\rcampbell'
MAKE_MODE = `unix'
PWD = `/tmp/make'
USER = `rcampbell'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `DESK-RCAMPBELL2'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
COSMIC = `t'
CVS_RSH = `/bin/ssh'
DISPLAY = `:0'
FP_NO_HOST_CHECK = `NO'
HOMEDRIVE = `C:'
HOMEPATH = `\Documents and Settings\rcampbell'
HOSTNAME = `desk-rcampbell2'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
LOGONSERVER = `\\EXCHANGE'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
NUMBER_OF_PROCESSORS = `2'
OLDPWD = `/home/rcampbell'
OS = `Windows_NT'
P4CONFIG = `.p4config'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PRINTER = `135MC-4th on SPOOLER (from PCRCAMPBELL3)'
Re: update on hyperthreading system for cgf
Christopher Faylor wrote: On Wed, Jan 19, 2005 at 09:16:51PM -0800, David Christensen wrote: Christopher Faylor wrote: Hasn't anyone put together a nice $400 system? How about $417.50? http://secure.newegg.com/app/WishR.asp?ID=1251752 You need to provide the hard drive, CD-ROM drive, floppy drive, keyboard, mouse, and operating system. Well, yeah. I sort of need a hard disk, though and is that system *guaranteed* to exhibit this problem? cgf I have been able to reproduce this on a variety of machines, the only common attribute that I noticed has been Hyperthreading itself (WinXP/WinServer2003, 2.6GHz P4-HT/2.8GHz P4-HT/Dual 3.2GHz Zeon-HT, 40Gig Mitsubishi harddrive/36G Western Digital/80 Gig HP, with or without a CD-ROM drive, with or without a floppy). I unplugged my mouse and was able to reproduce it. I unplugged the monitor and reproduced it over remote desktop connection. So, at this point, I would believe that any HT machine running at least WinXP would show the problem. -Rolf -- 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: ls /dev/*
Andrew DeFaria wrote: While, you are welcome to redefine /cygdrive any way you want, the unix paradigm does not put filesystems under /dev. That is for devices. To me, a disk drive IS a device. YMMV! :-) A disk drive is a device, but /cygdrive/c is not a disk-drive. It's a file-system contained in a partition contained on a disk-drive (usually). In unix-like systems, the disk-drive and the partition are available as devices along with the file-system. The disk-drive in /dev/ is a flat-device. All bytes available sequentially as a single image. I recall that there is a way to access the disks as real devices under NT/2000/XP using some strange notation. It might make sense to mount those under /dev/, but to mount your C-drive there would not be consistant with what /dev/ was designed for. -Rolf -- 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: cygutils cygstart eats program arguments
Dave Korn wrote: -Original Message- From: cygwin-owner On Behalf Of Robert Schmidt Sent: 25 October 2004 22:56 Mark Paulus wrote: Have you tried using a -- to indicate end of arguments to cygstart: cygstart -- tail --version Thanks! No, I hadn't, and that works great. I still find the usage syntax to be misleading though: Usage: cygstart [OPTION]... FILE [ARGUMENTS] What are ARGUMENTS if not to be passed to the execution of FILE? (For people relatively new to the nuances of cygwin/Linux (like myself), '--' is a pretty obscure feature.) Consider the question of how one would grep for the string --version in a file. cheers, DaveK grep -e --version -- 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/x symantec antivirus conflict (fixed in snapshot?)
Christopher Faylor wrote: On Tue, Oct 19, 2004 at 12:26:58AM -0400, Rolf Campbell wrote: An rsync session that consistantly works on the Oct 7 snapshot fails consistantly on the Oct 10 snapshot. Try it with the October 20 snapshot. I had the same problem with rsync (although I would have sworn that I tested it). It seems like I fixed it although I don't understand why my fix would make things better. Oct 20: Looks good to me. -- 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/x symantec antivirus conflict (fixed in snapshot?)
Christopher Faylor wrote: For those who haven't been following along at home, it looks like a change I just made to select() may solve the dreaded slows down to a crawl with Symantec AntiVirus problem. This may also improve the performance of things that use sockets slightly. So, I'd appreciate reports on the latest snapshot. Does it fix any problems? Cause any problems? No change? In this one case, I'd like to hear me toos since the change was to a fundamental part of cygwin and it is in socket code, which has proved to be problematic. So, I'd like to know if things still work on Windows 9x and all flavors of NT. http://cygwin.com/snapshots/ Things would be, openssh, telnet, ftp, rsync, etc. Anything which uses sockets or communicates via TCP/IP. I've run into a problem with your change: An rsync session that consistantly works on the Oct 7 snapshot fails consistantly on the Oct 10 snapshot. I've tried 10/07 and 10/11 on both WinXP (as the client) and Win2000 (as the client). The server in both cases was a WinXP machine running 1.5.11. The command I'm running in both cases is: rsync -tvr --stats --progress --delete [EMAIL PROTECTED]:/c/mp3/ /c/mp3/ It logs in using ssh fine, then it gets the remote file-list fine (2189 files), but at the end of local file list, it just hangs (presumably when it's trying to figure out what to transfer). It will hang even when there are no files to actually transfer (all the time-stamps are the same). I've tried it about 5 times on each snapshot on each machine, with very reproducable results. -Rolf Cygwin Configuration Diagnostics Current System Time: Tue Oct 19 00:18:03 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 0(root) 544(Administrators) 545(Users)10513(Domain Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS CYGWIN = `error_start=c:/cygwin/bin/gdb.exe' HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' CLIENTNAME = `Console' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DESK-RCAMPBELL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `desk-rcampbell' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\EXCHANGE' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/home/rcampbell' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `vt100' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TROPIC_UNIQUE_ID = `156' USERDNSDOMAIN = `TROPICNETWORKS.COM' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINDOWS' WINDOWID = `168191264' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin (default) = 0x0400 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts' flags =
Re: Compilation errors not shown properly in Cygwin
Rajagopalan, Karthik wrote: Hi Cygwin_Techies, I have been trying to install working packages of Cygwin for our current project but fails in every attempt with some issues. Currently I find the Cygwin doesn't report the compilation errors from Microsoft Visual Studio C Compiler. Let me explain the problem clearly. I am trying to compile a C program through Makefile from Cygwin. This C program has syntax errors which are supposed to be shown by Cygwin when running C compiler. It just indicates the following lines and stops : make: *** [/cygdrive/h/test.obj] Error 1 If I run the C program without using Makefile from Cygwin, errors are properly indicated. I feel the problem exists with make.exe of Cygwin and their dependency executables. Can anyone spot the problem happening here and highlght a solution for this? Regards, Karthik http://cygwin.com/problems.html -- 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/
Basic C/C++ (Was: 1.5.10: problems relocating structures with function pointers)
Justin Schoeman wrote:
I have discovered what may be a bug in the linker/relocater in cygwin
(or, more likely, I am doing something stupid again).
When I use a structure containing function pointers, and this structure
is placed in an archive, then the function pointer becomes NULL. As an
example, compile the attached files as follows:
gcc -O2 -Wall -c inc.c
ar rsvc inc.a inc.c
gcc -O2 -Wall -o test test.c inc.a
Executing test.exe prints 0x0 (the address of the function cointained in
the structure), and subsequently segfaults.
Relinking with
gcc -O2 -Wall -o test test.c inc.o
produces a binary that works correctly.
It seems that once the object file is archived, the dynamic loader
losses the capability of correctly assigning the function addresses?
Any help would be greatly appreciated.
TIA,
-justin
#include stdio.h
static void junk(void)
{
fprintf(stderr, JUNK!\n);
}
struct js {
void (*junk)(void);
};
const struct js jsi = { junk };
#include stdio.h
struct js {
void (*junk)(void);
};
struct js jsi;
extern struct js jsi;
^^
int main(void)
{
fprintf(stderr, %p\n, jsi.junk);
jsi.junk();
return 0;
}
--
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: Extending long threads
GARY VANSICKLE wrote: There's three reasons people knee-jerk against HTML email: 1. It isn't ASCII (i.e. the Back in my day a child would open up a gift and within seconds he'd either burst into flames or lose a limb! That's the way it was and we liked it![1] Defense). 2a. There isn't an email program alive which can do a Reply to an HTML email properly. I'm using one right now... Mozilla (Thunderbird) handles replying to HTML email just fine. 2b. ...especially those which support VT-100 terminals. 3. The lines are longer than 80 characters ;-). I fall under category 2a, but my knee isn't jerking: If Outlook didn't absolutely s*ck *ss at editing HTML I wouldn't care. You can't blame everything on your choice to use Outlook. -- 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: two instances of a.exe on dual processor - still only 50% performance
Brian Dessent wrote: [EMAIL PROTECTED] wrote: Many thanks for this tip. I tried it out and indeed there is a Set Affinity option in the Taskmanager. Apparently, this option lets you assign one or more of the 4 virtual processors to a particular task. (W2K seems to have this concept of virtual processors, I am no expert at all here). But it doesn't change a thing. still 50% are spent on Idle mode... You see 4 CPUs because of HyperThreading. A HT CPU registers with the OS as two CPUs, but it's not. Only in certain circumstances can it run two threads concurrently (such as performing an integer and floating operation at the same time.) Thus 50% CPU usage means that your system is fully loaded. On a HT system you've got to double all the CPU usage percentages for it to make sense. Occasionally you might see it surpass 50%, which would mean that the hyperthreading is particularly suited to whatever combination of instructions is being executed and it's using the CPU more efficiently. Brian Sorry Brian, that is bogus. I'm running one HT processor right now. The combined CPU utilization is not an actual display of usage, but theoretical usage, based on scheduling. It's really how much of the CPU was NOT being used by the idle task, and given that there is only one CPU, if some process is taking up 99% of it, and some other process takse up the other 1% on the other 'hyper thread' then the idle task will not be able to run at all on either virtual cpu. Thus Task Manager will (and does) show 100% dual CPU utilization. Now, Mathias's problem: Sounds like your program is bound by something other than CPU. If you have two programs that try to access the hard-disk, they are not going to be twice as fast with 2 CPUs (virtual or not). -Rolf -- 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: two instances of a.exe on dual processor - still only 50% performance
Ken Thompson wrote: At 01:24 PM 7/7/2004, Rolf Campbell wrote: Sorry Brian, that is bogus. I'm running one HT processor right now. The combined CPU utilization is not an actual display of usage, but theoretical usage, based on scheduling. It's really how much of the CPU was NOT being used by the idle task, and given that there is only one CPU, if some process is taking up 99% of it, and some other process takse up the other 1% on the other 'hyper thread' then the idle task will not be able to run at all on either virtual cpu. Thus Task Manager will (and does) show 100% dual CPU utilization. -Rolf Sorry Rolf, but at least on my HT processor running Windows XP pro, the reporting of utilization by task manager is exactly as described by Brian. Strange, I'm running WinXP pro, all patched up. And if I run two CPU bound programs (cygwin or not) my utilization goes to 100% (easily). -- 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/
1.5.10-3: make -j6: read jobs pipe: No such file or directory. Stop.
First, this is not a regression to any recent cygwin (it has been a problem for a while (I've tried it on every snapshot as they came out for the past 2 months), I know it did work is 1.3.17, but I also know that is not terribly useful info). I finally produced a test case that exhibited the problem. This should look familiar to some of you, it's the old make -j test, but it's been modified (cause the original test did not show this problem). I'm running a WinXP, P4-2.6GHz(HT) machine. It takes a while to fail (about 6 hours for me): make: *** read jobs pipe: No such file or directory. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs Failed after 606 runs -Rolf Cygwin Configuration Diagnostics Current System Time: Thu May 27 10:26:05 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS CYGWIN = `error_start=c:/cygwin/bin/gdb.exe' HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp/cygwin' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DESK-RCAMPBELL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `desk-rcampbell' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\OTTDC2' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/home/rcampbell' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `vt100' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TROPIC_UNIQUE_ID = `156' USERDNSDOMAIN = `TROPICNETWORKS.COM' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINDOWS' WINDOWID = `168191120' _ = `/usr/bin/cygcheck' POSIXLY_CORRECT = `1' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin (default) = 0x0400 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 39260Mb 69% CP CS UN PA FC d: cd N/AN/A z: net NTFS 39260Mb 60% CP CS UN PA FC C:\cygwin / system binmode C: /csystem binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe
Re: /bin/rm lots of files
I suspect this is a command-line too long problem, but I can't say for sure since you didn't really provide any details. If I'm correct, then you cannot change the limit easily. You should either delete the files in smaller lists, or if you are trying to delete all files in a directory you can do: rm -r path/to/files or find path/to/files | xargs rm or something like that. Lester Ingber wrote: I couldn't find what I thought I recalled as a similar posting. In my Makefile I have a command to remove a directory of files. I get a complaint that there are too many files to remove (about 1000). How do I change the default for increasing the number of listed/open files? Thanks. Lester -- 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: recompiling cygwin dll problems
Christopher Faylor wrote: Bingo! I guess I should have put an and in my first two statements. You can only have *1* DLL built from the Cygwin source resident and running at any one time. It wasn't clear to me that this is what you were doing, otherwise I would have told you that this is a no-no to start with. Actually, that isn't entirely true or you wouldn't be able to run the test suite. Looking at the test suite scripts might be instructive. Oh, and, in the case of multiple DLLs, in theory, the DLL is supposed to print an error, not just mysteriously die. cgf When running the Apr22 snapshot, and trying to start a program with an Apr27-cvs build, I don't recieve any error message, all programs terminate with no output. -- 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: latest snapshot seems better wrt make -j hang problems
Christopher Faylor wrote: FWIW, I found ANOTHER race yesterday while running the cygwin test suite. So, it's back to square one for testing since it was in low level code which could affect everything. And, this race has been there since I screwed up in September 2001. Lovely. Well, I can't break the '16 snapshot either ( 11000 iterations without any problems). I'm guessing this included a fix for that other race you speak of. -- 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: latest snapshot seems better wrt make -j hang problems
Christopher Faylor wrote: I have been running the make -j cygwin breaker for about ten hours now with no hangs, no segvs, and no strange error exits. I'm sure this is just because of the magical way in which I have my system set up but could anyone confirm or deny whether that this snapshot behaves better? If it does still die then an strace of the failing case would be helpful. If it is too large for the mailing list software then let me know and I'll arrange to get the strace via some other mechanism -- i.e., via a brand new cygwin bugzilla setup. cgf I've been running it for about 24 hours on my HyperThreaded XP machine, 14000 iteration, not a single problem. -- 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: Using gcc 3.3.3
Building gcc (natively) always requires a working gcc to be present, how else would it compile itself? Ben Taylor wrote: What I don't get is why when I built 3.3.3 using 'make' and then 'make install' (it failed to do 'make bootstrap') it relied on the fact that cygwin was installed in the first place. Why then is that, does it require some unix based functionality that only cygwin provides to a windows pc? -Original Message- From: Larry Hall [mailto:[EMAIL PROTECTED] Sent: 14 March 2004 18:59 To: Ben Taylor; [EMAIL PROTECTED] Subject: Re: Using gcc 3.3.3 At 09:50 AM 3/14/2004, you wrote: Hi I have got Cygwin running on my windows XP pc, using gcc 3.3.1. I downloaded gcc 3.3.3 release, and managed to build it, however when I tried to compile a windows application using it it compiled ok but gave a linker error 'couldn't find crt2.o'. It gave this error when I was trying to compile with -mno-cygwin, which worked with gcc 3.3.1. I found that this file was in c:/cygwin/lib/mingw, but passing an option on to the linker such as -Wl,-Lc:/cygwin/lib/mingw or other variations on this didn't work. However when I copied the crt2.o file to c:/cygwin/lib, it worked! But then I read that -mno-cygwin wasn't included on gcc 3.3.3. So was this a fluke? Or is there a standard way to use gcc 3.3.3 on cygwin? Also if I used g++ 3.3.3 to compile but g++ 3.3.1 that came with cygwin to link, it also works fine! Is it then actually using the benefits of the more modern version? The gcc compiler suite for Cygwin contains patches to include the '-mno-cygwin' switch. Since gcc 3.3.3 isn't part of the Cygwin distribution yet, you would need to patch your local version if you want this functionality prior to it's inclusion in Cygwin. -- 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: Snapshot 20040225: make hangs/errors out
Christopher Faylor wrote: I made a fix last night that allowed me to run this for 2500+ iterations. Of course, I have managed to do that before without error, so that doesn't mean much, I guess. Backing the change out resulted in a 'virtual memory exhausted' error in less than a hundred iterations, however. Odd that I can duplicate it so readily now. I think my computer was previously trying to shield me from the pain of debugging this problem. There is a new snapshot up now with my fix in it. Please try it. Sigh. Literally two minutes after sending this email, the make -j test that I was running at home errored out with a different error. Back to the drawing board... Hmm. I can't duplicate the failure I saw so maybe it would still be instructive to see how the current snapshot works for others. Please send test results here. cgf '06 snapshot, froze after 128 iterations (0% cpu, no error output). I've attached the end of the strace output. I will run it a few more times to make sure this is consistant. -Rolf ** Program name: C:\cygwin\bin\sh.exe (2884) 248 43520 [main] uname 2816 writev: writev (1, 0x22EEB0, 1) App version: 1005.8, api: 0.111 96 43616 [main] uname 2816 fhandler_base::write: binary write DLL version: 1005.8, api: 0.111 118 43734 [main] uname 2816 fhandler_base::write: 14 = write (0xA040280, 14) DLL build:20040306 23:59:38SNP 107 43841 [main] uname 2816 writev: 14 = write (1, 0x22EEB0, 1), errno 0 OS version: Windows NT-5.1 9827 1053360 [proc] make 2168 proc_subproc: args: 2, 1 170 44011 [main] uname 2816 close: close (1) Heap size:1073741824 154 1053514 [proc] make 2168 proc_subproc: pid 4080[1] terminated, handle 0x674, nchildren 3, nzombies 3 151 44162 [main] uname 2816 fhandler_base::close: closing '/tmp/cygwin/freeze.1' handle 0x6E8 Date/Time:2004-03-08 11:18:11 ** 151 1053665 [proc] make 2168 proc_subproc: zombifying [1], pid 4080, handle 0x674, nchildren 3 131 44293 [main] uname 2816 close: 0 = close (1) 103 1053768 [proc] make 2168 proc_subproc: returning 1 77 1053845 [proc] make 2168 sig_send: sendsig 0x70C, pid 2168, signal 20, its_me 1 2891133 [main] sh 2884 events_init: windows_system_directory 'C:\WINDOWS\System32\', windows_system_directory_length 20 243 44536 [main] uname 2816 do_exit: do_exit (0), exit_state 0 132 1053977 [proc] make 2168 sig_send: Not waiting for sigcomplete. its_me 1 signal 20 99 44635 [main] uname 2816 void: 0x0 = signal (20, 0x1) 1421275 [main] sh 2884 _cygwin_istext_for_stdio: fd 0: opened as binary 108 1054085 [proc] make 2168 sig_send: returning 0x0 from sending signal 20 65 44700 [main] uname 2816 void: 0x0 = signal (1, 0x1) 90 44790 [main] uname 2816 void: 0x0 = signal (2, 0x1) 133 1054218 [proc] make 2168 wait_subproc: looping 1501425 [main] sh 2884 _cygwin_istext_for_stdio: fd 1: opened as binary 51 44841 [main] uname 2816 void: 0x0 = signal (3, 0x1) 134 1054352 [sig] make 2168 sigpacket::process: signal 20 processing 129 44970 [main] uname 2816 fhandler_base::close: closing '/tmp/cygwin/freeze.1.err' handle 0x738 1511576 [main] sh 2884 _cygwin_istext_for_stdio: fd 2: opened as binary 70 1054422 [sig] make 2168 _cygtls::find_tls: sig 20 94 1054516 [sig] make 2168 sigpacket::process: signal 20, about to call 0x40C540 144 45114 [main] uname 2816 sigproc_terminate: entering 54 1054570 [sig] make 2168 setup_handler: trying to send sig 20 but signal 20 already armed 61 1054631 [sig] make 2168 setup_handler: signal 20 not delivered 149 45263 [sig] uname 2816 wait_sig: done 49 1054680 [sig] make 2168 sigpacket::process: returning 0 62 45325 [sig] uname 2816 _cygtls::remove: wait 0x0 76 1054756 [sig] make 2168 proc_subproc: args: 3, 0 60 1054816 [sig] make 2168 proc_subproc: looking for processes to reap 71 1054887 [sig] make 2168 proc_subproc: finished processing terminated/stopped child 173 45498 [main] uname 2816 proc_terminate: nchildren 0, nzombies 0 50 1054937 [sig] make 2168 proc_subproc: returning 1 112 45610 [main] uname 2816 proc_terminate: leaving 716 46326 [main] uname 2816 __to_clock_t: dwHighDateTime 0, dwLowDateTime 156250 60 46386 [main] uname 2816 __to_clock_t: total 000F 51 46437 [main] uname 2816 __to_clock_t: dwHighDateTime 0, dwLowDateTime 312500 50 46487 [main] uname 2816 __to_clock_t: total 001F 17633339 [main] sh 2884 parse_options: error_start (called func) 1003439 [main] sh 2884 parse_options: returning 523491 [main] sh 2884 pinfo_init: pid 2884, pgid 2168 4193910 [main] sh 2884 sigproc_init: process/signal handling enabled(C1) 783988 [main] sh 2884 dll_crt0_1: user_data-main 0x4081F0 604048 [main] sh 2884 wait_for_sigthread: wait_sig_inited 0x750 2424290 [sig]
Re: please try the latest snapshot
Volker Quetschke wrote: Christopher Faylor wrote: The latest snapshot should fix virtual memory exhausted errors that were reported when running make -j. I am close to releasing cygwin 1.5.8 so I want to verify that this is fixed. OK, did that, and got a freeze after 196 iterations. Still using your make with debug info. This time my script enabled the malloc debug info strace -mall+malloc -o strace.out make -j -f MakefileV $logname 2 $logerr so the strace is very long, you can find it here: http://www.scytek.de/cygwin/strace.zip Unfortunately I pressed CTRL-c before looking at the running processes, I cannot say where it was hanging. Volker I've run it twice so far, 128 iterations, then about 2500, running it a third time now. In both cases, it was make hanging with 0% cpu usage, and I lost the strace from the second run (I tried using /bin/kill -f pid, and the return code from the make process was 0, so the script kept going). -Rolf -- 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: Snapshot 20040306: make hangs
Christopher Faylor wrote: If you want to analyze the strace yourself and offer comment, then please do so. Sending strace snippets is normally useless. 99% of the time, people send the equivalent of a photo of an accident scene with the thought that the picture will show why the accident occurred, i.e., the strace snippet is worthless. I gave up trying to inspect unsolicited strace output a long time ago. cgf I did notice one pattern after stairing blindly at strace output for a while. Every time it freezes, there is a: 43 4628798 [sig] make 2064 setup_handler: signal 20 not delivered 47 4628845 [sig] make 2064 sigpacket::process: returning 0 very near the end of strace output (last 10 lines). And on every successful run that I've looked at, I see: 43 6057447 [sig] make 3768 setup_handler: signal 20 delivered 41 6057488 [sig] make 3768 sigpacket::process: returning 1 in the last 150 lines of stace output. What is signal 20 anyway? I see it get 'not delivered' in the success runs too, but never so close to the end (1000's of lines up from the end). -Rolf -- 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: Snapshot 20040225: make hangs/errors out
Christopher Faylor wrote: No, but I'll try to catch one. (I removed the strace from my script.) Ok, caught two already. (Produced with attached script + Makefile) Not much to there, unfortunately. Out of curiousity, can you duplicate this problem with the snapshot? I see that this is your own build, probably built with --enable-debugging. I've been diligently testing things with the snapshot rather than my own build because I was trying to debug what was in the subject. Snapshots aren't built with --enable-debugging. If this is just an artifact from building with --enable-debugging, then I'm not too worried. cgf Ok, I've been running the script with the '25 snapshot all day, with 44 failures. All the same type of failures I was seeing with the cvs (with --enable-debugging). Unfortunitely, the ethernet card on my home machine broke so for now I'll upload one of the strace files to a geocites site. Nothing looks suspicious to me in the strace, maybe it's a bug in make? http://www.geocities.com/endlisnis/Temp/freeze.zip What I did notice is that I'm getting a tonne of failures make: *** virtual memory exhausted. Stop. grep'ing through the make source (which I was unable to compile) I see that this can happen when malloc returns NULL (makes sense from the message), and I can say that my machine has plenty of memory left. 1Gig of ram, and my commit charge never exheaded 500Megs during the whole test. I have my 'heap_chunk_in_mb' set to 1024. -Rolf -- 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: gcc 2.95
gcc version 3.3 works fine, gcc v2.95 was broken on cygwin and nobody wanted to fix it, so it was discontinued. Erick Castillo wrote: Need to install gcc 2.95 on the latest cygwin release. gcc version 3.3... does not work properly. Where could i find 2.95 if not through the simple cygwin install wizard? Will version 2.95 even work on the latest cygwin release? Any information on this would be incredibly useful. thanks. --Erick Castillo -- 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: Snapshot 20040225: make hangs/errors out
Christopher Faylor wrote:
On Tue, Mar 02, 2004 at 02:27:33PM -0500, Volker Quetschke wrote:
I can reproduce with that snapshot, but I get slightly different
results. Here is the stderr output from 1052 runs, but the strange
thing is that even when I get errors, the task continues to run. It
seems somehow that the return code of the errored run gets lost or
something.
Are you still using this script:
export C=1 while strace -o strace.$C.txt make -j ; do C=$(($C+1)) ;
done echo Failed after $C runs
If yes: The strace catches the errors. I use a script without strace
and the while catches the error of the make command.
Do you actually have an strace which demonstrates the problem? I
don't any indication that you've duplicated this problem running
strace with a modern snapshot.
I have reproduced the problem with a recent snapshot ('25), and strace,
but I am only using a single strace output file, so it keeps going and
over-writes the errored strace with the next run. I will run it tonight
while preserving all strace logs, but I can only run for about 1500
iterations before I fill my disk. I hope it happens before that.
Is there any way to tell strace to mimic the return code of it's
inferior process?
-Rolf
--
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: Snapshot 20040225: make hangs/errors out
I can reproduce with that snapshot, but I get slightly different results. Here is the stderr output from 1052 runs, but the strange thing is that even when I get errors, the task continues to run. It seems somehow that the return code of the errored run gets lost or something. This is different than how the '21 snapshot worked on my machine. make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs @: not found make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs 2840238 [main] make 1392 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 2850856 [main] make 1392 open_stackdumpfile: Dumping stack trace to make.exe.sta ckdump make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** virtual memory exhausted. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs Volker Quetschke wrote: Trapping this errors is a bit tedious, at the moment I'm using the attached script to catch the errors, but instead of a new stackdump/gdb prompt I got a new record, 2559 iterations until reaching an error. OK, enough! The script run since yesterday, with the debugging enabled make.exe and cygwin1.dll. I got: Thu Feb 26 17:11:34 EST 2004 make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs Failed after 2048 runs MakefileV:6: *** unterminated variable reference. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs Failed after 294 runs make: -c: Command not found make: *** [28.pp] Error 127 make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs Failed after 256 runs make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs Failed after 1857 runs make: -c: Command not found make: *** [14.pp] Error 127 make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs Failed after 5356 runs make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs Failed after 1387 runs make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs make: *** Waiting for unfinished jobs Failed after 211 runs make: *** wait: No children. Stop. make: *** Waiting for unfinished jobs make: *** wait: No children. Stop. Failed after 887 runs make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs Failed after 690 runs make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs Failed after 1459 runs c: c: No such file or directory make: *** [9.pp] Error 127 make: *** Waiting for unfinished jobs Failed after 6226 runs Stopped the the script at iteration 563. No stackdump. Any ideas? This takes way to long to reproduce. I never run this script with cygwin 1.5.5 maybe it fails there too. Maybe the freezes I got building OOo are long fixed and this was always broken? Or sh (ash) or even make has a problem and not cygwin. This gets us nowhere. Volker Exception: STATUS_ACCESS_VIOLATION at eip=0040DC0B eax=0002 ebx=0A067DA0 ecx=6574783D edx=0001 esi=0A05CA88 edi=0A069A28 ebp=0022E478 esp=0022E470 program=C:\cygwin\bin\make.exe cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 0022E478 0040DC0B (0A067DA0, 0022E4AC, 0001, ) 0022E4C8 0040C91E (, , 0A05C860, 610C8A9F) 0022E508 0040D77B (0A05D3A8, 0003, , ) 0022E578 00419E15 (0A05D3A8, 0002, , 0002) 0022E598 00418FCA (0A05D3A8, 0002, 0022E5C8, 004010DF) 0022E5E8 0041AADF (0A05D3A8, 0001, 0001, ) 0022E658 0041A2F7 (0A05CA10, 0001, , 0A05CA10) 0022E678 00418FCA (0A05CA10, , 0022E6B8, 61055BB7) 0022E6C8 00418C8F (0A0602F0, , 0022EF58, ) 0022F080 0041146E (0002, 0A040B48, 0A0400A8, 61005A20) 0022F0D0 61005EB4 (0022F0E8, 0024,
Re: Snapshot 20040221: make hangs on XP
Christopher Faylor wrote: --- t.sh --- #!/bin/bash export C=1 while make -j ; do C=$(($C+1)) ; done echo Failed after $C runs 12 --- end of t.sh --- The script failed with: $ ./t.sh freeze.out /bin/sh: line 1: sleep: No such file or directory make: *** [12.pp] Error 127 make: *** Waiting for unfinished jobs Failed after 1499 runs I ran a variation of the above for three days without fail so I think I can safely say that I can't reproduce this problem. And, by the way: http://cygwin.com/ml/cygwin/2004-02/msg00923.html cgf I tried running that script again, here were my results: Feb14: more than 10,000 iterations (never failed, just got bored of watching it) Feb17: more than 270 (still running) Feb18: Froze after 12, 41, 6 Feb20: Froze after 9, 2, 4 Feb21: Froze after 1, 5, 4 My un-educated guess is: 2004-02-17 Corinna Vinschen [EMAIL PROTECTED] * fork.cc (fork_child): Move fixup_shms_after_fork so that signal_arrived is initialized when calling it. In every case of freezing, the make process gobbled up all the CPU it could. -Rolf Cygwin Win95/NT Configuration Diagnostics Current System Time: Wed Feb 25 13:55:07 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' CLIENTNAME = `Console' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DESK-RCAMPBELL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `desk-rcampbell' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\OTTDC2' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/home/rcampbell' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `RDP-Tcp#1' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `xterm' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TROPIC_UNIQUE_ID = `156' USERDNSDOMAIN = `TROPICNETWORKS.COM' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINDOWS' WINDOWID = `168123432' _ = `/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin (default) = 0x0400 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 39260Mb 48% CP CS UN PA FC d: cd N/AN/A C:\cygwin / system binmode C: /c system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\ld.exe Found:
Re: Snapshot 20040221: make hangs on XP
Christopher Faylor wrote: I tried running that script again, here were my results: Feb14: more than 10,000 iterations (never failed, just got bored of watching it) Feb17: more than 270 (still running) Feb18: Froze after 12, 41, 6 Feb20: Froze after 9, 2, 4 Feb21: Froze after 1, 5, 4 Out of curiousity, the next time it freezes, try hitting CTRL-D. I ran one of the scripts for four hours and got a freeze. gdb showed that make was sitting in console input mode for some reason. Hitting ctrl-d (followed two seconds by an expletive) got things running again. I can say that is not what is happening (because it would not be using any CPU if it were waiting for input), but I will humour you the next time I see it freeze. I have (once) had that happen (make waiting for input that is), but I never thought of hitting ^D. And, just for completeness, I built and ran a CVS version from about an hour ago, and it has not failed yet (350 iterations). So, maybe someone already fixed this problem after Feb21. -- 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: Snapshot 20040221: make hangs on XP
Volker Quetschke wrote: And, just for completeness, I built and ran a CVS version from about an hour ago, and it has not failed yet (350 iterations). So, maybe someone already fixed this problem after Feb21. No, not for me. I'm using the same version, see my other mail, but it seems very hard to trigger the problem. I tried to use uname instead of sleep 1. This doesn't seem to fail either (752 iterations). Boom. Error after 832 runs. $ ./u.sh freezeU.out make: *** wait: Interrupted system call. Stop. make: *** Waiting for unfinished jobs Failed after 832 runs Volker Oh, come to think of it, I did get that error once with the Feb14th snapshot, after about 1500 runs. But my latter attempt ran for over 10,000 so I didn't mention it. And I've never seen it since. And I'm still running the CVS with sleep 1, and it's 1000 iterations without any problems. I will run it overnight tonight just for kicks. -- 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/
Valentine's snapshot rules (was: Re: latest CVS: make hangs on XP (with HT))
I just tried the feb 14th snapshot on my XP(HT) machine, and the my test ran over 5100 iterations before finnaly exhausting my disk space with strace output, but there were NO FAILURES!! I'm going to let it run with strace turned off just to see how far it will go, but this looks very good. Rolf Campbell wrote: I tried using lates CVS too, here are the results: Time to freeze: 761 and 409 iterations This is MUCH better than before, but it still does freeze (althought a big difference now is that when make freezes, it consumes no CPU). I'm speculating it has something to do with: trying to send sig 20 but signal 20 already armed Here is an strace tail from the process that froze: -- 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: What kind of executable is zcat? Crashes from cmd.exe
Jamshid Afshar wrote: I just installed Cygwin. What kind of executable is zcat.exe? It doesn't show up when I dir c:\cygwin\bin\zc* (only zcmp), but I see it's 19 bytes in Explorer. It works fine within bash, but I want UNIX utilities I can use in the regular Windows Command Prompt. $ ls -l zcat.exe lrwxrwxrwx1 rcampbel Users 19 Jan 6 17:06 zcat.exe - gzip.exe As you can see from the ls output, it's a symbolic link (doesn't work in cmd). You can still call gunzip -c (or whatever). -- 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/
latest CVS: make hangs on XP (with HT)
Volker Quetschke wrote: Just FYI, I build a cygwin dll from current cvs (last winsup/cygwin/ChangeLog entry 2004-02-09 Ralf H.) with debugging enabled and rerun this script. It didn't freeze, I stopped it after 1588 iterations, but it produced one stackdump and wrote some errors from make to stderr: $ ./t.sh freeze.out 988627 [main] make 3376 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION 996727 [main] make 3376 open_stackdumpfile: Dumping stack trace to make.exe.stackdump make: *** virtual memory exhausted. Stop. ... Volker I tried using lates CVS too, here are the results: Time to freeze: 761 and 409 iterations This is MUCH better than before, but it still does freeze (althought a big difference now is that when make freezes, it consumes no CPU). I'm speculating it has something to do with: trying to send sig 20 but signal 20 already armed Here is an strace tail from the process that froze: 176 1089336 [main] sh 2968 __to_clock_t: dwHighDateTime 0, dwLowDateTime 156250 39 1089375 [main] sh 2968 __to_clock_t: total 000F 35 1089410 [main] sh 2968 __to_clock_t: dwHighDateTime 0, dwLowDateTime 156250 33 1089443 [main] sh 2968 __to_clock_t: total 000F 1102 1090545 [main] sh 2968 _pinfo::exit: Calling ExitProcess 0 23418 4462811 [proc] make 5012 proc_subproc: args: 2, 0 83 4462894 [proc] make 5012 proc_subproc: pid 2968[0] terminated, handle 0x654, nchildren 1, nzombies 7 51 4462945 [proc] make 5012 proc_subproc: zombifying [0], pid 2968, handle 0x654, nchildren 1 52 4462997 [proc] make 5012 proc_subproc: returning 1 51 4463048 [proc] make 5012 sig_send: sendsig 0x70C, pid 5012, signal 20, its_me 1 61 4463109 [proc] make 5012 sig_send: Not waiting for sigcomplete. its_me 1 signal 20 45 4463154 [proc] make 5012 sig_send: returning 0x0 from sending signal 20 41 4463195 [proc] make 5012 wait_subproc: looping 57 4463252 [sig] make 5012 sigpacket::process: signal 20 processing 52 4463304 [sig] make 5012 _threadinfo::find_tls: sig 20 56 4463360 [sig] make 5012 sigpacket::process: signal 20, about to call 0x40C540 67 4463427 [sig] make 5012 setup_handler: trying to send sig 20 but signal 20 already armed 52 4463479 [sig] make 5012 setup_handler: signal 20 not delivered 52 4463531 [sig] make 5012 sigpacket::process: returning 0 52 4463583 [sig] make 5012 proc_subproc: args: 3, 0 56 4463639 [sig] make 5012 proc_subproc: looking for processes to reap 51 4463690 [sig] make 5012 proc_subproc: finished processing terminated/stopped child 52 4463742 [sig] make 5012 proc_subproc: returning 1 Cygwin Win95/NT Configuration Diagnostics Current System Time: Tue Feb 10 10:51:01 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' C = `409' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DESK-RCAMPBELL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `desk-rcampbell' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\OTTDC1' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/home/rcampbell' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `xterm' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TROPIC_UNIQUE_ID = `156' USERDNSDOMAIN = `TROPICNETWORKS.COM' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINDOWS' WINDOWID = `168123408' _ = `/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
Re: 'errno' bug in cygwin+samba
First of all, learn to include the correct headers, and to write valid
C-code. Here's what you meant to type.
#include sys/stat.h
#include sys/types.h
#include fcntl.h
#include unistd.h
#include stdio.h
int main() {
if(mkdir(test, 0777) 0)
perror(mkdir1);
if(mkdir(test, 0777) 0)
perror(mkdir2);
return 0;
}
2nd of all, I get:
mkdir2: File exists
3rd of all:
http://cygwin.com/problems.html
W.J. van der Laan wrote:
Hello,
Today I stumbled on a really strange bug in Cygwin and Samba: errno 2 is
returned when attempting to create a file or directory that already
exists.
#include stdlib.h
#include unistd.h
void main() {
if(mkdir(test, 0777) 0)
perror(mkdir1);
if(mkdir(test, 0777) 0)
perror(mkdir2);
}
Gives a mkdir2: No such file or directory. huh?
This happens on more occasions; execute this on a mounted samba filesystem
under windows, like /cygdrive/p/...
import shelve
shelve.open(test, flag='c')
shelve.open(test, flag='c')
Traceback (most recent call last):
File ./test.py, line 3, in ?
shelve.open(test, flag='c');
File /usr/lib/python2.3/shelve.py, line 231, in open
return DbfilenameShelf(filename, flag, protocol, writeback, binary)
File /usr/lib/python2.3/shelve.py, line 212, in __init__
Shelf.__init__(self, anydbm.open(filename, flag), protocol, writeback,
binary)
File /usr/lib/python2.3/anydbm.py, line 83, in open
return mod.open(file, flag, mode)
File /usr/lib/python2.3/dbhash.py, line 16, in open
return bsddb.hashopen(file, flag, mode)
File /tmp/python.2664/usr/lib/python2.3/bsddb/__init__.py, line 192,
in hashopen
bsddb._db.DBNoSuchFileError: (2, 'No such file or directory')
Exception exceptions.AttributeError: DbfilenameShelf instance has no
attribute 'writeback' in ignored
It gives an 'No such file or directory' the second time, while the shelve
is succesfully created. It seems to produce this error when a file already
exists.
This essentially makes shelve useless under cygwin.
Greetings,
Wladimir
--
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: 1.5.8s: make hangs on XP (with HT)
Rafael Kitover wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rolf Campbell Sent: Thursday, February 05, 2004 8:40 AM To: [EMAIL PROTECTED] Subject: 1.5.7: make hangs on XP (with HT) I've been trying to narrow the problem I've been having with make (-j) and processes locking up. And I've made some progress. First, this happens with 1.5.6 - 1.5.7 (and every snapshot in-between). I've tried this test on 3 configurations: WinXP (HyperThreaded): fails quickly (between 20 seconds and 3 minutes) Win2000 (Not HT): fails slowly (between 6 minutes and 20 minutes) WinXP (HT turned off): does not fail (ran it for about an hour and it was fine). [SNIP] This test would fail on me on WinXP on an HT machine very quickly with 1.5.7 and earlier snapshot, but with the most recent CVS it works fine :) I tried the Feb05 snapshot, and things are MUCH better. Instead of failing after 1 to 36 iterations, it now lasts into the hundreds, but it still does eventually fail. On iteration #337 (about 20 minutes in), I got a similar strace output: And, like before, after this output, the process continued to run, consuming as much processor time as it could. 186 1375242 [main] sh 10144 __to_clock_t: dwHighDateTime 0, dwLowDateTime 0 47 1375289 [main] sh 10144 __to_clock_t: total 48 1375337 [main] sh 10144 __to_clock_t: dwHighDateTime 0, dwLowDateTime 312500 46 1375383 [main] sh 10144 __to_clock_t: total 001F -178 1375205 [sig] sh 10144 wait_sig: done 1642 1376847 [sig] sh 10144 _threadinfo::remove: wait 0x0 147 1376994 [main] sh 10144 _pinfo::exit: Calling ExitProcess 0 20174 4390513 [proc] make 3748 proc_subproc: args: 2, 0 82 4390595 [proc] make 3748 proc_subproc: pid 10144[0] terminated, handle 0x650, nchildren 1, nzombies 8 50 4390645 [proc] make 3748 proc_subproc: zombifying [0], pid 10144, handle 0x650, nchildren 1 51 4390696 [proc] make 3748 proc_subproc: returning 1 50 4390746 [proc] make 3748 sig_send: sendsig 0x714, pid 3748, signal 20, its_me 1 62 4390808 [proc] make 3748 sig_send: Not waiting for sigcomplete. its_me 1 signal 20 44 4390852 [proc] make 3748 sig_send: returning 0x0 from sending signal 20 171 4391023 [proc] make 3748 wait_subproc: looping 9 4391032 [sig] make 3748 sigpacket::process: signal 20 processing 109 4391141 [sig] make 3748 _threadinfo::find_tls: sig 20 51 4391192 [sig] make 3748 sigpacket::process: signal 20, about to call 0x40C540 49 4391241 [sig] make 3748 setup_handler: suspending mainthread 80 4391321 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 54 4391375 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 60 4391435 [sig] make 3748 setup_handler: suspending mainthread 72 4391507 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 55 4391562 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 62 4391624 [sig] make 3748 setup_handler: suspending mainthread 135 4391759 [sig] make 3748 interruptible: pc 0x77E66B4A, h 0x77E6, interruptible 0 50 4391809 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 63 4391872 [sig] make 3748 setup_handler: suspending mainthread 68 4391940 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 54 4391994 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 80 4392074 [sig] make 3748 setup_handler: suspending mainthread 70 4392144 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 51 4392195 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 63 4392258 [sig] make 3748 setup_handler: suspending mainthread 68 4392326 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 75 4392401 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 62 4392463 [sig] make 3748 setup_handler: suspending mainthread 69 4392532 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 52 4392584 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 60 4392644 [sig] make 3748 setup_handler: suspending mainthread 67 4392711 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 51 4392762 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 52 4392814 [sig] make 3748 setup_handler: suspending mainthread 67 4392881 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 42 4392923 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 48 4392971 [sig] make 3748 setup_handler: suspending mainthread 57 4393028 [sig] make 3748 interruptible: pc 0x7FFE0304, h 0x7FFE, interruptible 0 104 4393132 [sig] make 3748 setup_handler: couldn't interrupt. trying again. 48 4393180 [sig] make 3748 setup_handler: suspending mainthread 57 4393237 [sig] make 3748
Re: 1.5.8s: make hangs on 2000 (no HT)
Rolf Campbell wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rolf Campbell Sent: Thursday, February 05, 2004 8:40 AM To: [EMAIL PROTECTED] Subject: 1.5.7: make hangs on XP (with HT) I've been trying to narrow the problem I've been having with make (-j) and processes locking up. And I've made some progress. First, this happens with 1.5.6 - 1.5.7 (and every snapshot in-between). I've tried this test on 3 configurations: WinXP (HyperThreaded): fails quickly (between 20 seconds and 3 minutes) Win2000 (Not HT): fails slowly (between 6 minutes and 20 minutes) WinXP (HT turned off): does not fail (ran it for about an hour and it was fine). This test would fail on me on WinXP on an HT machine very quickly with 1.5.7 and earlier snapshot, but with the most recent CVS it works fine :) I tried the Feb05 snapshot, and things are MUCH better. Instead of failing after 1 to 36 iterations, it now lasts into the hundreds, but it still does eventually fail. On iteration #337 (about 20 minutes in), I got a similar strace output: And, like before, after this output, the process continued to run, consuming as much processor time as it could. I was also able to recreate this on Win2000 (iteration #268 failed). 70544 15704529 [proc] make 1784 proc_subproc: args: 2, 0 205 15704734 [proc] make 1784 proc_subproc: pid 684[0] terminated, handle 0x25C, nchildren 1, nzombies 5 96 15704830 [proc] make 1784 proc_subproc: zombifying [0], pid 684, handle 0x25C, nchildren 1 95 15704925 [proc] make 1784 proc_subproc: returning 1 91 15705016 [proc] make 1784 sig_send: sendsig 0x314, pid 1784, signal 20, its_me 1 149 15705165 [sig] make 1784 sigpacket::process: signal 20 processing 96 15705261 [sig] make 1784 _threadinfo::find_tls: sig 20 86 15705347 [sig] make 1784 sigpacket::process: signal 20, about to call 0x40C540 82 15705429 [sig] make 1784 setup_handler: suspending mainthread 119 15705548 [proc] make 1784 sig_send: Not waiting for sigcomplete. its_me 1 signal 20 91 15705639 [proc] make 1784 sig_send: returning 0x0 from sending signal 20 88 15705727 [proc] make 1784 wait_subproc: looping 165 15705892 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 87 15705979 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 135 15706114 [sig] make 1784 setup_handler: suspending mainthread 122 15706236 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 79 15706315 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 118 15706433 [sig] make 1784 setup_handler: suspending mainthread 124 15706557 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 76 15706633 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 117 15706750 [sig] make 1784 setup_handler: suspending mainthread 115 15706865 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 77 15706942 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 115 15707057 [sig] make 1784 setup_handler: suspending mainthread 116 15707173 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 78 15707251 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 117 15707368 [sig] make 1784 setup_handler: suspending mainthread 116 15707484 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 82 15707566 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 116 15707682 [sig] make 1784 setup_handler: suspending mainthread 116 15707798 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 77 15707875 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 114 15707989 [sig] make 1784 setup_handler: suspending mainthread 118 15708107 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 76 15708183 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 117 15708300 [sig] make 1784 setup_handler: suspending mainthread 116 15708416 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 84 15708500 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 116 15708616 [sig] make 1784 setup_handler: suspending mainthread 116 15708732 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 77 15708809 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 116 15708925 [sig] make 1784 setup_handler: suspending mainthread 116 15709041 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 77 15709118 [sig] make 1784 setup_handler: couldn't interrupt. trying again. 117 15709235 [sig] make 1784 setup_handler: suspending mainthread 116 15709351 [sig] make 1784 interruptible: pc 0x77F92450, h 0x77F8, interruptible 0 76 15709427 [sig] make 1784 setup_handler: couldn't
Re: strange thing for execlp() function
kaiduan xie wrote:
Hi,all,
I just want to use execlp to invoke another program
from a program. It works on Linux, but it stucks on
Cygwin. Acutally, this is a very very very simple
program:
#include stdio.h
#include sys/types.h
#include unistd.h
#include errno.h
#include string.h
int main()
{
pid_t pid;
printf(Hello, cygwin!\n);
if (execlp(/home/kaiduan/test2.exe,
test2.exe,(char *)0) 0)
printf(Error is %s\n, strerror(errno));
}
I also added current directy to PATH, but it still
sucks. Anything wrong?
Yes, there is something wrong. You haven't said what the problem is
(other than it sucking). This program works fine for me if i change the
line to /bin/ls.exe.
--
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: printf does not print long long ints properly
ll is the long long prefix.
Daniel Jeliski wrote:
when I compile the following program:
#include stdio.h
main()
{
long long i;
i=100;
i*=100;
printf(%Ld,i);
return 0;
}
I get the following:
-727379968
instead of the expected 1
I am using gcc 3.3.1
the same code works nicely on linux machine with gcc 3.3.1
is any other information necessary?
dj
--
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: regtool freezes on XP (Was: Re: [ANNOUNCEMENT] Updated: cygwin-1.5.6-1)
Christopher Faylor wrote: On Mon, Jan 19, 2004 at 01:48:52PM -0800, David Rothenberger wrote: I think the problem is bash, not regtool. The following script also displays the problem: ---begin script--- #!/bin/sh ls ---end script--- Does the latest snapshot fix this problem? Yes, yes it does. -- 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/
1.5.7s: gdb crash on exit
I just realized that gdb (at least on my machine) always crashes if you attach to any process, then try to quit. Rolf Campbell wrote: I've noticed a problem with the snapshot (it's not limited to the snapshot, it was there in 1.5.6 as well). The problem may have been in 1.5.5 as well, but it was definitely less pronounced there. If I run make -j6 or something, on our large corporate build environment, then sometimes, one or more make instances will end up freezing. (They spin in place, using up as much cpu as they can, forever). ^C stops them. I can't find any easy way to produce this with smaller examples (and it doesn't even always happen on my big builds). It seems to happen about 75% of the time with my builds, so I don't have any real problem reproducing it. I tried attaching to the process with gdb, but I didn't really know what to do after I was attached: - (gdb) attach 524 Attaching to process 524 [Switching to thread 524.0x38c] (gdb) bt #0 0x77f75a59 in ntdll!DbgUiConnectToDbg () from /c/WINDOWS/System32/ntdll.dll #1 0x77f5f31f in ntdll!KiUserCallbackDispatcher () from /c/WINDOWS/System32/ntdll.dll #2 0x0005 in ?? () #3 0x0004 in ?? () #4 0x0001 in ?? () #5 0x003fffd0 in ?? () #6 0x85005480 in ?? () #7 0x in ?? () #8 0x77fa88f0 in wcstombs () from /c/WINDOWS/System32/ntdll.dll (gdb) p/x *(int *)$ebp $1 = 0x0 (gdb) info thread * 4 thread 524.0x38c 0x77f75a59 in ntdll!DbgUiConnectToDbg () from /c/WINDOWS/System32/ntdll.dll 3 thread 524.0x270 0x7ffe0304 in ?? () 2 thread 524.0xc14 0x7ffe0304 in ?? () 1 thread 524.0xff0 0x00419015 in ?? () (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) ye Segmentation fault (core dumped) [EMAIL PROTECTED] ~ $ Also, gdb crashed as you can see. Gdb seems to crash if i attach to a process, then try to quit. I ran gdb under gdb, but it didn't produce a usefull traceback: (gdb) q Program received signal SIGSEGV, Segmentation fault. 0x0042454c in ?? () (gdb) bt #0 0x0042454c in ?? () #1 0x0ec0 in ?? () I understand that I haven't provided much usefull info, I am willing to try other things apon suggestion. Cygwin Win95/NT Configuration Diagnostics Current System Time: Tue Jan 20 12:04:02 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' CLIENTNAME = `Console' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DESK-RCAMPBELL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `desk-rcampbell' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\EXCHANGE' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/c/base2/node' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `xterm' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TROPIC_UNIQUE_ID = `150' USERDNSDOMAIN = `TROPICNETWORKS.COM' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINDOWS' WINDOWID = `168127776' _ = `/usr/bin/cygcheck' 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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags
regtool freezes on XP (Was: Re: [ANNOUNCEMENT] Updated: cygwin-1.5.6-1)
When I run this script *not* from another cygwin program (Windows Run menu as bash -c scriptname.sh, or from W32 GNU Emacs) ---begin script #!/bin/sh echo -n Getting location... regtool get '\' ---end script I get the expected output: Getting location...Unknown key prefix. Valid prefixes are: root HKCR HKEY_CLASSES_ROOT config HKCC HKEY_CURRENT_CONFIG user HKCU HKEY_CURRENT_USER machine HKLM HKEY_LOCAL_MACHINE users HKU HKEY_USERS BUT, it then freezes (that is sh.exe freezes, after regtool finishes) (Ctrl+C does nothing, kill -9 does nothing, /bin/kill -f works). This worked correctly in 1.5.5, and it still works on my Win2000Pro box, but not on my XP box. It does not matter what arguments you pass to regtool (I just tried it with none and it still froze). This is a hyperthreaded machine (if that makes any difference). I can try it with HT turned off if you want. Cygwin Win95/NT Configuration Diagnostics Current System Time: Mon Jan 19 16:21:34 2004 Windows XP Professional Ver 5.1 Build 2600 Service Pack 1 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Output from C:\cygwin\bin\id.exe (nontsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 10513(Domain Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 11643(rcampbell) GID: 10513(Domain Users) 544(Administrators) 545(Users) 10513(Domain Users) SysDir: C:\WINDOWS\System32 WinDir: C:\WINDOWS HOME = `C:\cygwin\home\rcampbell' MAKE_MODE = `unix' PWD = `/tmp' USER = `rcampbell' ALLUSERSPROFILE = `C:\Documents and Settings\All Users' APPDATA = `C:\Documents and Settings\rcampbell\Application Data' CLIENTNAME = `Console' COLORFGBG = `0;default;15' COLORTERM = `rxvt-xpm' COMMONPROGRAMFILES = `C:\Program Files\Common Files' COMPUTERNAME = `DESK-RCAMPBELL' COMSPEC = `C:\WINDOWS\system32\cmd.exe' COSMIC = `t' CVS_RSH = `/bin/ssh' DISPLAY = `:0' HOMEDRIVE = `C:' HOMEPATH = `\Documents and Settings\rcampbell' HOSTNAME = `desk-rcampbell' INFOPATH = `/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:' LOGONSERVER = `\\EXCHANGE' MANPATH = `/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man' NUMBER_OF_PROCESSORS = `2' OLDPWD = `/home/rcampbell' OS = `Windows_NT' P4CONFIG = `.p4config' PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' PROCESSOR_ARCHITECTURE = `x86' PROCESSOR_IDENTIFIER = `x86 Family 15 Model 2 Stepping 9, GenuineIntel' PROCESSOR_LEVEL = `15' PROCESSOR_REVISION = `0209' PROGRAMFILES = `C:\Program Files' PS1 = `\[\033]0;\w\007 [EMAIL PROTECTED] \[\033[33m\w\033[0m\] $ ' SESSIONNAME = `Console' SHLVL = `1' SYSTEMDRIVE = `C:' SYSTEMROOT = `C:\WINDOWS' TEMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' TERM = `xterm' TMP = `C:\DOCUME~1\RCAMPB~1\LOCALS~1\Temp' USERDNSDOMAIN = `TROPICNETWORKS.COM' USERDOMAIN = `TROPICNETWORKS' USERNAME = `rcampbell' USERPROFILE = `C:\Documents and Settings\rcampbell' WINDIR = `C:\WINDOWS' WINDOWID = `168128144' _ = `/usr/bin/cygcheck' 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_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c (default) = `C:' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd NTFS 39260Mb 45% CP CS UN PA FC d: cd N/AN/A C:\cygwin / system binmode C: /c system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Found: C:\cygwin\bin\gdb.exe Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe 61k 2003/08/09
