Re: 256x256 px icons
On Aug 3 06:54, Andy Koppe wrote: On 2 August 2011 17:06, Corinna Vinschen wrote: On Aug 2 11:45, Charles Wilson wrote: On 8/2/2011 11:24 AM, Corinna Vinschen wrote: I guess we're getting close to the end result now. So, how are you (Andy, Corinna) planning to handle the .ico file(s) themselves? Are you 1. (Andy) planning to put it/them into the mintty executable as resource(s), 2. ship the .ico file(s) in '/' as part of the main cygwin package, as we have long done with cygwin.ico 3. Incorporate it/them into cygicon*.dll as part of the cygutils package or some combination? I'm open to #3, but I'll need provenance and licensing info (see the end of /usr/share/doc/cygutils/cygicons/README ) I would stick to the standard terminal icon for mintty(*), except in the case of the Cygwin Terminal desktop and start menu icons. Sounds good to me. Both files will be installed into / just as today. I thought the desktop and start menu icons would be the same. (Setup.exe's icon might be different.) Right. But even if the terminal uses the terminal C, I think it doesn't hurt to provide the standalone C as well (think brand). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [Patch] Add rebase-dump application to rebase package
On Aug 1 09:28, Charles Wilson wrote: On 8/1/2011 3:56 AM, Corinna Vinschen wrote: Looks good to me. As you probably noticed, I didn't manage to move the db functions into rebase-dump.c so far, though. Otherwise there wouldn't be a need to have your own load_image_info function. Do you want me to do that before or after you applied your patch? (a) I figured it should come after, and (b) at first, rebase-dump probably just needs to rename its version of load_image_info to avoid conflicts, since the two versions are (slightly) different. I agree that rebase-dump.exe SHOULD use the same load_image_info() that the real rebase.exe does, but that ought to be a third patch IMO. Because rebase-dump's version needs a SMALL rewrite to use the dump_* functions -- and dump_*_entry needs a tiny tweak to make that work right -- but most importantly, the new combined load_image_info needs to have the 'verbose' option passed down. So, in your patch, I think just ignoring rebase-dump entirely -- /except/ for changing the name of its load_image_info -- is the way to go. Then I'll post a third patch, discussed separately, that tries to merge the two versions. Hmm. I just figured that moving the entire db stuff into rebase-db.c isn't as simple as I imagined. Functions and global variables are pretty much intertwined in a non modular way. I assume you might just go ahead and apply your dumper and we get a new rebase package out of the door. We can clean this up later. Idle musing: I think we should create some sort of global settings structure which can be used as a parameter or something... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [Patch] Add rebase-dump application to rebase package
On 8/3/2011 4:30 AM, Corinna Vinschen wrote: Hmm. I just figured that moving the entire db stuff into rebase-db.c isn't as simple as I imagined. Functions and global variables are pretty much intertwined in a non modular way. Yep...I had similar, but much smaller, issues when moving the dump_* methods to rebase-db.[h,c]. This will be a non-trivial refactoring. I assume you might just go ahead and apply your dumper and we get a new rebase package out of the door. We can clean this up later. Ack. Given Jason hasn't reponded to my patch, and your positive review, I've invoked the libtool 3-day rule and committed it. Idle musing: I think we should create some sort of global settings structure which can be used as a parameter or something... Yep. That's typically the way I handle these issues, even in very simple apps that don't need it -- 'cause they ALWAYS grow to become non-simple, and it's a lot harder to add it later. :-) But that can also wait until after the next release. AFAICT, we're ready to go -- so it's up to Jason to bump the library and application version numbers, tag it in cvs, and publish a new package. Jason? -- Chuck
Re: SETUP: default to mintty
On 8/3/2011 10:43 AM, Corinna Vinschen wrote: Ok, here's my final(?) patch to make setup install mintty as Cygwin Terminal desktop and start menu entries. Apart from the cygwin.ico file, there's now also a cygwin-terminal.ico file and a cygwin-setup.ico file. The latter is used as the default application icon. Only the first two are installed into / as Cygwin.ico and Cygwin-Terminal.ico. See below for the patch. Attached are the new ico files for the setup repository. If that's fine with everybody, Andy will also have to change the mintty postinstall script so that the mintty entry is not added to the start menu anymore. Builds fine for me, and works as advertised with new pretty icons. One thing of note: I haven't locally built setup since January, and even after stripping and upx'ing: -rwxrwxr-x 1 user group 889K Aug 3 11:33 setup.exe* -rwxrwxr-x 1 user group 648K Jan 26 2011 setup.exe-save* Most -- but not all -- of that is due to the new icons, which are only: -rw-rw-r-- 1 user group 34K Aug 3 11:20 cygwin.ico -rw-rw-r-- 1 user group 65K Aug 3 11:20 cygwin-setup.ico -rw-rw-r-- 1 user group 80K Aug 3 11:20 cygwin-terminal.ico I guess Jon's changes have added a lot of code :-) I'll wait until (a) a new setup with these changes and new icons has been 'officially' released, and (b) it's had time to 'settle', before attempting to add the new ico's to the cygicons dll. -- Chuck
Re: SETUP: default to mintty
On 3 August 2011 15:43, Corinna Vinschen wrote: On Jul 27 17:52, Corinna Vinschen wrote: On Jul 27 16:15, Andy Koppe wrote: On 27 July 2011 10:43, Corinna Vinschen wrote: On Jul 27 09:07, Andy Koppe wrote: On 27 July 2011 08:46, Corinna Vinschen wrote: On Jul 27 08:24, Andy Koppe wrote: I meant cygicons-0.dll,9. Yes, I like that one, too. we could use it as the default 48x48 and 64x64 icons. Per the MSFT guidelines in http://msdn.microsoft.com/en-us/library/aa511280.aspx#size, smaller sizes should stick to a 2D look. Maybe we can simply use the old icon for these sizes? The way I understand it, I think it's just that they shouldn't use perspective. Compare for example the drive icons in the Computer window, where they appear tilted in the main part of the window, but straight-on at 16x16 in the sidebar. The small icons do still have some depth to them. Well, ok. I was just thinking that at 16x16 there's no such thing as edginess. And at that size an icon should make a rather clear, simple impression. FWIW, 'cygicons-0.dll,9' looks better to me even at 16x16, not least because of the anti-aliasing. Also, it's this size that appears in the upper-left corner of windows, and I think it's good to have this correspond closely to the 32x32 icon appearing in the Windows 7 taskbar. Fine with me. Ok, here's my final(?) patch to make setup install mintty as Cygwin Terminal desktop and start menu entries. Apart from the cygwin.ico file, there's now also a cygwin-terminal.ico file and a cygwin-setup.ico file. The latter is used as the default application icon. Only the first two are installed into / as Cygwin.ico and Cygwin-Terminal.ico. See below for the patch. Attached are the new ico files for the setup repository. The Cygwin-Terminal.ico isn't good enough IMNSHO, and I'm disappointed with how this has suddenly become the official proposal, riding roughshod over much of the previous discussions. - Above you'd agreed that fatbuttlarry's bulgy icon was fine in the 16x16 version, and that was before making it bigger and turning its outline grey to lose that eerie look. Yet here we are with a murky flat effort that looks no better than ye olde Cygwin.ico. (This size is used for the window icon, so arguably this is the most important one.) - The terminal frame at the 32..64 sizes isn't as sharp as it could be, because it's copied from one of my attempts before I worked out how to render it like in the original Konsole icon. - The 256x256 version still has Warren's dark border around the terminal. Not only is this spoiling the KDE Oxygen team's work, but it also makes it pointlessly different from the smaller versions. Furthermore, the C still has rough corners due to the bottom line being too low, and its shadow makes little visual sense inside the terminal frame. - The Cygwin-symbol-in-terminal approach remains a dodgy compromise. It doesn't fit into 16x16, and as Warren pointed out, the removal of the prompt means that the terminal is hard to recognise as such. I can't remember a case for why this compromise is preferable over the Cygwin symbol on its own. To avoid being entirely negative, here's my proposal: forget about Cygwin-terminal.ico and just use Cygwin.ico. I like the setup.exe parcel idea, but this also needs improvements. In particular, the 16x16 version doesn't work, with the parcel just an ill-defined grey blob behind the C. Also, the shadow behind the C on the 256x256 makes even less visual sense here than in the terminal frame. Andy will also have to change the mintty postinstall script so that the mintty entry is not added to the start menu anymore. Yep. (That should make for a fair few complaints about how mintty has suddenly disappeared from the start menu though.) Andy
Re: SETUP: default to mintty
On 8/3/2011 2:37 PM, Andy Koppe wrote: - The 256x256 version still has Warren's dark border around the terminal. Not only is this spoiling the KDE Oxygen team's work, There's a 50% transparent black (so, gray when composited over white) border in the original KDE artwork. Are you saying you want to drop this, and make it like the silver terminal bezel goes to the icon edge? To avoid being entirely negative, here's my proposal: forget about Cygwin-terminal.ico and just use Cygwin.ico. What's wrong with using the lone Cygwin logo in 16 px through 32 px, then switching to logo-in-terminal for 48 px and up where there's enough resolution to allow it?
Re: 256x256 px icons
On 2 August 2011 16:24, Corinna Vinschen wrote: On Aug 2 15:49, Andy Koppe wrote: On 1 August 2011 21:05, Andy Koppe wrote: On 1 August 2011 09:07, Corinna Vinschen wrote: On Jul 31 21:21, Andy Koppe wrote: On 30 July 2011 21:22, Andy Koppe wrote: On 30 July 2011 19:36, Corinna Vinschen wrote: On Jul 29 21:29, Andy Koppe wrote: Attached is my take on this, with 64x64, 48x48, 32x32 showing fatbuttlarry's Cygwin symbol inside the Konsole icon, and 16x16 showing the Cygwin symbol only. Not bad, but the green border around the C is too dark to set the C apart from the background. The border needs some light grey which allows to recognize the C. I'm not sure how to do that, but the attached attempt turn up the saturation of the green outline. It also reduces the blurriness of the whole thing a bit. Apparently it's better to convert an SVG to a high-res bitmap and resize that down with a bitmap program such as Paint.net instead of converting the SVG straight to the target bitmap sizes (at least when using InkScape). The two attached icons differ at size 32: cygwin-terminal2.ico has the Cygwin-in-terminal there, whereas cygwin-terminal3.ico has just the Cygwin symbol. Size 32 shows up in the Windows 7 taskbar. Further to those two, here's one with the glowy Cygwin symbol all the way from size 16 to 64. It's a remastered version of the one in cygutils; a bit bigger and with the aforementioned brighter green outline around the C. Thanks. But, hmm. The longer I play with it, the less I like the green glow. It adds an eerie touch to the C Now what's wrong with that? Cygwin - mean and a bit eerie. ;) and it still doesn't set the C really apart on dark backgrounds. I disagree, looking at a desktop with a darkish picture and dark grey taskbar and window borders. I think we should go with a grey outline. I did eventually work out how to turn the outline of fatbuttlarry's icon grey. See attachments. Having used both variants for a while, I agree that a grey outline does look better. I tried your icons on my desktop and the standalone icon looks good. In the terminal icons the beveled C looks better than the fatbuttlarry C, cleaner, crisper. I think it would be better to stick to one. I don't particularly mind which, in principle anyway. Warren's has the advantage of a 256 version and that it's more tweakable assuming he provides the vector version it's presumably based on. It does need to lose that shadow though, and have the bottom edge fixed. Also, the bottom half of the green triangle is a bit on the dark side. It's also easier to distinguish from the dark background, but that's probably just because you used a darker shade of grey for the frame. In the terminal window, a lighter grey really doesn't hurt. It's pretty much the same grey actually (~220), at full size anyway. But the border is thinner and/or partially transparent in larry's. Therefore, when scaling it down, it blends into the background more. Generally it looks like your C's are a pixel or two smaller, except in the smallest sizes. Gimp shows that you're always leaving a transparent frame of at least one pixel. Any reason for that? Not really. Just seemed a prudent thing to do when cutting it out of the original, but you're right, there's no need for this, and I'd be happy to redo it. Andy
Re: AW: AltGr key mostly fires an additional CONTROL key
The actual issue here is that Windows apparently inserts a fake Ctrl-L keypress/release when AltGr is pressed/released (except when the keyboard layout is US). I have never found any documentation of this behavior, and I've no idea why it does this. There is some code in the X server which attempts to detect and discard these fake keypress/release events, but it not working reliably for some people has been reported a few times, but I've never been able to reproduce the problem or get to the bottom of what causes it. If you are willing to help, I've put together a test build with some extra debugging at [1]. If you could run that with '-logverbose 3' as before and attach the output, that would be helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20110801-git-2d9f9305cb559907.exe.bz2 no problem - here we go: The logs are attached. This is what I did: 1. /bin/startxwin -- XWin.20110801-git-2d9f9305cb559907.exe -emulate3buttons 100 -logverbose 3 2. It took me more attempts than usual to reproduce it, therefore the interesting part will be at the end of the log. 3. I manually killed the X-Server and took the log. 4. XWin.0.log is the full log of the session. 5. xev.txt: I have taken only the interesting part. My session in detail: I pressed several times AltGr and Q, nothing special, I get @ (it doesn't happen always - just then and when). I hold down AltGr for 2 seconds ... I play around. Then I get into the bug: I press AltGr and Q, then release both keys: I get CHAR 00. I just hit key A and instead of a I get CHAR 01 = CONTROL-A. I just hit key C and instead of c I get CHAR 03 = CONTROL-C. Then I (first time) hit the real CONTROL key to unlock that situation. In the xev-log you see only(!) a ReleaseEvent at that point. Then I press AltGr and Q again and I get CHAR HEX 40 = letter @. I hit key A and get a. Thanks for the logs, that was very useful. I still can't reproduce this (although holding AltGr down to make it autorepeat seems the best way to try to do that). It is a timing issue with the keypress/release messages so it might be sensitive to CPU speed, or perhaps you have some software installed which looks at keypress/release messages and changes the timing? I've had a go at fixing it. Can you please try the build I've uploaded at [1] and see if it still shows the problem for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Unable to open socket for inet
Just installed Cygwin/X on WIndows XP Pro, Version 2002, SP 3. When I invoke startxwin, here's what I get: -- bash startxwin Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.10.3.0 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Package: version 1.10.3-1 built 2011-07-19 XWin was started with the following command line: X :0 -multiwindow _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/GP3JDP1-E6410:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet _XSERVTransOpen: transport open failed for inet/GP3JDP1-E6410:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet _XSERVTransSocketOpenCOTSServer: Unable to open socket for local _XSERVTransOpen: transport open failed for local/GP3JDP1-E6410:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for local Fatal server error: Cannot establish any listening sockets - Make sure an X server isn't already running winDeinitMultiWindowWM - Noting shutdown in progress -- It seems as though there's a general networking issue: -- bash ping 127.0.0.1 icmp: unknown protocol -- but using Windows ping from a DOS prompt works fine: -- Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\ping 127.0.0.1 Pinging 127.0.0.1 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time1ms TTL=128 Reply from 127.0.0.1: bytes=32 time1ms TTL=128 Reply from 127.0.0.1: bytes=32 time1ms TTL=128 Ping statistics for 127.0.0.1: Packets: Sent = 3, Received = 3, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms Control-C ^C C:\ -- I am in the Administrators group, so raw sockets should work. We do run McAfee, so that could be an issue. Any ideas? Both for XWin and for ping? Are they related? Thanks, Tom -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
AW: AW: AltGr key mostly fires an additional CONTROL key
Thanks for the logs, that was very useful. I still can't reproduce this (although holding AltGr down to make it autorepeat seems the best way to try to do that). It is a timing issue with the keypress/release messages so it might be sensitive to CPU speed, or perhaps you have some software installed which looks at keypress/release messages and changes the timing? I've had a go at fixing it. Can you please try the build I've uploaded at [1] and see if it still shows the problem for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20110803-git-a493c0465e56ce0b.exe.bz2 Hi Jon, works fine for me. I Played around quite a while, but the CONTROL-locking didn't occur any more. Yippie! Is it ok, if I leave the hotfix file permanently in on my PC (I mean, did you base it on a recent XWin released version with just my bug fix in - or is there other experimental stuff inside?), then I'll use it automatically during work and I can let you know in case of problems. I wouldn't have started a thread with the following, but since we have already started looking at this keyboard, maybe you are interested in some of these: Tilde sign (~) should be a normal (not a blind) key. In Windows I hit AltGr++ to get ~, in XWin I need to type AltGr++ then space to get a ~. See attachment for the initial XWin xmodmap -pke table. Possible xmodmap correction (works fine): keycode 35 = plus asterisk plus asterisk asciitilde Euro Currency sign doesn't work. I know - it's not a latin1 character, but together with CP1252 this xmodmap correction works like Windows: keycode 26 = e E e E 0x0080 ALT+Space produces a NBSP character (HEX A0) in Windows, but not in XWin. xmodmap correction is unfortunately not possible, because the xmodmap setting on ISO_Level3_Shift+Space is just thrown away: Something like keycode 65 = space NoSymbol space NoSymbol nobreakspace or keycode 65 = space space space space nobreakspace doesn't work: it's discarded and the setting is not shown on a xmodmap -pke. So I put nobreakspace to the fifth place of another key - there it works. That would be good if key 65 (space key) would accept above xmodmap setting or have it initially. Number block is not working. See attachment for the initial XWin xmodmap -pke table (all these KP_* settings look good at the first sight, but the keys don't produce numbers). Possible xmodmap correction (works fine): keycode 63 = asterisk asterisk keycode 79 = 7 7 keycode 80 = 8 8 keycode 81 = 9 9 keycode 82 = minus minus keycode 83 = 4 4 keycode 84 = 5 5 keycode 85 = 6 6 keycode 86 = plus plus keycode 87 = 1 1 keycode 88 = 2 2 keycode 89 = 3 3 keycode 90 = 0 0 keycode 91 = period period keycode 108 = Return Return keycode 112 = slash slash Regards, Paul keycode 8 = keycode 9 = Escape NoSymbol Escape keycode 10 = 1 exclam 1 exclam onesuperior exclamdown onesuperior keycode 11 = 2 quotedbl 2 quotedbl twosuperior oneeighth twosuperior keycode 12 = 3 section 3 section threesuperior sterling threesuperior keycode 13 = 4 dollar 4 dollar onequarter currency onequarter keycode 14 = 5 percent 5 percent onehalf threeeighths onehalf keycode 15 = 6 ampersand 6 ampersand notsign fiveeighths notsign keycode 16 = 7 slash 7 slash braceleft seveneighths braceleft keycode 17 = 8 parenleft 8 parenleft bracketleft trademark bracketleft keycode 18 = 9 parenright 9 parenright bracketright plusminus bracketright keycode 19 = 0 equal 0 equal braceright degree braceright keycode 20 = ssharp question ssharp question backslash questiondown U1E9E keycode 21 = dead_acute dead_grave dead_acute dead_grave dead_cedilla dead_ogonek dead_cedilla keycode 22 = BackSpace NoSymbol BackSpace keycode 23 = Tab ISO_Left_Tab Tab ISO_Left_Tab keycode 24 = q Q q Q at Greek_OMEGA at keycode 25 = w W w W lstroke Lstroke lstroke keycode 26 = e E e E EuroSign EuroSign EuroSign keycode 27 = r R r R paragraph registered paragraph keycode 28 = t T t T tslash Tslash tslash keycode 29 = z Z z Z leftarrow yen leftarrow keycode 30 = u U u U downarrow uparrow downarrow keycode 31 = i I i I rightarrow idotless rightarrow keycode 32 = o O o O oslash Oslash oslash keycode 33 = p P p P thorn THORN thorn keycode 34 = udiaeresis Udiaeresis udiaeresis Udiaeresis dead_diaeresis dead_abovering dead_diaeresis keycode 35 = plus asterisk plus asterisk dead_tilde dead_macron dead_tilde keycode 36 = Return NoSymbol Return keycode 37 = Control_L NoSymbol Control_L keycode 38 = a A a A ae AE ae keycode 39 = s S s S U017F U1E9E U017F keycode 40 = d D d D eth ETH eth keycode 41 = f F f F dstroke ordfeminine dstroke keycode 42 = g G g G eng ENG eng keycode 43 = h H h H hstroke Hstroke hstroke keycode 44 = j J j J dead_belowdot dead_abovedot dead_belowdot keycode 45 = k K k K kra ampersand kra keycode 46 = l L l L lstroke Lstroke lstroke keycode 47 = odiaeresis Odiaeresis odiaeresis Odiaeresis dead_doubleacute
XWin -ignoremousewheelpress
Hi Jon, maybe you are interested in this idea: The wheel of a wheel mouse also working as middle mouse button can be quite annoying, when you accidently paste lots of lines into an xterm while scrolling up and down. I thought an option -ignoremousewheelpress to XWin would be a great enhancement. Scrolling were possible, but clicking the wheel were ignored. (Using it would only make sense together with -emulate3buttons.) Luckily I found another mouse driver which allowed me to diable this directly on Windows, so it's fine for me, but such a mouse driver might not be available for all mice. Regards, Paul -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
xterm: scrollbar bug
Hi, I wanted to ask if it's already known, with which release xterm's scrollbar bug will be resolved. Thanks! Paul -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog cygtls.cc cygtls.h ...
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2011-08-03 11:40:48 Modified files: winsup/cygwin : ChangeLog cygtls.cc cygtls.h exceptions.cc hires.h ntdll.h signal.cc thread.cc thread.h times.cc tlsoffsets.h wait.cc Log message: * cygtls.h (struct _local_storage): Add cw_timer member. * cygtls.cc (_cygtls::init_thread): Initialize locals.cw_timer. (_cygtls::fixup_after_fork): Ditto. * tlsoffsets.h: Regenerate. * ntdll.h (enum _TIMER_INFORMATION_CLASS): Define. (struct _TIMER_BASIC_INFORMATION): Define. (NtQueryTimer): Declare function. * thread.h (cancelable_wait): Change timeout argument to PLARGE_INTEGER and provide NULL default. (fast_mutex::lock): Adjust accordingly. (pthread_cond::wait): Change timeout argument to PLARGE_INTEGER and default to NULL. * thread.cc (cancelable_wait): Change timeout argument to PLARGE_INTEGER. Initialize _cygtls.locals.cw_timer if needed. Use NT waitable timers for handling timeout. Return remaining time to timeout argument if timeout was relative. (pthread_cond::wait): Change timeout argument to PLARGE_INTEGER. Adjust to change in cancelable_wait. (pthread_mutex::lock): Adjust to change in cancelable_wait. (pthread_spinlock::lock): Ditto. (pthread::join): Ditto. (__pthread_cond_dowait): Change waitlength argument to PLARGE_INTEGER. Adjust to changes in cancelable_wait and pthread_cond::wait. (pthread_cond_timedwait): Adjust to change in __pthread_cond_dowait. (pthread_cond_wait): Ditto. (semaphore::_timedwait): Adjust to change in cancelable_wait. (semaphore::_wait): Ditto. * exceptions.cc (handle_sigsuspend): Ditto. * signal.cc (nanosleep): Ditto. * wait.cc (wait4): Ditto. Fix copyright dates. * times.cc (FACTOR, NSPERSEC): Move from here... * hires.h (FACTOR, NSPERSEC): ...to here. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5464r2=1.5465 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.cc.diff?cvsroot=srcr1=1.76r2=1.77 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygtls.h.diff?cvsroot=srcr1=1.72r2=1.73 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/exceptions.cc.diff?cvsroot=srcr1=1.359r2=1.360 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/hires.h.diff?cvsroot=srcr1=1.19r2=1.20 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ntdll.h.diff?cvsroot=srcr1=1.125r2=1.126 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/signal.cc.diff?cvsroot=srcr1=1.98r2=1.99 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.244r2=1.245 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.h.diff?cvsroot=srcr1=1.122r2=1.123 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/times.cc.diff?cvsroot=srcr1=1.110r2=1.111 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/tlsoffsets.h.diff?cvsroot=srcr1=1.47r2=1.48 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/wait.cc.diff?cvsroot=srcr1=1.37r2=1.38
winsup/cygwin ChangeLog dll_init.cc sigproc.cc ...
CVSROOT:/cvs/uberbaum Module name:winsup Changes by: c...@sourceware.org 2011-08-03 17:59:00 Modified files: cygwin : ChangeLog dll_init.cc sigproc.cc cygwin/include/sys: strace.h Log message: * dll_init.cc: Use fabort in favor of api_fatal and fork_info-abort where appropriate throughout. (fabort): Define. (dll_list::topsort): Don't print sorting information. Fix formatting. (dll_list::topsort_visit): Fix formatting. (dll_list::load_after_fork_impl): Perform comment fixups. * sigproc.cc (child_info_fork::abort): (for now?) Always print cause of fork failure. * include/sys/strace.h (strace_vprintf): Remove _STRACE_NOTALL when printing. We really do want to see this. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/ChangeLog.diff?cvsroot=uberbaumr1=1.5465r2=1.5466 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/dll_init.cc.diff?cvsroot=uberbaumr1=1.94r2=1.95 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/sigproc.cc.diff?cvsroot=uberbaumr1=1.340r2=1.341 http://sourceware.org/cgi-bin/cvsweb.cgi/winsup/cygwin/include/sys/strace.h.diff?cvsroot=uberbaumr1=1.27r2=1.28
src/winsup/cygwin ChangeLog cygwin.din posix.s ...
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2011-08-03 14:17:02 Modified files: winsup/cygwin : ChangeLog cygwin.din posix.sgml signal.cc thread.cc winsup/cygwin/include/cygwin: version.h Log message: * cygwin.din (clock_nanosleep): Export. * posix.sgml (std-notimpl): Move clock_nanosleep from here... (std-susv4): ... to here. (std-notes): Note limitations of clock_nanosleep. * signal.cc (clock_nanosleep): Renamed from nanosleep, adding clock_id and flags arguments and changing return values throughout. Improve checks for illegal rqtp values. Add support for CLOCK_MONOTONIC and TIMER_ABSTIME. (nanosleep): Rewrite in terms of clock_nanosleep. (sleep): Ditto. (usleep): Ditto. * thread.cc: Mark clock_nanosleep in list of cancellation points. * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.5466r2=1.5467 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.din.diff?cvsroot=srcr1=1.245r2=1.246 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/posix.sgml.diff?cvsroot=srcr1=1.69r2=1.70 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/signal.cc.diff?cvsroot=srcr1=1.99r2=1.100 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/thread.cc.diff?cvsroot=srcr1=1.245r2=1.246 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/cygwin/version.h.diff?cvsroot=srcr1=1.350r2=1.351
src/winsup/doc ChangeLog new-features.sgml
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2011-08-03 14:18:07 Modified files: winsup/doc : ChangeLog new-features.sgml Log message: * new-features.sgml (ov-new1.7.10): Document new POSIX Clock Selection option APIs. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.357r2=1.358 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.87r2=1.88
Re: [PATCH] clock_nanosleep(2)
On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote:
Does that mean the return value from NtQueryTimer is unreliable?
In what way is it wrong?
I'm not sure. When I run an STC (attached), it works as expected. In
cancelable_wait(), however, it returns the negative system uptime. Is
Cygwin doing something to make this occur?
Does nanosleep wait too long or not long enough?
That doesn't seem to be an issue.
If NtQueryTimer is unusable, maybe we should just skip the idea to return
the remaining time from cancelabel_wait and simply use the return
value from hires_ms::timeGetTime_ns() to return the remaining time
from {clock_}nanosleep
I'd rather avoid this type of workaround, particularly with
clock_nanosleep having to deal with CLOCK_MONOTONIC as well.
and the pthread_spin chunk doesn't look right (previously
the timeout would repeat in the while loop, but that won't happen the
way the waitable timer is set up).
It doesn't look wrong to me, but then again, I didn't test it...
You're right, since we pay no attention to the return value of
cancelable_wait() here.
Yaakov
#pragma CCOD:script no
#pragma CCOD:options -lntdll
#include stdlib.h
#include stdio.h
#include windows.h
#include ddk/ntapi.h
int main(void) {
HANDLE timer;
LARGE_INTEGER li;
PTIMER_BASIC_INFORMATION tbi;
const size_t sizeof_tbi = sizeof (TIMER_BASIC_INFORMATION);
int i;
li.QuadPart = -2000LL;
NtCreateTimer (timer, TIMER_ALL_ACCESS, NULL, NotificationTimer);
for (i = 0; i 10; i++)
{
NtSetTimer (timer, li, NULL, NULL, FALSE, 0, NULL);
WaitForSingleObject (timer, 1000);
tbi = (PTIMER_BASIC_INFORMATION) malloc (sizeof_tbi);
NtQueryTimer (timer, TimerBasicInformation, tbi, sizeof_tbi, NULL);
NtCancelTimer (timer, NULL);
printf (%ld.%09ld\n, (long) (tbi-TimeRemaining.QuadPart / 1000LL),
(long) ((tbi-TimeRemaining.QuadPart % 1000LL) * 100LL));
}
NtClose (timer);
return 0;
}
Re: [PATCH] clock_nanosleep(2)
On Aug 3 01:20, Yaakov (Cygwin/X) wrote: On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote: Does that mean the return value from NtQueryTimer is unreliable? In what way is it wrong? I'm not sure. When I run an STC (attached), it works as expected. In cancelable_wait(), however, it returns the negative system uptime. Is Cygwin doing something to make this occur? That sounds weird. How should Cygwin influence what an independent OS function returns? And you sure it's the system uptime? Wow. I'll have a look into that, but I doubt I see more than you. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] clock_nanosleep(2)
On Wed, 2011-08-03 at 09:45 +0200, Corinna Vinschen wrote: On Aug 3 01:20, Yaakov (Cygwin/X) wrote: On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote: Does that mean the return value from NtQueryTimer is unreliable? In what way is it wrong? I'm not sure. When I run an STC (attached), it works as expected. In cancelable_wait(), however, it returns the negative system uptime. Is Cygwin doing something to make this occur? That sounds weird. How should Cygwin influence what an independent OS function returns? And you sure it's the system uptime? Wow. Never mind, I figured it out. The difference is the timeout to WaitFor*Object*(); my STC doesn't allow the timer to finish, but cancelable_wait() does with the INFINITE timeout. If there is time remaining, as in the STC, then TIMER_BASIC_INFORMATION.TimeRemaining contains just that (as a positive). If the timer has signalled, then instead of zero, it appears to provide when it was signalled (system uptime, as a negative). With that figured out, here's a revised patch. Once this is in, then adding clock_nanosleep() should be relatively easy. Yaakov 2011-08-03 Yaakov Selkowitz yselkowitz@... * cygtls.h (struct _local_storage): Add cw_timer member. * cygtls.cc (_cygtls::init_thread): Initialize locals.cw_timer. (_cygtls::fixup_after_fork): Ditto. * tlsoffsets.h: Regenerate. * ntdll.h (enum _TIMER_INFORMATION_CLASS): Define. (struct _TIMER_BASIC_INFORMATION): Define. (NtQueryTimer): Declare function. * thread.h (cancelable_wait): Change timeout argument to PLARGE_INTEGER and provide NULL default. (fast_mutex::lock): Adjust accordingly. (pthread_cond::wait): Change timeout argument to PLARGE_INTEGER and default to NULL. * thread.cc (cancelable_wait): Change timeout argument to PLARGE_INTEGER. Initialize _cygtls.locals.cw_timer if needed. Use NT waitable timers for handling timeout. Return remaining time to timeout argument if timeout was relative. (pthread_cond::wait): Change timeout argument to PLARGE_INTEGER. Adjust to change in cancelable_wait. (pthread_mutex::lock): Adjust to change in cancelable_wait. (pthread_spinlock::lock): Ditto. (pthread::join): Ditto. (__pthread_cond_dowait): Change waitlength argument to PLARGE_INTEGER. Adjust to changes in cancelable_wait and pthread_cond::wait. (pthread_cond_timedwait): Adjust to change in __pthread_cond_dowait. (pthread_cond_wait): Ditto. (semaphore::_timedwait): Adjust to change in cancelable_wait. (semaphore::_wait): Ditto. * exceptions.cc (handle_sigsuspend): Ditto. * signal.cc (nanosleep): Ditto. * wait.cc (wait4): Ditto. * times.cc (FACTOR, NSPERSEC): Move from here... * hires.h (FACTOR, NSPERSEC): ...to here. Index: cygtls.cc === RCS file: /cvs/src/src/winsup/cygwin/cygtls.cc,v retrieving revision 1.76 diff -u -p -r1.76 cygtls.cc --- cygtls.cc 21 Apr 2011 08:10:28 - 1.76 +++ cygtls.cc 29 Jul 2011 05:56:31 - @@ -98,6 +98,7 @@ _cygtls::init_thread (void *x, DWORD (*f thread_id = GetCurrentThreadId (); initialized = CYGTLS_INITIALIZED; errno_addr = (local_clib._errno); + locals.cw_timer = NULL; if ((void *) func == (void *) cygthread::stub || (void *) func == (void *) cygthread::simplestub) @@ -127,6 +128,7 @@ _cygtls::fixup_after_fork () } stacklock = spinning = 0; locals.select.sockevt = NULL; + locals.cw_timer = NULL; wq.thread_ev = NULL; } Index: cygtls.h === RCS file: /cvs/src/src/winsup/cygwin/cygtls.h,v retrieving revision 1.72 diff -u -p -r1.72 cygtls.h --- cygtls.h 28 May 2011 18:17:08 - 1.72 +++ cygtls.h 29 Jul 2011 05:56:31 - @@ -131,6 +131,9 @@ struct _local_storage int setmode_file; int setmode_mode; + /* thread.cc */ + HANDLE cw_timer; + /* All functions requiring temporary path buffers. */ tls_pathbuf pathbufs; char ttybuf[32]; Index: exceptions.cc === RCS file: /cvs/src/src/winsup/cygwin/exceptions.cc,v retrieving revision 1.359 diff -u -p -r1.359 exceptions.cc --- exceptions.cc 13 Jul 2011 17:53:21 - 1.359 +++ exceptions.cc 29 Jul 2011 05:56:32 - @@ -719,7 +719,7 @@ handle_sigsuspend (sigset_t tempmask) sigproc_printf (oldmask %p, newmask %p, oldmask, tempmask); pthread_testcancel (); - cancelable_wait (signal_arrived, INFINITE); + cancelable_wait (signal_arrived); set_sig_errno (EINTR); // Per POSIX Index: hires.h === RCS file: /cvs/src/src/winsup/cygwin/hires.h,v retrieving revision 1.19 diff -u -p -r1.19 hires.h --- hires.h 17 May 2011 17:08:09 - 1.19 +++ hires.h 29 Jul 2011 05:56:32 - @@ -29,6 +29,11 @@ details. */ and rounding won't exceed HIRES_DELAY_MAX */ #define HIRES_DELAY_MAX UINT_MAX - 1) / 1000) * 1000) + 10) +/* 100ns difference
Re: [PATCH] clock_nanosleep(2)
On Aug 3 04:19, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 09:45 +0200, Corinna Vinschen wrote: On Aug 3 01:20, Yaakov (Cygwin/X) wrote: On Tue, 2011-08-02 at 17:42 +0200, Corinna Vinschen wrote: Does that mean the return value from NtQueryTimer is unreliable? In what way is it wrong? I'm not sure. When I run an STC (attached), it works as expected. In cancelable_wait(), however, it returns the negative system uptime. Is Cygwin doing something to make this occur? That sounds weird. How should Cygwin influence what an independent OS function returns? And you sure it's the system uptime? Wow. Never mind, I figured it out. The difference is the timeout to WaitFor*Object*(); my STC doesn't allow the timer to finish, but cancelable_wait() does with the INFINITE timeout. If there is time remaining, as in the STC, then TIMER_BASIC_INFORMATION.TimeRemaining contains just that (as a positive). If the timer has signalled, then instead of zero, it appears to provide when it was signalled (system uptime, as a negative). This is cool. Does it match the tickcount as returned by hires_ms::timeGetTime_ns()? If so, it sounds like the return value from NtQueryTimer *after* the NtCancelTimer call would be usable and probably more reliable than calling NtQueryTimer first, then NtCancelTimer. What do you think? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [PATCH] clock_nanosleep(2)
On Wed, 2011-08-03 at 11:27 +0200, Corinna Vinschen wrote: On Aug 3 04:19, Yaakov (Cygwin/X) wrote: Never mind, I figured it out. The difference is the timeout to WaitFor*Object*(); my STC doesn't allow the timer to finish, but cancelable_wait() does with the INFINITE timeout. If there is time remaining, as in the STC, then TIMER_BASIC_INFORMATION.TimeRemaining contains just that (as a positive). If the timer has signalled, then instead of zero, it appears to provide when it was signalled (system uptime, as a negative). This is cool. Does it match the tickcount as returned by hires_ms::timeGetTime_ns()? If so, it sounds like the return value from NtQueryTimer *after* the NtCancelTimer call would be usable and probably more reliable than calling NtQueryTimer first, then NtCancelTimer. What do you think? The only thing that uses the remaining time is nanosleep(), which uses a relative timeout. Same thing will go for clock_nanosleep(): per POSIX, rmtp is only returned if TIMER_ABSTIME is not set. If we only care about relative remainders, then calling NtQueryTimer first is the simplest way to go, as in my patch. Yaakov
Re: [PATCH] clock_nanosleep(2)
On Aug 3 04:35, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 11:27 +0200, Corinna Vinschen wrote: On Aug 3 04:19, Yaakov (Cygwin/X) wrote: Never mind, I figured it out. The difference is the timeout to WaitFor*Object*(); my STC doesn't allow the timer to finish, but cancelable_wait() does with the INFINITE timeout. If there is time remaining, as in the STC, then TIMER_BASIC_INFORMATION.TimeRemaining contains just that (as a positive). If the timer has signalled, then instead of zero, it appears to provide when it was signalled (system uptime, as a negative). This is cool. Does it match the tickcount as returned by hires_ms::timeGetTime_ns()? If so, it sounds like the return value from NtQueryTimer *after* the NtCancelTimer call would be usable and probably more reliable than calling NtQueryTimer first, then NtCancelTimer. What do you think? The only thing that uses the remaining time is nanosleep(), which uses a relative timeout. Same thing will go for clock_nanosleep(): per POSIX, rmtp is only returned if TIMER_ABSTIME is not set. If we only care about relative remainders, then calling NtQueryTimer first is the simplest way to go, as in my patch. Yes, I know. I was just wondering about the reliability factor of the value returned by NtQueryTimer. Using the absolute value after the call to NtCancelTimer and subtracting the start time may be more reliable. But, never mind. Your patch looks good to me. Please apply. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[PATCH] clock_nanosleep(2), round two
Here's my second attempt at clock_nanosleep(2). After what we dealt
with in round one, this should be a piece of cake.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html
http://www.kernel.org/doc/man-pages/online/pages/man2/clock_nanosleep.2.html
Patches for winsup/cygwin and winsup/doc, plus a test program, attached.
Yaakov
2011-08-03 Yaakov Selkowitz yselkowitz@...
* cygwin.din (clock_nanosleep): Export.
* posix.sgml (std-notimpl): Move clock_nanosleep from here...
(std-susv4): ... to here.
(std-notes): Note limitations of clock_nanosleep.
* signal.cc (clock_nanosleep): Renamed from nanosleep, adding clock_id
and flags arguments and changing return values throughout.
Improve checks for illegal rqtp values. Add support for
CLOCK_MONOTONIC and TIMER_ABSTIME.
(nanosleep): Rewrite in terms of clock_nanosleep.
(sleep): Ditto.
(usleep): Ditto.
* thread.cc: Mark clock_nanosleep in list of cancellation points.
* include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump.
Index: cygwin.din
===
RCS file: /cvs/src/src/winsup/cygwin/cygwin.din,v
retrieving revision 1.245
diff -u -p -r1.245 cygwin.din
--- cygwin.din 21 Jul 2011 09:39:21 - 1.245
+++ cygwin.din 3 Aug 2011 17:56:20 -
@@ -223,6 +223,7 @@ _clock = clock SIGFE
clock_getcpuclockid SIGFE
clock_getres SIGFE
clock_gettime SIGFE
+clock_nanosleep SIGFE
clock_setres SIGFE
clock_settime SIGFE
clog NOSIGFE
Index: posix.sgml
===
RCS file: /cvs/src/src/winsup/cygwin/posix.sgml,v
retrieving revision 1.69
diff -u -p -r1.69 posix.sgml
--- posix.sgml 21 Jul 2011 09:39:21 - 1.69
+++ posix.sgml 3 Aug 2011 17:56:20 -
@@ -92,6 +92,7 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008)
clock_getcpuclockid
clock_getres
clock_gettime
+clock_nanosleep (see chapter Implementation Notes)
clock_settime (see chapter Implementation Notes)
clog
clogf
@@ -1299,7 +1300,6 @@ also IEEE Std 1003.1-2008 (POSIX.1-2008)
ceill
cexpl
cimagl
-clock_nanosleep
clogl
conjl
copysignl
@@ -1446,8 +1446,10 @@ by keeping track of the current root and
related function calls. A real chroot functionality is not supported by
Windows however./para
-parafunctionclock_setres/function, functionclock_settime/function,
-and functiontimer_create/function only support CLOCK_REALTIME./para
+parafunctionclock_nanosleep/function currently supports only
+CLOCK_REALTIME and CLOCK_MONOTONIC. functionclock_setres/function,
+functionclock_settime/function, and functiontimer_create/function
+currently support only CLOCK_REALTIME./para
paraBSD file locks created via functionflock/function are not
propagated to the parent process and sibling processes. The locks are
Index: signal.cc
===
RCS file: /cvs/src/src/winsup/cygwin/signal.cc,v
retrieving revision 1.99
diff -u -p -r1.99 signal.cc
--- signal.cc 3 Aug 2011 16:40:47 - 1.99
+++ signal.cc 3 Aug 2011 17:56:20 -
@@ -81,52 +81,104 @@ signal (int sig, _sig_func_ptr func)
}
extern C int
-nanosleep (const struct timespec *rqtp, struct timespec *rmtp)
+clock_nanosleep (clockid_t clk_id, int flags, const struct timespec *rqtp,
+ struct timespec *rmtp)
{
+ const bool abstime = (flags TIMER_ABSTIME) ? true : false;
int res = 0;
sig_dispatch_pending ();
pthread_testcancel ();
- if ((unsigned int) rqtp-tv_nsec 9)
+ if (rqtp-tv_sec 0 || rqtp-tv_nsec 0 || rqtp-tv_nsec 9L)
+return EINVAL;
+
+ /* Explicitly disallowed by POSIX. Needs to be checked first to avoid
+ being caught by the following test. */
+ if (clk_id == CLOCK_THREAD_CPUTIME_ID)
+return EINVAL;
+
+ /* support for CPU-time clocks is optional */
+ if (CLOCKID_IS_PROCESS (clk_id) || CLOCKID_IS_THREAD (clk_id))
+return ENOTSUP;
+
+ switch (clk_id)
{
- set_errno (EINVAL);
- return -1;
+case CLOCK_REALTIME:
+case CLOCK_MONOTONIC:
+ break;
+default:
+ /* unknown or illegal clock ID */
+ return EINVAL;
}
+
LARGE_INTEGER timeout;
timeout.QuadPart = (LONGLONG) rqtp-tv_sec * NSPERSEC
+ ((LONGLONG) rqtp-tv_nsec + 99LL) / 100LL;
- timeout.QuadPart *= -1LL;
- syscall_printf (nanosleep (%ld.%09ld), rqtp-tv_sec, rqtp-tv_nsec);
+ if (abstime)
+{
+ struct timespec tp;
+
+ clock_gettime (clk_id, tp);
+ /* Check for immediate timeout */
+ if (tp.tv_sec rqtp-tv_sec
+ || (tp.tv_sec == rqtp-tv_sec tp.tv_nsec rqtp-tv_nsec))
+ return 0;
+
+ if (clk_id == CLOCK_REALTIME)
+ timeout.QuadPart += FACTOR;
+ else
+ {
+ /* other clocks need to be handled with a relative timeout */
+ timeout.QuadPart -= tp.tv_sec * NSPERSEC + tp.tv_nsec / 100LL;
+ timeout.QuadPart *= -1LL;
+ }
+}
+ else /* !abstime */
+timeout.QuadPart *= -1LL;
+
+
Re: [PATCH] clock_nanosleep(2), round two
On Aug 3 13:42, Yaakov (Cygwin/X) wrote: * cygwin.din (clock_nanosleep): Export. * posix.sgml (std-notimpl): Move clock_nanosleep from here... (std-susv4): ... to here. (std-notes): Note limitations of clock_nanosleep. * signal.cc (clock_nanosleep): Renamed from nanosleep, adding clock_id and flags arguments and changing return values throughout. Improve checks for illegal rqtp values. Add support for CLOCK_MONOTONIC and TIMER_ABSTIME. (nanosleep): Rewrite in terms of clock_nanosleep. (sleep): Ditto. (usleep): Ditto. * thread.cc: Mark clock_nanosleep in list of cancellation points. * include/cygwin/version.h (CYGWIN_VERSION_API_MINOR): Bump. Thumbs up. Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
[PATCH] Add /proc/devices
This patchset implements /proc/devices[1]: $ cat /proc/devices Character devices: 1 mem 5 /dev/tty 5 /dev/console 5 /dev/ptmx 9 st 13 misc 14 sound 117 ttyS 136 tty Block devices: 2 fd 8 sd 11 sr 65 sd 66 sd 67 sd 68 sd 69 sd 70 sd 71 sd The question is how to handle /dev/tty and /dev/console as the apparently vary now, per cgf's remarks on the main list. Patches for winsup/cygwin and winsup/doc attached. Yaakov [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-proc-devices.html cygwin-proc-devices.patch Description: Binary data doc-proc-devices.patch Description: Binary data
Problems with 20110801 snapshot
I am having the following issues with the 20110801 snapshot: * Previously I had my DLLs rebased from 0x8000 up, but now, all fork() calls failed until I rebased from 0x down. * Opening multiple VTE-based terminals (gnome-terminal, Xfce Terminal, etc.), or even one after a mintty terminal is already open, produces the following message when starting a bash login shell: -bash: cannot set terminal process group (-1): Inappropriate ioctl for device -bash: no job control in this shell In which case, launching a ncurses app (e.g. less or nano) displays on the first terminal which didn't have such a warning. And when closing such a terminal, a warning about a process still running in that terminal appears even though there is none. Yaakov -- 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: Show GNU screen captions inside of mintty
On Wed, Aug 03, 2011 at 06:45:31AM +0100, Andy Koppe wrote: This has nothing to do with mintty and everything to do with screen and its configuration, unless you can show that mintty displays I didn't think it necessarily had anything to do with mintty as an application, but the TERMCAP settings it's using. Your comment did remind me that screen still reads the /etc/screenrc file even if you have a user specified configuration, so I diffed the /etc/screenrc from my Debian desktop and the Cygwin /etc/screenrc and found they were different. After replacing Cygwin's screenrc with the one from Debian, it behaved as expected. Thanks for the help, Eric -- 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: Problems with 20110801 snapshot
On Aug 3 01:01, Yaakov (Cygwin/X) wrote: I am having the following issues with the 20110801 snapshot: * Previously I had my DLLs rebased from 0x8000 up, but now, all fork() calls failed until I rebased from 0x down. Yes, that was to be expected. Sorry about that. However, since DLLs will stay in the range below 0x8000 by default anyway, I was mulling over a way to utilize the large address area. And then it occured to me that it's the ideal playfield for the heap. See http://cygwin.com/ml/cygwin-cvs/2011-q3/msg00032.html http://cygwin.com/ml/cygwin-cvs/2011-q3/msg00033.html * Opening multiple VTE-based terminals (gnome-terminal, Xfce Terminal, etc.), or even one after a mintty terminal is already open, produces the following message when starting a bash login shell: -bash: cannot set terminal process group (-1): Inappropriate ioctl for device -bash: no job control in this shell In which case, launching a ncurses app (e.g. less or nano) displays on the first terminal which didn't have such a warning. And when closing such a terminal, a warning about a process still running in that terminal appears even though there is none. Is that a new one in 20110801? The change set doesn't look like it could introduce this. Can you please look which snapshot introduced this issue? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: bzr completely broken?
On Aug 2 15:25, Andrew Schulman wrote: On Aug 2 10:07, Andrew Schulman wrote: $ rebaseall ReBaseImage (/usr/bin/cygcrypt-0.dll) failed with last error = 6 [...] chmod u+w /usr/bin/cygcrypt-0.dll ? Uh... yes. Thanks. It works now. Although I had to get more aggressive and run find /usr -iname \*.dll -o -iname \*.so | xargs chmod u+w After that, rebaseall completed successfully, and bzr now works again. Who maintains the rebase package? I wonder if it should automatically try to chmod u+w all of the files it wants to operate on-- maybe just temporarily. Jason is the maintainer, with a bit of Chuck's and my help. I don't think that chmod +w is a good idea in general. I don't like to see tools fiddeling with permissions without asking. We're working on a new release of rebase anyway. This new release checks for writability and prints just a warning without stopping dead in its track: /usr/bin/foo.dll: skipped because not writable That should be ok, shouldn't it? Otherwise, what we can do is to open the file with FILE_FLAG_BACKUP_SEMANTICS. This would allow you to rebase DLLs without write permissions if you have admin privileges. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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
python doesn't allow descriptors 63 in select
Hi Jason, it looks like there's a build glitch in python: $ cat sel.py EOF from socket import * from select import select ins = [] for i in range(1024): s = socket(AF_INET, SOCK_STREAM) ins.append(s) print socket opened with fd, s.fileno() select(ins, [], [], 0) EOF $ python sel.py socket opened with fd 3 socket opened with fd 4 socket opened with fd 5 [...] socket opened with fd 62 socket opened with fd 63 socket opened with fd 64 socket opened with fd 64 Traceback (most recent call last): File test.py, line 10, in module select(ins, [], [], 0) ValueError: filedescriptor out of range in select() I debugged this and it turns out that python does not call Cygwin's select function anymore, as soon as there's a file descriptor in the set which is = 64. While the default value for FD_SETSIZE is 64 (see /usr/include/sys/types.h): # ifndef FD_SETSIZE # define FD_SETSIZE 64 AFAICS the python default for the fd set is 256, see the definition in /usr/include/python2.6/pyport.h: #ifndef FD_SETSIZE #define FD_SETSIZE 256 But somehow this didn't make it into the python build. On my Linux box, the same script only stops when it hits the soft descriptor limit, 1024 in my case. Can you have a look and, perhaps, provide a new python with a bigger internal FD_SETSIZE? The 256 from /usr/include/python2.6/pyport.h would already be ok, I guess, but 512 or so wouldn't hurt either... Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Problems with 20110801 snapshot
On Wed, 2011-08-03 at 09:06 +0200, Corinna Vinschen wrote: * Opening multiple VTE-based terminals (gnome-terminal, Xfce Terminal, etc.), or even one after a mintty terminal is already open, produces the following message when starting a bash login shell: -bash: cannot set terminal process group (-1): Inappropriate ioctl for device -bash: no job control in this shell In which case, launching a ncurses app (e.g. less or nano) displays on the first terminal which didn't have such a warning. And when closing such a terminal, a warning about a process still running in that terminal appears even though there is none. Is that a new one in 20110801? The change set doesn't look like it could introduce this. Can you please look which snapshot introduced this issue? I'm sure it's not, it probably dates back to the pty/tty handling changes. I won't be able to bisect this until tomorrow. Yaakov -- 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: Commands slow in wait_sig.
On 8/3/2011 9:44 AM, texas salsa wrote: Hello there, I use Cygwin to do some complex text processing jobs using shell scripts on Thinkpad X200s Windows XP sp3. It had worked fine before but at some point I noticed the job started to take much time to complete. It is taking about ten times period compare to before. I don't know what had triggered this exactly. $ while true ;do /usr/bin/date ;done|uniq -c 1 Wed Aug 3 16:21:05 2011 1 Wed Aug 3 16:21:06 2011 1 Wed Aug 3 16:21:08 2011 1 Wed Aug 3 16:21:09 2011 1 Wed Aug 3 16:21:10 2011 2 Wed Aug 3 16:21:11 2011 1 Wed Aug 3 16:21:12 2011 $ time date Wed Aug 3 16:23:19 2011 real0m0.905s user0m0.077s sys 0m0.562s $ uname -a CYGWIN_NT-5.1 IBM-8DE0336DAA4 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin So one command take about 1 sec to complete. On other machines with similar configuration the above testing shows about 10 forks/sec on average. similar machine T410 with XP SP3 using latest snapshots $ while true ;do /usr/bin/date ;done|uniq -c 51 Wed Aug 3 10:23:36 WEDT 2011 50 Wed Aug 3 10:23:37 WEDT 2011 50 Wed Aug 3 10:23:38 WEDT 2011 51 Wed Aug 3 10:23:39 WEDT 2011 51 Wed Aug 3 10:23:40 WEDT 2011 $ time date Wed Aug 3 10:29:58 WEDT 2011 real0m0.016s user0m0.030s sys 0m0.000s Yuta possible cause: bash-completion installed or BLODA (mainly antivirus) Regards Marco -- 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: git-svn hang starting with 20110721 snapshot.
On Aug 2 10:58, David Rothenberger wrote: I use git-svn extensively in my day-to-day work, and I noticed with recent snapshots that some of the git-svn commands are hanging. I narrowed it down to the 20110721 snapshot. 20110713 is the last one that works fine. I realize this isn't exactly a STC, but I don't have the time right now to narrow it down further (or the skills, really). I've attached a script which reproduces the problem. It requires svn and git-svn. In the script, the first git svn init command hangs with 20110721, but the entire script succeeds with 20110713. I hope this is enough information to track down the problem, because I was absolutely LOVING the speed increase in 20110801. This is not enough for me. I tried your script on W7 32 bit and Server 2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot, in in no case can I reproduce a hang. The script runs fine (and fast): $ ./reproduce.sh Created /tmp/git-svn-problem.2528 Creating an SVN repository and workspace. Checked out revision 0. A tags A trunk A branches A trunk/file1 Adding branches Adding tags Adding trunk Adding trunk/file1 Transmitting file data . Committed revision 1. Initializing with git svn. This hangs with recent snapshots. Initialized empty Git repository in /tmp/git-svn-problem.2528/work/trunk/.git/ A file1 r1 = 3a690f391f65e05607235e13e2baf15af222ea6a (refs/remotes/trunk) Checked out HEAD: file:///tmp/git-svn-problem.2528/repos/trunk r1 Making a change in svn, then doing git svn rebase --all. git svn rebase --all also hangs. Sendingtrunk/file1 Transmitting file data . Committed revision 2. HEAD is now at 3a690f3 Initial version M file1 r2 = 688e627bde2e5b2cdf7526edb9b34a21e2f816a2 (refs/remotes/trunk) First, rewinding head to replay your work on top of it... Fast-forwarded master to refs/remotes/trunk. I see only one change in the 20110721 snapshot which *might* account for this problem and that is the FIONREAD stuff, but actually even that is unlikely since it just changes the error code returned from the ioctl call (ENOTTY instead of EINVAL). Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: bzr completely broken?
Corinna Vinschen writes: . . . We're working on a new release of rebase anyway. This new release checks for writability and prints just a warning without stopping dead in its track: /usr/bin/foo.dll: skipped because not writable Otherwise, what we can do is to open the file with FILE_FLAG_BACKUP_SEMANTICS. This would allow you to rebase DLLs without write permissions if you have admin privileges. A combination of the two would be best, I think. That is, try FILE_FLAG_BACKUP_SEMANTICS, so for Admins it will work, and if _that_ fails print the message. Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 651-1426, e-mail: h...@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- 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: python doesn't allow descriptors 63 in select
2011/8/3 Corinna Vinschen: $ python sel.py socket opened with fd 3 socket opened with fd 4 socket opened with fd 5 [...] socket opened with fd 62 socket opened with fd 63 socket opened with fd 64 socket opened with fd 64 Traceback (most recent call last): File test.py, line 10, in module select(ins, [], [], 0) ValueError: filedescriptor out of range in select() I debugged this and it turns out that python does not call Cygwin's select function anymore, as soon as there's a file descriptor in the set which is = 64. I have a similar limitation in postgresql, and I heard that this is based on a windows limitation, not any predefined constant. In postgresql I can max fork 63 worker childs, tested by a configure probe. -- Reini -- 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: gdb-7.3.50-1
On 2 August 2011 03:44, Yaakov (Cygwin/X) wrote: On Sun, 2011-07-31 at 13:59 -0400, Christopher Faylor wrote: As usual, I forgot an item of news that I wanted to impart a second after hitting 'y'. For those who follow this type of thing, gdb now has a python scripting interface. That is not turned on in this Cygwin release, primarily because the release was so overdue that I didn't want to waste time figuring out what I needed to pull into my cross-build environment. If I may, based on looking at configure, you'll need libpython2.6.dll.a in $sysroot/usr/lib and the Python headers in $sysroot/usr/include/python2.6, and add -I$sysroot/usr/include/python2.6 to CPPFLAGS. (I wouldn't advise moving them straight into $sysroot/usr/include/, their names are too generic.) Passing '--with-python=/usr/bin/python' as opposed to messing with CPPFLAGS, etc. might be easier. I just recently built if for MinGW and specifying the python interpreter in '--with-python' caused gdb's configure to DTRT (in terms of locating the header files, appropriate libraries, etc.). Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: bzr completely broken?
On Aug 3 10:48, Henry S. Thompson wrote: Corinna Vinschen writes: . . . We're working on a new release of rebase anyway. This new release checks for writability and prints just a warning without stopping dead in its track: /usr/bin/foo.dll: skipped because not writable Otherwise, what we can do is to open the file with FILE_FLAG_BACKUP_SEMANTICS. This would allow you to rebase DLLs without write permissions if you have admin privileges. A combination of the two would be best, I think. That is, try FILE_FLAG_BACKUP_SEMANTICS, so for Admins it will work, and if _that_ fails print the message. I agree. I checked that in. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: python doesn't allow descriptors 63 in select
On Aug 3 12:04, Reini Urban wrote: 2011/8/3 Corinna Vinschen: $ python sel.py socket opened with fd 3 socket opened with fd 4 socket opened with fd 5 [...] socket opened with fd 62 socket opened with fd 63 socket opened with fd 64 socket opened with fd 64 Traceback (most recent call last): File test.py, line 10, in module select(ins, [], [], 0) ValueError: filedescriptor out of range in select() I debugged this and it turns out that python does not call Cygwin's select function anymore, as soon as there's a file descriptor in the set which is = 64. I have a similar limitation in postgresql, and I heard that this is based on a windows limitation, not any predefined constant. In postgresql I can max fork 63 worker childs, tested by a configure probe. I don't know why that is, since Cygwin allows 256 children per process. Either way, that's not related to select. Cygwin's select is using a single WaitForMultipleObjects (WFMO) call at the core. This WFMO call is restricted to 63 wait objects. But many object types are handled by a common thread, and only this thread is given to WFMO. So, for instance, all sockets given to select together take only one waitable object in the WFMO call. So far this works for sockets, pipes, fifos, ptys and /dev/log. All other objects take one WFMO slot per descriptor. However, if you restrict your application to 64 objects, you will never be able to use more, even if Cygwin's select supports that already or will support it at one point, depending on the descriptor type. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: python doesn't allow descriptors 63 in select
On 03/08/2011 08:49, Corinna Vinschen wrote: Hi Jason, it looks like there's a build glitch in python: $ cat sel.pyEOF from socket import * from select import select ins = [] for i in range(1024): s = socket(AF_INET, SOCK_STREAM) ins.append(s) print socket opened with fd, s.fileno() select(ins, [], [], 0) EOF $ python sel.py socket opened with fd 3 socket opened with fd 4 socket opened with fd 5 [...] socket opened with fd 62 socket opened with fd 63 socket opened with fd 64 socket opened with fd 64 Traceback (most recent call last): File test.py, line 10, inmodule select(ins, [], [], 0) ValueError: filedescriptor out of range in select() I debugged this and it turns out that python does not call Cygwin's select function anymore, as soon as there's a file descriptor in the set which is= 64. While the default value for FD_SETSIZE is 64 (see /usr/include/sys/types.h): # ifndef FD_SETSIZE # define FD_SETSIZE 64 AFAICS the python default for the fd set is 256, see the definition in /usr/include/python2.6/pyport.h: #ifndef FD_SETSIZE #define FD_SETSIZE 256 But somehow this didn't make it into the python build. On my Linux box, the same script only stops when it hits the soft descriptor limit, 1024 in my case. Can you have a look and, perhaps, provide a new python with a bigger internal FD_SETSIZE? The 256 from /usr/include/python2.6/pyport.h would already be ok, I guess, but 512 or so wouldn't hurt either... fwiw, I already reported this problem with a patch to fix it at [1]. [1] http://cygwin.com/ml/cygwin/2011-03/msg00651.html -- 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: python doesn't allow descriptors 63 in select
On Aug 3 12:29, Jon TURNEY wrote: On 03/08/2011 08:49, Corinna Vinschen wrote: Hi Jason, it looks like there's a build glitch in python: $ cat sel.pyEOF from socket import * from select import select ins = [] for i in range(1024): s = socket(AF_INET, SOCK_STREAM) ins.append(s) print socket opened with fd, s.fileno() select(ins, [], [], 0) EOF $ python sel.py socket opened with fd 3 socket opened with fd 4 socket opened with fd 5 [...] socket opened with fd 62 socket opened with fd 63 socket opened with fd 64 socket opened with fd 64 Traceback (most recent call last): File test.py, line 10, inmodule select(ins, [], [], 0) ValueError: filedescriptor out of range in select() I debugged this and it turns out that python does not call Cygwin's select function anymore, as soon as there's a file descriptor in the set which is= 64. While the default value for FD_SETSIZE is 64 (see /usr/include/sys/types.h): # ifndef FD_SETSIZE # define FD_SETSIZE 64 AFAICS the python default for the fd set is 256, see the definition in /usr/include/python2.6/pyport.h: #ifndef FD_SETSIZE #define FD_SETSIZE 256 But somehow this didn't make it into the python build. On my Linux box, the same script only stops when it hits the soft descriptor limit, 1024 in my case. Can you have a look and, perhaps, provide a new python with a bigger internal FD_SETSIZE? The 256 from /usr/include/python2.6/pyport.h would already be ok, I guess, but 512 or so wouldn't hurt either... fwiw, I already reported this problem with a patch to fix it at [1]. [1] http://cygwin.com/ml/cygwin/2011-03/msg00651.html Indeed. Huh, even the testcase is the same. Apparently Jason also forgot about it. Jason? Ping? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Commands slow in wait_sig.
On Wed, Aug 03, 2011 at 04:44:29PM +0900, texas salsa wrote: Hello there, I use Cygwin to do some complex text processing jobs using shell scripts on Thinkpad X200s Windows XP sp3. It had worked fine before but at some point I noticed the job started to take much time to complete. It is taking about ten times period compare to before. I don't know what had triggered this exactly. $ while true ;do /usr/bin/date ;done|uniq -c ? 1 Wed Aug? 3 16:21:05 2011 ? 1 Wed Aug? 3 16:21:06 2011 ? 1 Wed Aug? 3 16:21:08 2011 ? 1 Wed Aug? 3 16:21:09 2011 ? 1 Wed Aug? 3 16:21:10 2011 ? 2 Wed Aug? 3 16:21:11 2011 ? 1 Wed Aug? 3 16:21:12 2011 $ time date Wed Aug? 3 16:23:19 2011 real??? 0m0.905s user??? 0m0.077s sys 0m0.562s $ uname -a CYGWIN_NT-5.1 IBM-8DE0336DAA4 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin ? So one command take about 1 sec to complete. On other machines with similar configuration the above testing shows about 10 forks/sec on average. The following is strace date information ?7070??? 9351 [main] date 1780 _cygtls::remove: wait 0x ?? 76??? 9427 [main] date 1780 _cygtls::remove: removed 0x22CE64 element 0 ?? 64??? 9491 [main] date 1780 _cygtls::remove: wait 0x ?? 34??? 9525 [main] date 1780 _cygtls::remove: removed 0x22CE64 element 0 ? 218??? 9743 [sig] date 1780 wait_sig: entering ReadFile loop, my_readsig 0x764, my_sendsig 0x760 332702? 342445 [main] date 1780 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\admuser, no-keep-rel, no-add-slash) ?? 80? 342525 [main] date 1780 normalize_win32_path: C:\cygwin\home\admuser = normalize_win32_path (C:\cygwin\home\admuser) ? 165? 342690 [main] date 1780 mount_info::conv_to_posix_path: /home/admuser = conv_to_posix_path (C:\cygwin\home\admuser) ?2047? 344737 [main] date 1780 _cygwin_istext_for_stdio: fd 0: not open ? It looks like that wait_sig: entering ReadFile loop taking much time in the command processing. So firstly I supposed Slow performance Win7/64 discussion last month may apply to this. I tested 2011-08-01 snapshot and it doubled the performance like 2 forks/sec, but wait_sig still taking much time and I suspect there is another problem in the code or specific problem in my PC. Nothing in the above indicates that there is a problem in wait_sig. The delta times in an strace do not mean This is how long an operation took. They just indicate the number of microseconds since the last update to strace output. What the above says is: 1) wait_sig is about to call ReadFile. It has been 9743 microseconds since strace last reported anytinng. 2) There was a lag of 342445 microseconds before something happened in main. That could be symptomatic of the problem which the 8/01 snapshot works around. Or not. If it is only happening on one system that obviously points to BLODA. cgf -- 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: python doesn't allow descriptors 63 in select
On Wed, Aug 03, 2011 at 01:52:21PM +0200, Corinna Vinschen wrote: On Aug 3 12:29, Jon TURNEY wrote: On 03/08/2011 08:49, Corinna Vinschen wrote: [snip] Can you have a look and, perhaps, provide a new python with a bigger internal FD_SETSIZE? The 256 from /usr/include/python2.6/pyport.h would already be ok, I guess, but 512 or so wouldn't hurt either... fwiw, I already reported this problem with a patch to fix it at [1]. [1] http://cygwin.com/ml/cygwin/2011-03/msg00651.html Indeed. Huh, even the testcase is the same. Apparently Jason also forgot about it. Jason? Ping? The thread is a little more involved which is why I thought it was the WFMO limitation. See the following for the details, if interested: http://cygwin.com/ml/cygwin/2011-03/threads.html#00651 Anyway, I will add this patch to the next Cygwin Python build. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- 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: git-svn hang starting with 20110721 snapshot.
On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote: On Aug 2 10:58, David Rothenberger wrote: I use git-svn extensively in my day-to-day work, and I noticed with recent snapshots that some of the git-svn commands are hanging. I narrowed it down to the 20110721 snapshot. 20110713 is the last one that works fine. I realize this isn't exactly a STC, but I don't have the time right now to narrow it down further (or the skills, really). I've attached a script which reproduces the problem. It requires svn and git-svn. In the script, the first git svn init command hangs with 20110721, but the entire script succeeds with 20110713. I hope this is enough information to track down the problem, because I was absolutely LOVING the speed increase in 20110801. This is not enough for me. I tried your script on W7 32 bit and Server 2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot, in in no case can I reproduce a hang. The script runs fine (and fast): I don't see a hang but I do see a: error: cannot fork() for git-svn: Resource temporarily unavailable I'll investigate that. Maybe it's related. cgf -- 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
ISO: recommendations while setting up a new cygwin environment.
I work in an environment where we have been using cygwin 1.5 and cygwin/X (along with xterm, mintty, and putty) on a variety of Windows XP desktops, as well as an older cygwin 1.7, cygwin/X, and a variety of pretty traditional packages on development XP desktops. Now we are considering creating a single distribution to be used across the board, but set up to run on Windows 7. Two specific questions we were wondering about - are there any recommendations from you who have begun using cygwin on Windows 7 about things we should consider during the configuration? Also, we have some java developers who have commented in the past that trying to start, manage, and stop java processes were more difficult in cygwin than using other similar toolsets (which live purely in the windows process model). Are there any HOWTOs or other useful documents for configuring cygwin to allow a developer to live with processing that has to straddle the windows and cygwin environment. Thank you all for your continued useful suggestions. -- Tcl - The glue of a new generation. http://wiki.tcl.tk/ Larry W. Virden http://www.facebook.com/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. -- 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: git-svn hang starting with 20110721 snapshot.
On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote: On Aug 2 10:58, David Rothenberger wrote: I use git-svn extensively in my day-to-day work, and I noticed with recent snapshots that some of the git-svn commands are hanging. I narrowed it down to the 20110721 snapshot. 20110713 is the last one that works fine. I realize this isn't exactly a STC, but I don't have the time right now to narrow it down further (or the skills, really). I've attached a script which reproduces the problem. It requires svn and git-svn. In the script, the first git svn init command hangs with 20110721, but the entire script succeeds with 20110713. I hope this is enough information to track down the problem, because I was absolutely LOVING the speed increase in 20110801. This is not enough for me. I tried your script on W7 32 bit and Server 2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot, in in no case can I reproduce a hang. The script runs fine (and fast): I don't see a hang but I do see a: error: cannot fork() for git-svn: Resource temporarily unavailable I'll investigate that. Maybe it's related. Huh. I ran rebaseall before reporting the above but, on inspecting the output from strace, I saw that dlls were getting located in non-rebased locations. So, I ran rebaseall again. *Now* I see the hang. Weird. So I guess I can investigate the actual problem now. FWIW, strace reports that the child of a fork has died with a SIGSEGV but I don't see the location of the SIGSEGV in the strace output. So it will be a little tricky to track down. cgf -- 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: git-svn hang starting with 20110721 snapshot.
On Aug 3 10:00, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote: On Aug 2 10:58, David Rothenberger wrote: I use git-svn extensively in my day-to-day work, and I noticed with recent snapshots that some of the git-svn commands are hanging. I narrowed it down to the 20110721 snapshot. 20110713 is the last one that works fine. I realize this isn't exactly a STC, but I don't have the time right now to narrow it down further (or the skills, really). I've attached a script which reproduces the problem. It requires svn and git-svn. In the script, the first git svn init command hangs with 20110721, but the entire script succeeds with 20110713. I hope this is enough information to track down the problem, because I was absolutely LOVING the speed increase in 20110801. This is not enough for me. I tried your script on W7 32 bit and Server 2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot, in in no case can I reproduce a hang. The script runs fine (and fast): I don't see a hang but I do see a: error: cannot fork() for git-svn: Resource temporarily unavailable I'll investigate that. Maybe it's related. Huh. I ran rebaseall before reporting the above but, on inspecting the output from strace, I saw that dlls were getting located in non-rebased locations. So, I ran rebaseall again. *Now* I see the hang. Weird. So I guess I can investigate the actual problem now. FWIW, strace reports that the child of a fork has died with a SIGSEGV but I don't see the location of the SIGSEGV in the strace output. So it will be a little tricky to track down. Is git-svn using perl? I have constant problems using perl after a rebase. The problem starts with perl.exe(!) being rebased(!) to 0x5000(!). However, when rebasing perl.exe to 0x40 where it belongs, it doesn't work either. Only reinstalling perl helped afterwards. Reini, could you please update the perl package so that the executable is in its default place at 0x40? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: python doesn't allow descriptors 63 in select
On Aug 3 09:22, Jason Tishler wrote: On Wed, Aug 03, 2011 at 01:52:21PM +0200, Corinna Vinschen wrote: On Aug 3 12:29, Jon TURNEY wrote: On 03/08/2011 08:49, Corinna Vinschen wrote: [snip] Can you have a look and, perhaps, provide a new python with a bigger internal FD_SETSIZE? The 256 from /usr/include/python2.6/pyport.h would already be ok, I guess, but 512 or so wouldn't hurt either... fwiw, I already reported this problem with a patch to fix it at [1]. [1] http://cygwin.com/ml/cygwin/2011-03/msg00651.html Indeed. Huh, even the testcase is the same. Apparently Jason also forgot about it. Jason? Ping? The thread is a little more involved which is why I thought it was the WFMO limitation. See the following for the details, if interested: http://cygwin.com/ml/cygwin/2011-03/threads.html#00651 Anyway, I will add this patch to the next Cygwin Python build. Thanks. Any chance to get this soon? This is a really problematic limitation. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: git-svn hang starting with 20110721 snapshot.
On Aug 3 16:56, Corinna Vinschen wrote: On Aug 3 10:00, Christopher Faylor wrote: Huh. I ran rebaseall before reporting the above but, on inspecting the output from strace, I saw that dlls were getting located in non-rebased locations. So, I ran rebaseall again. *Now* I see the hang. Weird. So I guess I can investigate the actual problem now. FWIW, strace reports that the child of a fork has died with a SIGSEGV but I don't see the location of the SIGSEGV in the strace output. So it will be a little tricky to track down. Is git-svn using perl? I have constant problems using perl after a rebase. The problem starts with perl.exe(!) being rebased(!) to 0x5000(!). However, when rebasing perl.exe to 0x40 where it Well, not exactly 0x5000, but in that region. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: bzr completely broken?
On Aug 3 10:48, Henry S. Thompson wrote: Corinna Vinschen writes: . . . We're working on a new release of rebase anyway. This new release checks for writability and prints just a warning without stopping dead in its track: /usr/bin/foo.dll: skipped because not writable Otherwise, what we can do is to open the file with FILE_FLAG_BACKUP_SEMANTICS. This would allow you to rebase DLLs without write permissions if you have admin privileges. A combination of the two would be best, I think. That is, try FILE_FLAG_BACKUP_SEMANTICS, so for Admins it will work, and if _that_ fails print the message. I agree. I checked that in. Thanks. I think that works. -- 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: bzr completely broken?
On 6/6/2011 9:01 AM, Andrew Schulman wrote: Am I right that bzr is just completely broken in Cygwin? If so, is there an ETA to get it fixed? My bzr is 2.3.1-1, in Cygwin 1.7.9. No matter what bzr command I run, I always get the same result: As a quick workaround, you can delete all the dll files in /usr/lib/python2.6/site-packages/bzrlib. bzr will complain that it can't find the native modules, but it'll fall back to pure-Python code and work just fine. You can eliminate the warning by putting ignore_missing_extensions=True in ~/.bazaar/bazaar.conf. Interesting - thanks. The problem was solved otherwise, but that's still useful to know. -- 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
perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.)
On Wed, Aug 03, 2011 at 04:56:05PM +0200, Corinna Vinschen wrote: Is git-svn using perl? Yes, very heavily. Setting CYGWIN_DEBUG=perl filled my screen with gdb windows. I have constant problems using perl after a rebase. The problem starts with perl.exe(!) being rebased(!) to 0x5000(!). So, it is. How odd. However, when rebasing perl.exe to 0x40 where it belongs, it doesn't work either. Only reinstalling perl helped afterwards. perl itself seems to still work but rebasing doesn't solve the hang. Reini, could you please update the perl package so that the executable is in its default place at 0x40? Or at least explain why it's sitting up there where it interferes with dlls? cgf -- 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: Portable shell code between Cygwin and Linux
* Eliot Moss (Tue, 02 Aug 2011 11:40:44 -0400) On 8/2/2011 8:24 AM, Sebastien Vauban wrote: Thorsten Kampe wrote: * Sebastien Vauban (Mon, 01 Aug 2011 08:46:52 +0200) My goal is to have just 1 alias that would work both under Win32 (Cygwin) and Ubuntu Why don't have simply put your alias definitions in if [[ $OSTYPE = cygwin ]]; then else? Because I really want one single definition which could work on every system I'm using. [...] The suggestion to use a few conditionals that look at the which OS you're on does not involve continued tweaking. Once you have the right file, it works everywhere (for which you have provided suitable cases) using the exact same file. It's just that different parts get executed on different platforms. It's not as elegant as achieving an arrangement with no conditionals, but it's practical and flexible. Couldn't have said it better. Cygwin is not Linux and you just can't ignore the differences. For example I have different aliases for netstat and ps on Linux and on Windows. They just don't have the same options. Thorsten I second this. I have used that same technique since the late 80s to build scripts that run on multiple platforms including Cygwin, Linux, Solaris, HP-UX and AIX. You can cover up all sorts of differences that way. Its about the only clean way of dealing with platform specific differences. And sadly, you may even have to stick with /bin/sh if you really want to be portable. Andy Hall -- 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: Re: sshd failes allocating /dev/tty[0-9]
On 21:59, Larry Hall (Cygwin) wrote: On 8/2/2011 7:32 AM, Alexey Luchko wrote: Cygwin Configuration Diagnostics atteched. Maybe crank up the debugging flags to maximum? I assume sshd is still stopped from your last run of sshd -d. If that doesn't sound right to you, you may want to investigate why it's not running now. sshd was stopped while that run because it did not login anyway. and still don't. sshd will run even if you're having problems connecting to it. I'm just making sure that you are testing with a running server. If not, then you want to make sure the server is running first. Yes, it's running. Now it is set up as a service with automatic start up. The messages debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/tty2 chown(/dev/tty2, 11135, 10513) failed: Bad file descriptor debug1: do_cleanup debug1: session_pty_cleanup: session 0 release /dev/tty2 were got running sshd -d in console. I was suggesting that you run sshd with all the debug flags (i.e. -d -d -d) to see if you'd get more useful information about your problem. I've run it with -ddd. There is nothing new around the tty allocation. The full output is attached. May be it can give some clue. Thank you :) -- Alex debug2: load_server_config: filename /etc/sshd_config debug2: load_server_config: done config len = 226 debug2: parse_server_config: config /etc/sshd_config len 226 debug3: /etc/sshd_config:13 setting Port 22 debug3: /etc/sshd_config:19 setting Protocol 2 debug3: /etc/sshd_config:35 setting LogLevel DEBUG debug3: /etc/sshd_config:41 setting StrictModes no debug3: /etc/sshd_config:97 setting UsePrivilegeSeparation yes debug3: /etc/sshd_config:112 setting Subsystem sftp /usr/sbin/sftp-server debug1: sshd version OpenSSH_5.8p1 debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug3: Incorrect RSA1 identifier debug1: read PEM private key done: type ECDSA debug1: private host key: #2 type 3 ECDSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-ddd' debug2: fd 3 setting O_NONBLOCK debug3: sock_set_v6only: set socket 3 IPV6_V6ONLY debug1: Bind to port 22 on ::. Server listening on :: port 22. debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 226 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from ::1 port 61981 debug1: Client protocol version 2.0; client software version OpenSSH_5.8 debug1: match: OpenSSH_5.8 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.8 debug2: fd 3 setting O_NONBLOCK debug2: Network child is on pid 1292 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ssh-rsa,ssh-dss
Re: git-svn hang starting with 20110721 snapshot.
On Wed, Aug 03, 2011 at 10:00:13AM -0400, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote: On Aug 2 10:58, David Rothenberger wrote: I use git-svn extensively in my day-to-day work, and I noticed with recent snapshots that some of the git-svn commands are hanging. I narrowed it down to the 20110721 snapshot. 20110713 is the last one that works fine. I realize this isn't exactly a STC, but I don't have the time right now to narrow it down further (or the skills, really). I've attached a script which reproduces the problem. It requires svn and git-svn. In the script, the first git svn init command hangs with 20110721, but the entire script succeeds with 20110713. I hope this is enough information to track down the problem, because I was absolutely LOVING the speed increase in 20110801. This is not enough for me. I tried your script on W7 32 bit and Server 2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot, in in no case can I reproduce a hang. The script runs fine (and fast): I don't see a hang but I do see a: error: cannot fork() for git-svn: Resource temporarily unavailable I'll investigate that. Maybe it's related. Huh. I ran rebaseall before reporting the above but, on inspecting the output from strace, I saw that dlls were getting located in non-rebased locations. So, I ran rebaseall again. *Now* I see the hang. Weird. So I guess I can investigate the actual problem now. FWIW, strace reports that the child of a fork has died with a SIGSEGV but I don't see the location of the SIGSEGV in the strace output. So it will be a little tricky to track down. It actually wasn't a SIGSEGV. It really was a strange rebase error. Unfortunately, the error was silent both to the standard output and, more irritatingly, to strace. I've checked in changes which now expose the error. The problem is during one of git's 1247 runs of perl, a dll gets inexplicably relocated out of its comfort zone. Then when perl forks the address that the dll was relocated to is in use. So: boom. The good news is that the problem went away when I ran peflagsall. Does that help you David? cgf -- 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: git-svn hang starting with 20110721 snapshot.
On 8/3/2011 11:02 AM, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 10:00:13AM -0400, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote: On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote: On Aug 2 10:58, David Rothenberger wrote: I use git-svn extensively in my day-to-day work, and I noticed with recent snapshots that some of the git-svn commands are hanging. I narrowed it down to the 20110721 snapshot. 20110713 is the last one that works fine. I realize this isn't exactly a STC, but I don't have the time right now to narrow it down further (or the skills, really). I've attached a script which reproduces the problem. It requires svn and git-svn. In the script, the first git svn init command hangs with 20110721, but the entire script succeeds with 20110713. I hope this is enough information to track down the problem, because I was absolutely LOVING the speed increase in 20110801. This is not enough for me. I tried your script on W7 32 bit and Server 2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot, in in no case can I reproduce a hang. The script runs fine (and fast): I don't see a hang but I do see a: error: cannot fork() for git-svn: Resource temporarily unavailable I'll investigate that. Maybe it's related. Huh. I ran rebaseall before reporting the above but, on inspecting the output from strace, I saw that dlls were getting located in non-rebased locations. So, I ran rebaseall again. *Now* I see the hang. Weird. So I guess I can investigate the actual problem now. FWIW, strace reports that the child of a fork has died with a SIGSEGV but I don't see the location of the SIGSEGV in the strace output. So it will be a little tricky to track down. It actually wasn't a SIGSEGV. It really was a strange rebase error. Unfortunately, the error was silent both to the standard output and, more irritatingly, to strace. I've checked in changes which now expose the error. The problem is during one of git's 1247 runs of perl, a dll gets inexplicably relocated out of its comfort zone. Then when perl forks the address that the dll was relocated to is in use. So: boom. The good news is that the problem went away when I ran peflagsall. Does that help you David? I failed to mention in my original report that I'm on W7 x64 and was running with bigaddr=1 and all DLLs rebased from 0x8900 down. I just saw Corinna's email from this morning about the heap changes around 20110721, so that probably explains my problem. I ran rebaseall -o 0 and peflagsall and my test case is working fine now. I'm a little worried, though, since git-svn and stgit were unusable for me last month until I rebased everything about 0x800. (The combination of python, perl, and tons of svn DLLs was just too much.) What's the best approach now? Should I expect forking to work better even with everything rebased from 0x700 down now that the heap is above 2gb? Or should I rebase everything from 0x down as Yaakov is doing? Or should I start from somewhere in between? Thanks, David -- David Rothenberger daver...@acm.org yo-yo, n.: Something that is occasionally up but normally down. (see also Computer). -- 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: git-svn hang starting with 20110721 snapshot.
On Aug 3 11:40, David Rothenberger wrote: On 8/3/2011 11:02 AM, Christopher Faylor wrote: It actually wasn't a SIGSEGV. It really was a strange rebase error. Unfortunately, the error was silent both to the standard output and, more irritatingly, to strace. I've checked in changes which now expose the error. The problem is during one of git's 1247 runs of perl, a dll gets inexplicably relocated out of its comfort zone. Then when perl forks the address that the dll was relocated to is in use. So: boom. The good news is that the problem went away when I ran peflagsall. Does that help you David? I failed to mention in my original report that I'm on W7 x64 and was running with bigaddr=1 and all DLLs rebased from 0x8900 down. I just saw Corinna's email from this morning about the heap changes around 20110721, so that probably explains my problem. I ran rebaseall -o 0 and peflagsall and my test case is working fine now. I'm a little worried, though, since git-svn and stgit were unusable for me last month until I rebased everything about 0x800. (The combination of python, perl, and tons of svn DLLs was just too much.) What's the best approach now? Should I expect forking to work better even with everything rebased from 0x700 down now that the heap is above 2gb? Or should I rebase everything from 0x down as Yaakov is doing? Or should I start from somewhere in between? Better drop the large address stuff for now. Since the heap is now in the large addres area(*), and since mmaps will go there, too(*), we have basically a lot more free space in the area up to 0x7fff. I also expect that the new rebase will help a lot. It supports a rebase database which keep track of rebase addresses, rebaseall does not keep 64K free space between DLLs anymore (this isn't necessary for a long time, but rebaseall never catched up), and rebase now supports a -i flag which allows to inspect DLL addresses for collisions. If you're curious, the CVS repository is on cygwin.com: cvs -d :pserver:anon...@cygwin.com:/cvs/cygwin-apps co rebase Corinna (*) On machines supporting large addresses. For instance, XP with the /3GB boot flag, or 64 bit Windows. And the executable needs to have the large-address awareness flag set as well, that's quite important. It's not very helpful that our executables don't have this flag set by default, but there's the peflags tool and future GCCs are supposed to set the large-address awareness flag by default. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: gdb-7.3.50-1
On Wed, 2011-08-03 at 06:33 -0400, Chris Sutcliffe wrote: On 2 August 2011 03:44, Yaakov (Cygwin/X) wrote: If I may, based on looking at configure, you'll need libpython2.6.dll.a in $sysroot/usr/lib and the Python headers in $sysroot/usr/include/python2.6, and add -I$sysroot/usr/include/python2.6 to CPPFLAGS. (I wouldn't advise moving them straight into $sysroot/usr/include/, their names are too generic.) Passing '--with-python=/usr/bin/python' as opposed to messing with CPPFLAGS, etc. might be easier. I just recently built if for MinGW and specifying the python interpreter in '--with-python' caused gdb's configure to DTRT (in terms of locating the header files, appropriate libraries, etc.). cgf is cross-compiling GDB, which rules out using a Python interpreter to get this information, as noted in gdb/configure.ac. Yaakov -- 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: git-svn hang starting with 20110721 snapshot.
On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote: Better drop the large address stuff for now. Since the heap is now in the large addres area(*), and since mmaps will go there, too(*), we have basically a lot more free space in the area up to 0x7fff. At this moment, I've got DLLs from 0xf000 all the way down to 0xa174, and I could easily have more if I installed all of KDE (which I provide in Ports, but I prefer to use GNOME). So where do you suggest I find that kind of open space in the lower half? Yaakov -- 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: ISO: recommendations while setting up a new cygwin environment.
On Wed, 2011-08-03 at 09:58 -0400, Larry W. Virden wrote: Also, we have some java developers who have commented in the past that trying to start, manage, and stop java processes were more difficult in cygwin than using other similar toolsets (which live purely in the windows process model). Are there any HOWTOs or other useful documents for configuring cygwin to allow a developer to live with processing that has to straddle the windows and cygwin environment. Cygwin Ports provides a Java environment based on JamVM and GNU Classpath, which includes Ant, ECJ, OpenJDK langtools (apt, javac, javah, javadoc, javap), Java-GNOME programs, fop, and several dozen libraries. It's not quite a Su^WOracle JRE but its enough for my needs. Yaakov Cygwin Ports -- 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: git-svn hang starting with 20110721 snapshot.
On Aug 3 15:02, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote: Better drop the large address stuff for now. Since the heap is now in the large addres area(*), and since mmaps will go there, too(*), we have basically a lot more free space in the area up to 0x7fff. At this moment, I've got DLLs from 0xf000 all the way down to 0xa174, and I could easily have more if I installed all of KDE (which I provide in Ports, but I prefer to use GNOME). So where do you suggest I find that kind of open space in the lower half? Did you use the current rebaseall? If so you have a 64K hole between each DLL. Other than that I don't have an answer for you. There's only so much you can do within the 32 bit address space. That's only one reason why a 64 bit Cygwin would be a good idea. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: git-svn hang starting with 20110721 snapshot.
On Aug 3 22:19, Corinna Vinschen wrote: On Aug 3 15:02, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote: Better drop the large address stuff for now. Since the heap is now in the large addres area(*), and since mmaps will go there, too(*), we have basically a lot more free space in the area up to 0x7fff. At this moment, I've got DLLs from 0xf000 all the way down to 0xa174, and I could easily have more if I installed all of KDE (which I provide in Ports, but I prefer to use GNOME). So where do you suggest I find that kind of open space in the lower half? Did you use the current rebaseall? If so you have a 64K hole between each DLL. Other than that I don't have an answer for you. There's only so much you can do within the 32 bit address space. That's only one reason why a 64 bit Cygwin would be a good idea. Of course there are other answers, but their implementation is really tricky: - Analyze all executables and rebase DLLs which are not used together in the same executable to the same addresses. Not good for runtime loading. - Replace the Windows loader with your own loader in Cygwin. You'll never have to rebase again. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: git-svn hang starting with 20110721 snapshot.
On 8/3/2011 1:19 PM, Corinna Vinschen wrote: On Aug 3 15:02, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote: Better drop the large address stuff for now. Since the heap is now in the large addres area(*), and since mmaps will go there, too(*), we have basically a lot more free space in the area up to 0x7fff. At this moment, I've got DLLs from 0xf000 all the way down to 0xa174, and I could easily have more if I installed all of KDE (which I provide in Ports, but I prefer to use GNOME). So where do you suggest I find that kind of open space in the lower half? Did you use the current rebaseall? If so you have a 64K hole between each DLL. Isn't this avoided by passing -o 0 to the current rebaseall? Other than that I don't have an answer for you. There's only so much you can do within the 32 bit address space. That's only one reason why a 64 bit Cygwin would be a good idea. What was the motivation for putting the heap and mmaps above 0x8000? Was there not enough space for them below? Would there be enough space below if all the DLLs were above? -- David Rothenberger daver...@acm.org zeal, n.: Quality seen in new graduates -- if you're quick. -- 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: git-svn hang starting with 20110721 snapshot.
On 8/3/2011 1:32 PM, David Rothenberger wrote: On 8/3/2011 1:19 PM, Corinna Vinschen wrote: Other than that I don't have an answer for you. There's only so much you can do within the 32 bit address space. That's only one reason why a 64 bit Cygwin would be a good idea. What was the motivation for putting the heap and mmaps above 0x8000? Was there not enough space for them below? Would there be enough space below if all the DLLs were above? Rereading this, I realized it sounds a little snotty. I'm not trying to second guess your decision; I was just curious. Feel free to ignore the question. :) -- David Rothenberger daver...@acm.org Warning: Listening to WXRT on April Fools' Day is not recommended for those who are slightly disoriented the first few hours after waking up. -- Chicago Reader 4/22/83 -- 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: ISO: recommendations while setting up a new cygwin environment.
On 8/3/2011 4:05 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2011-08-03 at 09:58 -0400, Larry W. Virden wrote:
Cygwin Ports provides a Java environment based on JamVM and GNU
Classpath, which includes Ant, ECJ, OpenJDK langtools (apt, javac,
javah, javadoc, javap), Java-GNOME programs, fop, and several dozen
libraries. It's not quite a Su^WOracle JRE but its enough for my needs.
Yes; but to use Oracle (or other Windows-based) JVMs mostly
requires setting PATH and CLASSPATH properly. Most particularly,
CLASSPATH needs to be in Windows format (';' separator, not ':',
and \ in file/directory paths, not /). This mostly requires
understanding of appropriate quoting and use of cygpath ...
Eliot Moss
--
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: ISO: recommendations while setting up a new cygwin environment.
On 8/3/2011 5:36 PM, Eliot Moss wrote:
Yes; but to use Oracle (or other Windows-based) JVMs mostly
requires setting PATH and CLASSPATH properly. Most particularly,
CLASSPATH needs to be in Windows format (';' separator, not ':',
and \ in file/directory paths, not /). This mostly requires
understanding of appropriate quoting and use of cygpath ...
Look here:
http://cygwin.com/cgi-bin/cvsweb.cgi/wrappers/java/?cvsroot=cygwin-apps
--
Chuck
--
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
odd socketpair() failure
A while ago, I tested pipe() for EMFILE failures [1]. Well, I repeated
those tests for socketpair() [2], and cygwin is once again the odd man out.
[1] http://cygwin.com/ml/cygwin/2011-06/msg00328.html
[2] http://austingroupbugs.net/view.php?id=483
$ cat foo.c
#define _POSIX_C_SOURCE 200811L
#define __EXTENSIONS__ 1
#include sys/types.h
#include sys/time.h
#include unistd.h
#include string.h
#include stdio.h
#include errno.h
#include fcntl.h
#include sys/socket.h
int
main (int argc, char **argv)
{
int last;
int fd[2] = {-2,-3};
int err;
/* Get to an EMFILE condition. */
while (1) {
int fd = open(/dev/null, O_RDONLY);
if (fd 0) {
printf (after fd %d, open failed with errno %d %s\n,
last, errno, strerror(errno));
break;
}
last = fd;
}
/* Probe behavior */
err = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
if (err)
printf (try 1, socketpair returned %d errno %d %s, fds %d %d\n,
err, errno, strerror(errno), fd[0], fd[1]);
else
printf (try 1, socketpair succeeded, fds %d %d\n, fd[0], fd[1]);
if (close(last))
return 1;
err = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
if (err)
printf (try 2, socketpair returned %d errno %d %s, fds %d %d\n,
err, errno, strerror(errno), fd[0], fd[1]);
else
printf (try 2, socketpair succeeded, fds %d %d\n, fd[0], fd[1]);
if (close(0))
return 1;
err = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
if (err)
printf (try 3, socketpair returned %d errno %d %s, fds %d %d\n,
err, errno, strerror(errno), fd[0], fd[1]);
else
printf (try 3, socketpair succeeded, fds %d %d\n, fd[0], fd[1]);
return 0;
}
$ ./foo
after fd 3199, open failed with errno 24 Too many open files
try 1, socketpair returned -1 errno 24 Too many open files, fds -2 -3
try 2, socketpair returned -1 errno 24 Too many open files, fds -2 -3
try 3, socketpair returned -1 errno 24 Too many open files, fds -2 -3
But on Linux, try 3 succeeds. Something in cygwin is not quite right on
try 3 - the program explicitly freed two fd slots (0 and 3199), so it
should have plenty of room to create the socketpair without hitting EMFILE.
Disclaimer: I tested on 1.7.9 rather than the latest snapshot; maybe the
pipe() fix in the meantime also fixed socketpair()?
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
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: gdb-7.3.50-1
On 3 August 2011 15:44, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 06:33 -0400, Chris Sutcliffe wrote: Passing '--with-python=/usr/bin/python' as opposed to messing with CPPFLAGS, etc. might be easier. I just recently built if for MinGW and specifying the python interpreter in '--with-python' caused gdb's configure to DTRT (in terms of locating the header files, appropriate libraries, etc.). cgf is cross-compiling GDB, which rules out using a Python interpreter to get this information, as noted in gdb/configure.ac. Fair enough, I had thought cgf was compiling natively under Cygwin. Cheers, Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d -- 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: Commands slow in wait_sig.
Nothing in the above indicates that there is a problem in wait_sig. The delta times in an strace do not mean This is how long an operation took. They just indicate the number of microseconds since the last update to strace output. What the above says is: 1) wait_sig is about to call ReadFile. It has been 9743 microseconds since strace last reported anytinng. 2) There was a lag of 342445 microseconds before something happened in main. That could be symptomatic of the problem which the 8/01 snapshot works around. Or not. If it is only happening on one system that obviously points to BLODA. cgf Hi, Marco, cgf, Thanks for the reply. I don't use bash-completion. $ cygcheck -cd bash-completion Cygwin Package Information Package Version $ I do use symantec antivirus which is in the BLODA list. I disabled it and observed a little performance improvement. 2 Thu Aug 4 09:41:55 2011 1 Thu Aug 4 09:41:56 2011 2 Thu Aug 4 09:41:57 2011 1 Thu Aug 4 09:41:58 2011 2 Thu Aug 4 09:41:59 2011 1 Thu Aug 4 09:42:00 2011 2 Thu Aug 4 09:42:01 2011 But not dramatically. Other PCs I have also have symantec antivirus and no problem. Also in the problem PC symantec antivirus had been installed from the beginning and no performance issue was seen before. So I doubt symantec is the main contributor to the command delay. But since no other systems with the same dll level do no see the problem, I think it is possible there may be other software that interfares cygwin's work. Is there any good way to find a specific BLODA that is having main effect to my PC? Regards, Yuta -- 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
Device numbers, Cygwin vs. Linux
I'm working on /proc/devices, but upon comparing to Linux[1], I noticed some differences in character device numbering: * /dev/tty Linux is 5,0, Cygwin is 3,0 * /dev/tty[N] Linux is 4,[N], Cygwin 136,N (major 136 is /dev/pts/N on Linux) * /dev/console Linux is 5,1, Cygwin is 3,0 (same as /dev/tty !) * /dev/ttyS[N] Linux is 4,[N+64], Cygwin is 117,[N] Why these differences? Yaakov [1] http://www.kernel.org/pub/linux/docs/device-list/devices-2.6+.txt -- 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: Device numbers, Cygwin vs. Linux
On Wed, Aug 03, 2011 at 09:33:32PM -0500, Yaakov (Cygwin/X) wrote: I'm working on /proc/devices, but upon comparing to Linux[1], I noticed some differences in character device numbering: * /dev/tty Linux is 5,0, Cygwin is 3,0 You're using a snapshot. After my pty reorg, Cygwin, probably erroneously, effectively symlinks /dev/tty to whatever your current tty is. It will either be a pty or a console. * /dev/tty[N] Linux is 4,[N], Cygwin 136,N (major 136 is /dev/pts/N on Linux) * /dev/console Linux is 5,1, Cygwin is 3,0 (same as /dev/tty !) See above. * /dev/ttyS[N] Linux is 4,[N+64], Cygwin is 117,[N] Why these differences? I had a reason when I set up the device numbers but I don't remember any more. I tried to adhere to linux but there wasn't a 1-1 correspondence. And, possibly the numbering changed over time for linux. cgf -- 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: Device numbers, Cygwin vs. Linux
On Wed, 2011-08-03 at 21:33 -0500, Yaakov (Cygwin/X) wrote: I'm working on /proc/devices, but upon comparing to Linux[1], I noticed some differences in character device numbering: * /dev/tty Linux is 5,0, Cygwin is 3,0 * /dev/tty[N] Linux is 4,[N], Cygwin 136,N (major 136 is /dev/pts/N on Linux) * /dev/console Linux is 5,1, Cygwin is 3,0 (same as /dev/tty !) * /dev/ttyS[N] Linux is 4,[N+64], Cygwin is 117,[N] Why these differences? One more: * /dev/clipboard and /dev/windows are in major device 13, which on Linux is for input devices (joysticks, mice, event queues). Wouldn't major device 10 (misc) be a better place for them? Yaakov -- 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: Device numbers, Cygwin vs. Linux
On Wed, Aug 03, 2011 at 11:31:54PM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2011-08-03 at 21:33 -0500, Yaakov (Cygwin/X) wrote: I'm working on /proc/devices, but upon comparing to Linux[1], I noticed some differences in character device numbering: * /dev/tty Linux is 5,0, Cygwin is 3,0 * /dev/tty[N] Linux is 4,[N], Cygwin 136,N (major 136 is /dev/pts/N on Linux) * /dev/console Linux is 5,1, Cygwin is 3,0 (same as /dev/tty !) * /dev/ttyS[N] Linux is 4,[N+64], Cygwin is 117,[N] Why these differences? One more: * /dev/clipboard and /dev/windows are in major device 13, which on Linux is for input devices (joysticks, mice, event queues). Wouldn't major device 10 (misc) be a better place for them? I believe that one of the reasons I didn't change the numbers is that I didn't know if anything was relying on them. As much as I like linux compatibility I don't see any reason to change them now. cgf -- 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
