Extending /proc/*/maps
Hi all,
Please find attached three patches which extend the functionality of
/proc/*/maps.
The first (proc-maps-files) makes format_process_maps report all
reserved or committed address space, rather than just the parts occupied
by dlls in the dll_list. It splits allocations when they have multiple
sets of permissions (with proper file offsets when appropriate),
displays the file name of all mapped images and files, and identifies
shared memory segments.
The second (proc-maps-heaps) adds reporting of Windows heaps (or their
bases, at least). Unfortunately there doesn't seem to be any efficient
way to identify all virtual allocations which a heap owns.
The third (proc-maps-safe) adds a safe mode and helper function which
allows to print the process map at early stages of process startup when
cygwin1.dll is not initialized yet. It is provided in case anyone finds
it helpful; I don't expect it to migrate upstream.
Changelog entries also attached...
NOTE 1: I do not attempt to identify PEB, TEB, or thread stacks. The
first could be done easily enough, but the second and third require
venturing into undocumented/private Windows APIs.
NOTE 2: If desired, we could easily extend format_process_maps further
to report section names of mapped images (linux does this for .so
files), using the pe/coff file introspection class that accompanies my
fork patches (separate email). I did not implement it because I don't
know if people want that functionality. I haven't needed it yet.
Thoughts?
Ryan
# HG changeset patch
# Parent 1420f18fd5c5647e475df8339486020b456fb9d8
diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2011-05-10 Ryan Johnson ryan.john...@cs.utoronto.ca
+
+ * fhandler_process.cc (dos_drive_mappings, heap_info): New helper
classes.
+ (format_process_maps): Reworked to report all mapped address space
+ in a process (committed or reserved), identifying the nature of
+ the mapping (mapped file/image, heap, shared memory) when
+ possible.
+ * autoload.cc: Register GetMappedFileNameW (psapi.dll)
+
2011-04-15 Yaakov Selkowitz yselkow...@users.sourceforge.net
* thread.cc (pthread_setschedprio): New function.
diff --git a/autoload.cc b/autoload.cc
--- a/autoload.cc
+++ b/autoload.cc
@@ -422,6 +422,7 @@
LoadDLLfunc (CoTaskMemFree, 4, ole32)
LoadDLLfunc (EnumProcessModules, 16, psapi)
+LoadDLLfunc (GetMappedFileNameW, 16, psapi)
LoadDLLfunc (GetModuleFileNameExW, 16, psapi)
LoadDLLfunc (GetModuleInformation, 16, psapi)
LoadDLLfunc (GetProcessMemoryInfo, 12, psapi)
diff --git a/fhandler_process.cc b/fhandler_process.cc
--- a/fhandler_process.cc
+++ b/fhandler_process.cc
@@ -527,6 +527,81 @@
return len + 1;
}
+struct dos_drive_mappings {
+ struct mapping {
+mapping* next;
+int len;
+wchar_t drive_letter;
+wchar_t mapping[1];
+ };
+ mapping* mappings;
+
+ dos_drive_mappings ()
+: mappings(0)
+ {
+/* The logical drive strings buffer holds a list of (at most 26)
+ drive names separated by nulls and terminated by a double-null:
+
+ a:\\\0b:\\\0...z:\\\0
+
+ The annoying part is, QueryDosDeviceW wants only x: rather
+ than the x:\ we get back from GetLogicalDriveStringsW, so
+ we'll have to strip out the trailing slash for each mapping.
+
+ The returned mapping a native NT pathname (\Device\...) which
+ we can use to fix up the output of GetMappedFileNameW
+*/
+static unsigned const DBUFLEN = 26*4;
+wchar_t dbuf[DBUFLEN+1];
+wchar_t pbuf[NT_MAX_PATH+1];
+wchar_t drive[] = {L'x', L':', 0};
+unsigned result = GetLogicalDriveStringsW (DBUFLEN*sizeof (wchar_t), dbuf);
+if (!result)
+ debug_printf (Failed to get logical DOS drive names: %lu, GetLastError
());
+else if (result DBUFLEN)
+ debug_printf (Too many mapped drive letters: %u, result);
+else
+ for (wchar_t* cur = dbuf; (*drive=*cur); cur = wcschr (cur, L'\0')+1)
+ if (QueryDosDeviceW (drive, pbuf, NT_MAX_PATH))
+ {
+ size_t plen = wcslen (pbuf);
+ size_t psize = plen*sizeof (wchar_t);
+ debug_printf (DOS drive %ls maps to %ls, drive, pbuf);
+ mapping* m = (mapping*) cmalloc (HEAP_FHANDLER, sizeof (mapping) +
psize);
+ m-next = mappings;
+ m-len = plen;
+ m-drive_letter = *drive;
+ memcpy (m-mapping, pbuf, psize + sizeof (wchar_t));
+ mappings = m;
+ }
+ else
+ debug_printf (Unable to determine the native mapping for %ls (error
%lu),
+ drive,
+ GetLastError ());
+ }
+
+ wchar_t* fixup_if_match (wchar_t* path) {
+for (mapping* m = mappings; m; m = m-next)
+ if (!wcsncmp (m-mapping, path, m-len))
+ {
+ path += m-len-2;
+ path[0] = m-drive_letter;
+ path[1] = L':';
+ break;
+ }
+return
strace swallows stderr?
Hi all, It seems that when strace is running an app, that app's stderr output disappears. Is this normal/expected? The problem doesn't seem to arise if strace opens the app in a different window or sends its own output to a log file, but both of those have their disadvantages. Thanks, Ryan -- 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
Emacs backgrounds itself
Hi all, Strange one here... I just updated emacs and a bunch of other packages, and for some reason 'emacs -nw' now backgrounds itself immediately after starting, and again each time I try to foreground it afterward. If I run emacs-X11 directly (again, in -nw mode) it segfaults during startup, but I haven't been able to catch it in the act using gcc (it seems to load properly under gcc but keyboard handling is worthless). Cygcheck output is attached. I've tried running a home-built emacs-23.3.1 and it behaves the same way; running the same home-built binary against an older install I happened to have laying around works normally, so some library update must be the culprit. To help narrow things down a bit, a diff of old vs. new cygcheck outputs is also attached. Any ideas? Ryan Cygwin Package Information Package Version _update-info-dir 00959-1 alternatives 1.3.30c-10 autoconf 10-1 autoconf2.1 2.13-10 autoconf2.5 2.68-1 automake 4-10 automake1.10 1.10.3-1 automake1.11 1.11.1-1 automake1.4 1.4p6-10 automake1.5 1.5-10 automake1.6 1.6.3-11 automake1.7 1.7.9-10 automake1.8 1.8.5-10 automake1.9 1.9.6-10 base-cygwin 3.0-1 base-files 4.0-6 bash 4.1.10-4 binutils 2.20.51-2 bison2.4.2-1 bzip21.0.6-1 cocom0.996-1 coreutils8.10-1 cpio 2.11-1 crypt1.1-1 csih 0.9.4-1 cvs 1.12.13-10 cvsps2.2b1-1 cygrunsrv1.34-1 cygutils 1.4.6-1 cygwin 1.7.9-1 cygwin-doc 1.7-1 damageproto 1.2.0-1 dash 0.5.6.1-2 diffutils2.9-1 dos2unix 5.3-1 ed 1.0-1 editrights 1.01-2 emacs23.3-2 emacs-X1123.3-2 epstool 3.08-2 file 5.05-1 findutils4.5.9-2 fixesproto 4.1.1-1 flex 2.5.35-1 font-adobe-dpi75 1.0.1-1 font-alias 1.0.2-1 font-encodings 1.0.3-1 font-misc-misc 1.1.0-1 fontconfig 2.8.0-1 gamin0.1.10-11 gawk 3.1.8-1 gcc 3.4.4-999 gcc-core 3.4.4-999 gcc-g++ 3.4.4-999 gcc-mingw20040810-1 gcc-mingw-core 20050522-3 gcc-mingw-g++20050522-3 gcc4 4.3.4-4 gcc4-core4.3.4-4 gcc4-g++ 4.3.4-4 gcc4-java4.3.4-4 gdb 6.8-2 gettext 0.17-11 ghostscript 8.63-2 ghostscript-fonts-other 6.0-1 ghostscript-fonts-std8.11-1 giflib 4.1.6-10 git 1.7.4-1 glproto 1.4.11-1 gmp 4.3.1-3 gnome-icon-theme 2.30.3-1 gnuplot 4.4.0-1 grep 2.6.3-1 groff1.20.1-2 gtk+ 1.2.10-10 guile1.8.7-2 gv 3.6.5-1 gzip 1.4-1 hicolor-icon-theme 0.12-1 ipc-utils1.0-1 jpeg 8b-1 kbproto 1.0.4-1 less 436-1 libapr1 1.4.2-1 libaprutil1 1.3.10-1 libatk1.0_0 1.30.0-1 libattr1 2.4.43-1 libblkid12.17.2-1 libbz2-devel 1.0.6-1 libbz2_1 1.0.6-1 libcairo-devel 1.8.10-1 libcairo21.8.10-1 libcharset1 1.13.1-2 libcloog00.15.7-1 libcroco0.6_30.6.2-10 libcurl4 7.20.1-1 libdb4.5 4.5.20.2-2 libdbus1_3 1.2.24-1 libecpg5 8.2.11-1 libedit0 20090923-1 libexpat12.0.1-1 libexpat1-devel 2.0.1-1 libfam0 0.1.10-11 libffi4 4.3.4-4 libfontconfig-devel 2.8.0-1 libfontconfig1 2.8.0-1 libfontenc1 1.0.5-1 libfreetype-devel2.3.12-1 libfreetype6 2.3.12-1 libgcc1 4.3.4-4 libgcj-common4.3.4-4 libgcj9 4.3.4-4 libgcrypt11 1.4.5-1 libgd2 2.0.36RC1-11 libgdbm4 1.8.3-20 libgdk_pixbuf2.0_0 2.20.1-1 libggi2 2.2.2-2 libggiwmh0 0.3.2-2 libgif-devel 4.1.6-10 libgif4 4.1.6-10 libgii1 1.0.2-2 libGL-devel 7.8.2-1 libGL1 7.8.2-1 libglib1.2_0 1.2.10-10
Re: Emacs backgrounds itself
s/gcc/gdb/g *sigh* On 05/05/2011 10:34 AM, Ryan Johnson wrote: Hi all, Strange one here... I just updated emacs and a bunch of other packages, and for some reason 'emacs -nw' now backgrounds itself immediately after starting, and again each time I try to foreground it afterward. If I run emacs-X11 directly (again, in -nw mode) it segfaults during startup, but I haven't been able to catch it in the act using gcc (it seems to load properly under gcc but keyboard handling is worthless). Cygcheck output is attached. I've tried running a home-built emacs-23.3.1 and it behaves the same way; running the same home-built binary against an older install I happened to have laying around works normally, so some library update must be the culprit. To help narrow things down a bit, a diff of old vs. new cygcheck outputs is also attached. Any ideas? Ryan -- 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: Emacs backgrounds itself (solved)
On 05/05/2011 10:34 AM, Ryan Johnson wrote: Hi all, Strange one here... I just updated emacs and a bunch of other packages, and for some reason 'emacs -nw' now backgrounds itself immediately after starting, and again each time I try to foreground it afterward. If I run emacs-X11 directly (again, in -nw mode) it segfaults during startup, but I haven't been able to catch it in the act using gcc (it seems to load properly under gcc but keyboard handling is worthless). Cygcheck output is attached. Update: perl and cygcheck also started going bad, which makes me think I must have done something to corrupt my install -- a fresh installation works normally. Ryan -- 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: Spurious warnings about MS-DOS paths
On 2:59 PM, Eric Blake wrote: On 04/13/2011 09:10 PM, Ryan Johnson wrote: Hi all, A recent cygwin update has started spewing warnings such as the following when I do tab completion on a path containing spaces: $ cd ~/Home/Documents/Pcygwin warning: MS-DOS style path detected: ~/Home/Documents/PC\ reviews\ 2011 Preferred POSIX equivalent is: ~/Home/Documents/PC/ reviews/ 2011 CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Would it be possible to make the check exclude common character escapes? No, but it probably is an upstream bug the bash-completion package worth reporting and fixing. Can you use 'set -vx' just before typing the command that triggers the message, so I can see which command in the completion function is insufficiently quoting the pathname such that a glob completion is being inappropriately attempted on escape characters? I don't have bash-completion(s) installed. If set -vx would be useful with vanilla bash, I'm happy to try it, though. Regards, Ryan -- 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: bash died waiting for longjmp before initialization
I haven't had bash crash on me, but I do get other fork-related errors on my win7-x64 system. You might try running the attached testcase (make ./fork) a few times to see if it reproduces the problem. For me it usually complains about access violations during the fork and sometimes dies waiting for longjmp, with the culprit being two dlls which want to load at the same address. The usual advice most likely applies: rebase your system (a workaround which usually prevents the condition that triggers the bug... until you run setup.exe again). Regards, Ryan On 2:59 PM, Lonni J Friedman wrote: Greetings, I've been experiencing seemingly random bash shell crashes on all (20+) Windows7-x64 systems that I have in a lab which are used for automated tests of my employer's software. Every time that bash crashes, I see an error very similar to the following: 5 [main] bash 3100 fork: child -1 - died waiting for longjmp before initialization, retry -1, exit code 0xC142, errno 11 Occasionally, I also see a few additional errors immediately after the above error, such as these: 2 [main] ? (4264) child_copy: cygheap read copy failed, 0x611688E0..0x6116BCF8, done 0, windows pid 0, Win32 error 299 124115 [main] bash 4264 child_copy: dll data read copy failed, 0x61102000..0x61106BA0, done 0, windows pid 4264, Win32 error 299 I've not had any success manually reproducing or attempting to force this crash. Its always been completely random, however it happens at least once every day on every Win7-x64 system. I've attached the output from running 'cygcheck -s -v -r' on one of the systems where this failure has occurred many times. I can provide the output from other systems as well if requested. I'd be happy to answer any questions or provide more information, or perform some form of debugging if someone requests something specific. thanks! fork-tests.tar Description: Binary data -- 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: Debugging help for fork failure: resource temporarily unavailable
On 2:59 PM, Ryan Johnson wrote: I wrote a very simple program whose main() prints out the contents of /proc/self/maps, forks, calls foo() and bar(), and finally (if the parent) calls wait(). The trick is, foo() and bar() reside in cygfoo.dll and cygbar.dll respectively, which I compiled to have the same base address: 0x6600. The running binary often, but not always, results in those annoying exception::handle: Exception: STATUS_ACCESS_VIOLATION messages (the process otherwise appears to complete normally most of the time). However, once in a while the child fails to spawn, with no particular error message to advertise that fact. After downloading windbg, I was able to capture the stack traces of access violations. It turns out there's no retry code at all; it's just some access violations cause the exception handler to crash with a variable number of additional violations. At this point I'm officially in over my head. The output below is hopefully useful to somebody who knows a lot more than I do about the code which is involved here. Help? Ideas? Ryan The first access violation occurred in la-la land: WARNING: FrameIP not in any known module. Following frames may be wrong. 610203ea 0x5c0073 6111ccca cygwin1!dlerror+0x6aa 610050ab cygwin1!wordfree+0x4d4a 61007040 cygwin1!setprogname+0x36bb 61004c96 cygwin1!dll_crt0__FP11per_process+0x710 61004d3b cygwin1!setprogname+0x32a6 004013c2 cygwin1!setprogname+0x334b 00401015 image_0040+0x13c2 756633ca image_0040+0x1015 77619ed2 kernel32!BaseThreadInitThunk+0x12 77619ea5 ntdll32!RtlInitializeExceptionChain+0x63 ntdll32!RtlInitializeExceptionChain+0x36 Passing the above through gdb's disassembler: 0x5c0073 _ZN10per_module9run_dtorsEv+24:call *%eax exit+21: call 0x61144970 __call_exitprocs cygwin_exit+22:call 0x6111ccb0 exit _cygwin_exit_return+526: call 0x61005090 cygwin_exit cygwin_crt0+28:call *0x405120 mainCRTStartup+16: call 0x4013a0 cygwin_crt0 kernel32!BaseThreadInitThunk+0x12 ... ntdll calls ... Continuing with windbg from there gave the following: cYgSiGw00f 11 0x2030 0x28CE8CHEAP[fork.exe]: HEAP: Free Heap block 2b3ac0 modified at 2b4000 after it was freed ntdll!EtwpCreateEtwThread+0x1721 Continuing on again: WARNING: Stack unwind information not available. Following frames may be wrong. 660010d9 cyggcc_s_1!_deregister_frame_info_bases+0x48 610203ea cygbar+0x10d9 6111ccca cygwin1!dlerror+0x6aa 77638fba ntdll32!RtlQueryEnvironmentVariable+0x241 77638e5c ntdll32!LdrShutdownProcess+0x141 75667a25 ntdll32!RtlExitUserProcess+0x74 6109d683 kernel32!ExitProcess+0x15 61005360 cygwin1!cygwin32_posix_path_list_p+0xa2f3 610283e1 cygwin1!setprogname+0x3970 61029034 cygwin1!getenv+0x4611 77626ab9 cygwin1!getenv+0x5264 77626a8b ntdll32!RtlDosSearchPath_Ustr+0xada 775f0143 ntdll32!RtlDosSearchPath_Ustr+0xaac 6111ccca ntdll32!KiUserExceptionDispatcher+0xf 610050ab cygwin1!wordfree+0x4d4a 61007040 cygwin1!setprogname+0x36bb (rest continues as in the first stack trace) Again decoding with gdb: __gcc_deregister_frame+48: movl $0x66003000,(%esp) _ZN10per_module9run_dtorsEv+24:call *%eax exit+21: call 0x61144970 __call_exitprocs ... ntdll calls... kernel32!ExitProcess+0x15 _ZN5pinfo4exitEm+270: call 0x61159c90 ExitProcess@4 _Z7do_exiti@4+587: call 0x6109d570 _ZN5pinfo4exitEm _ZN7_cygtls11signal_exitEi+284:call 0x61005110 _Z7do_exiti@4 _ZN9exception6handleEP17_EXCEPTION_RECORDP15_exception_listP8_CONTEXTPv+1295: call 0x610282c0 _ZN7_cygtls11signal_exitEi ... ntdll calls ... ntdll32!KiUserExceptionDispatcher+0xf ... below this is the stack trace from the original access violation ... Continuing yet again gives a third access violation inside ntdll32, due to a second call to KiUserExceptionDispatcher: WARNING: Stack unwind information not available. Following frames may be wrong. 0028c080 77626ab9 ntdll32!RtlUlonglongByteSwap+0x1605d 0028c0a4 77626a8b ntdll32!RtlDosSearchPath_Ustr+0xada 0028c154 775f0143 ntdll32!RtlDosSearchPath_Ustr+0xaac 0028c4bc 660010d9 ntdll32!KiUserExceptionDispatcher+0xf 0028c4cc 610203ea cygbar+0x10d9 ... continues as before ... At this point we're in an endless loop of access violations in the user exception dispatcher leading to the exception dispatcher raising an access violation... I figured this would lead to a stack overflow and detached. Surprisingly, the output of the cygwin app contained no mention of access violations. However, the errors prevented the child process from running global destructors in its dlls: Child exiting * * * fork.cpp fini Parent after fork (child: 7944) Parent exiting * * * fork.cpp fini * * * foo.cpp fini * * * bar.cpp fini Rerunning the process a few times turned up a different access violation, this one definitely fork-related: WARNING: Stack unwind information not available. Following frames may be wrong. 0028c7dc 61020d38 cygwin1!dlerror+0x74b 0028c7fc 61004c96 cygwin1
Re: Re: Debugging help for fork failure: resource temporarily unavailable
On 2:59 PM, Jon TURNEY wrote: On 15/03/2011 13:53, Ryan Johnson wrote: All of this assumes Windows is consistent in choosing locations when conflicts It's assumed that CreateProcess() produces the same layout, yes. This assumption is due to what? - Documented Windows feature? - An observation which holds in spite of tests/abuse which try to exercise corner cases? - A wish which comes true often enough to get by in most cases? I suggest you read how-startup-shutdown-works.txt and then observe that dll_list:alloc() is called by dll_dllcrt0_1() Thanks for the pointer. Unfortunately, it doesn't tell much about fork(), nor does it make clear when memory for dependent dlls is assigned. The loader calls dependent dllmains right before entering the . owner's dllmain, but that doesn't say when the address space is reserved. There's the complexity of deferred vs. immediate dllmain calls as well. I look forward to reading your patches :-) I think it's still rather premature to be cooking up a patch, unfortunately -- I'm not convinced I know yet where the real problem lies. Without some data to back up my speculation (which seems hard to come by), any patch I might write would have a high probability of joining other accumulated band-aids such as reserve_upto(). Open questions (for my ignorant self, at least) include: - Does Windows always load a given dll at the same address when its base address is already occupied? - Does fork() always load DLLs in the same order that the parent loaded them? This would probably be helpful to know even in cases where no error arises, because it's a necessary precursor to fork failures, and the code seems to assume it's true. - Is it ever possible for fork() to unload BLODA dlls? - Do injected dlls arrive before or after statically-linked dlls? Or can it be either one? - At fork time, does cygwin mogrify some generic child process to look like the parent, or is the child another normal run of the parent's executable image followed by plastic surgery to make heap, stack, etc. match? I had been assuming the former, but should probably ask. If if statically-linked dlls ever need to be loaded manually by fork(), and injected dlls arrive after statically-linked ones, then that might explain BLODA right there: If static.dll and bloda.dll both have the same base address, and dll injection occurs after statically-linked dlls, and fork() ever needs to load static.dll manually, then that would be (at least one) way bloda can arise. Is there any way to have cygwin report dlls, base addresses, and windows-assigned addresses for dlls when a fork fails? Thoughts? Ryan -- 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: Re: Debugging help for fork failure: resource temporarily unavailable
On 2:59 PM, Ryan Johnson wrote: On 2:59 PM, Jon TURNEY wrote: I look forward to reading your patches :-) I think it's still rather premature to be cooking up a patch, unfortunately -- I'm not convinced I know yet where the real problem lies. Without some data to back up my speculation (which seems hard to come by), any patch I might write would have a high probability of joining other accumulated band-aids such as reserve_upto(). Open questions (for my ignorant self, at least) include: - Does Windows always load a given dll at the same address when its base address is already occupied? - Does fork() always load DLLs in the same order that the parent loaded them? This would probably be helpful to know even in cases where no error arises, because it's a necessary precursor to fork failures, and the code seems to assume it's true. - Is it ever possible for fork() to unload BLODA dlls? - Do injected dlls arrive before or after statically-linked dlls? Or can it be either one? - At fork time, does cygwin mogrify some generic child process to look like the parent, or is the child another normal run of the parent's executable image followed by plastic surgery to make heap, stack, etc. match? I had been assuming the former, but should probably ask. Update: I wrote a very simple program whose main() prints out the contents of /proc/self/maps, forks, calls foo() and bar(), and finally (if the parent) calls wait(). The trick is, foo() and bar() reside in cygfoo.dll and cygbar.dll respectively, which I compiled to have the same base address: 0x6600. The running binary often, but not always, results in those annoying exception::handle: Exception: STATUS_ACCESS_VIOLATION messages (the process otherwise appears to complete normally most of the time). However, once in a while the child fails to spawn, with no particular error message to advertise that fact. Running inside gdb (inside a plain cygwin window) gives the following (I'm on Win7 x64, with all the latest packages as of yesterday afternoon): $ gdb GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i686-pc-cygwin. (gdb) file fork Reading symbols from /home/Ryan/experiments/fork-tests/fork...done. (gdb) run Starting program: /home/Ryan/experiments/fork-tests/fork [New thread 8864.0x2120] Error: dll starting at 0x7719 not found. Error: dll starting at 0x7565 not found. Error: dll starting at 0x7719 not found. Error: dll starting at 0x76d2 not found. [New thread 8864.0x2710] + + + bar.cpp init + + + foo.cpp init + + + fork.cpp init 0040-0041 rw-s 00401000 2C36:17C8 33776997205430206 /home/Ryan/experiments/fork-tests/fork.exe 775E-7776 r-xs 2C36:17C8 281474976927378 /cygdrive/c/Windows/SysWOW64/ntdll.dll 7565-7576 r-xs 756632D3 2C36:17C8 281474976927037 /cygdrive/c/Windows/syswow64/kernel32.dll 7535-75396000 r-xs 75357478 2C36:17C8 281474976925120 /cygdrive/c/Windows/syswow64/KERNELBASE.dll 6600-66012000 rw-s 660011F0 2C36:17C8 3940649674730545 /home/Ryan/experiments/fork-tests/cygbar.dll 6100-6145 r-xs 6106F960 2C36:17C8 844424930325032 /usr/bin/cygwin1.dll 75A6-75B0 r-xs 75A749E5 2C36:17C8 281474976927159 /cygdrive/c/Windows/syswow64/ADVAPI32.DLL 7505-750FC000 rw-s 7505A472 2C36:17C8 281474976749314 /cygdrive/c/Windows/syswow64/msvcrt.dll 7684-76859000 r-xs 76844975 2C36:17C8 281474976749841 /cygdrive/c/Windows/SysWOW64/sechost.dll 7675-7684 r-xs 76760569 2C36:17C8 281474976924963 /cygdrive/c/Windows/syswow64/RPCRT4.dll 74CD-74D3 r-xs 74CEA3B3 2C36:17C8 281474976924512 /cygdrive/c/Windows/syswow64/SspiCli.dll 74CC-74CCC000 r-xp 74CC10E1 2C36:17C8 281474976748415 /cygdrive/c/Windows/syswow64/CRYPTBASE.dll 67F0-67F0F000 rw-s 67F08920 2C36:17C8 562949954003711 /usr/bin/cyggcc_s-1.dll 6C48-6C545000 rw-s 6C485110 2C36:17C8 562949954003739 /usr/bin/cygstdc++-6.dll 002B-002C2000 rw-p 002B11F0 2C36:17C8 2533274791177101 /home/Ryan/experiments/fork-tests/cygfoo.dll 753A-754A rw-p 753BB6ED 2C36:17C8 281474976926904 /cygdrive/c/Windows/system32/user32.dll 74FC-7505 rw-p 74FD6343 2C36:17C8 281474976926610 /cygdrive/c/Windows/syswow64/GDI32.dll 754D-754DA000 rw-p 754D36A0 2C36:17C8 281474976749103 /cygdrive/c/Windows/syswow64/LPK.dll 757D-7586D000 rw-p 75803FD7 2C36:17C8 281474976927082 /cygdrive/c/Windows/syswow64/USP10.dll 754E-7554 r-xp 754F158F 2C36:17C8 281474976924115 /cygdrive/c/Windows/system32/IMM32.DLL 74EF-74FBC000 rw-p 74EF168B 2C36:17C8 281474976749206 /cygdrive/c
Spurious warnings about MS-DOS paths
Hi all, A recent cygwin update has started spewing warnings such as the following when I do tab completion on a path containing spaces: $ cd ~/Home/Documents/Pcygwin warning: MS-DOS style path detected: ~/Home/Documents/PC\ reviews\ 2011 Preferred POSIX equivalent is: ~/Home/Documents/PC/ reviews/ 2011 CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Would it be possible to make the check exclude common character escapes? Regards, Ryan -- 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: BLODA detection (was Re: Debugging help for fork failure: resource temporarily unavailable)
On 2:59 PM, Henry S. Thompson wrote: Ryan Johnson writes: BTW, I found a good way to identify, if not fix, BLODA: given an app which loads no libraries at runtime -- such as 'ls' -- any dlls mentioned in /proc/$$/maps which cygcheck does not mention are probably dodgy. In my case, Windows Live (which I didn't think was even installed on my machine) has injected a WLIDNSP.DLL (Microsoft Windows Live ID Namespace Provider) in all my processes. This would be super-cool if true, but it doesn't work for me. . . If I try, I find C:\Windows\system32\ntmarta.dll C:\Windows\SysWOW64\sechost.dll C:\Windows\syswow64\WLDAP32.dll in /proc/[ls procid]/maps but not in cygcheck output, but none of those are BLODA, right? [Note also that maps shows many things in syswow64 which cygcheck shows in system32, but presumably that's because cygcheck itself is a 32-bit app, is it?] Interesting... $ join -i -v 1 (cat /proc/$$/maps | sed 's;^.*/;;' | sort -f) (cygcheck $(cat /proc/$$/winexename) | sed 's;^.*\\;;' | sort -f) apphelp.dll DNSAPI.dll IMM32.DLL MSCTF.dll mswsock.dll napinsp.dll NLAapi.dll NSI.dll pnrpnsp.dll PSAPI.DLL sechost.dll SHLWAPI.dll winmm.dll winrnr.dll WLIDNSP.DLL ws2_32.dll wshbth.dll The above shows all dlls loaded by the process which are not linked in at compile time. Does bash really load so many dynamic libraries, or is cygcheck missing things? Ryan -- 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: Debugging help for fork failure: resource temporarily unavailable
On 2:59 PM, Jon TURNEY wrote: On 09/03/2011 17:04, Ryan Johnson wrote BTW, while looking at the code I noticed a potential source of remap problems: if B depends on A, and we remap A first, then only A's location will be checked carefully; B will be pulled in wherever it happens to end up when we do the full load of A. The code seems to assume that every DLL we try to remap is currently not loaded. I'm actually not sure what would happen when time came to remap B, because loading it would just return the handle we didn't know we had, and closing that handle wouldn't take its reference count to zero. I too have idly mused that there might be an issue with dependent DLLs here. But, since dll_list::load_after_fork() walks the dll list in the same order as the dlopen() calls occur, I've never been able to convince myself there is a real problem, barring esoteric scenarios like: B depends on A, C depends on A, load B, load C (C collides with A so loads at non-preferred address), unload B, fork Oh, I see what you mean... in theory, asking Windows to load the same dlls in the same order should put them at the same addresses. That doesn't match what really happens though: where problems are seen it's often with python or perl, which dynamically load libraries when modules are imported, but won't unload them in normal use. All of this assumes Windows is consistent in choosing locations when conflicts are involved. IOW, consider the case that B depends on A, with A and B both conflicting with a later-loaded C. The first time A and C load Windows will choose alternate locations for them, and if that order changes in the child, it's totally possible that A ends up in the child where C was in the parent. Incidentally, this same problem would arise if a BLODA injected a DLL into the process -- that DLL would be on the todo list for fork() to process (because it was also injected into the parent process), but would already be loaded by the time we try to remap it. Also, if we do want to force Windows not to put a dll in a certain address, wouldn't it make more sense to reserve the (wrong) space it went into on the first try? Right now if the offending location is higher than the one we want, nothing stops Windows from just putting it right back in its old spot because the code only reserves locations lower than the desired one. Is this accurate or am I missing something here? I'm not sure that particular scenario with injected DLLs is possible, as the list traversed in dll_list::load_after_fork() is only of dynamically loaded cygwin-based DLLs? Oh, so injected dlls, though not statically linked in, still wouldn't be on this list? BTW, I found a good way to identify, if not fix, BLODA: given an app which loads no libraries at runtime -- such as 'ls' -- any dlls mentioned in /proc/$$/maps which cygcheck does not mention are probably dodgy. In my case, Windows Live (which I didn't think was even installed on my machine) has injected a WLIDNSP.DLL (Microsoft Windows Live ID Namespace Provider) in all my processes. $ objdump -p /usr/bin/cygpyglib-2.0-python2.6-0.dll | grep ^ImageBase ImageBase 6aa4 $ objdump -p /usr/bin/cygglib-2.0-0.dll | grep ^ImageBase ImageBase 6aa4 C:\cygwin\bin\cygglib-2.0-0.dll @ 0x6AA4 using DONT_RESOLVE_DLL_REFERENCES 1263 [main] python 3008 dll_list::load_after_fork: reserve_upto 0x18C4 to try to force it to load there 1473 [main] python 3008 dll_list::load_after_fork: LoadLibrary C:\cygwin\bin\cygglib-2.0-0.dll @ 0x6AA4 using DONT_RESOLVE_DLL_REFERENCES 1620 [main] python 3008 C:\cygwin\bin\python.exe: *** fatal error - unable to remap C:\cygwin\bin\cygglib-2.0-0.dll to same address as parent: 0x18C4 != 0x6AA4 and I've confirmed that in the parent, cygpyglib-2.0-python2.6-0.dll loads at 0x6AA4 and cygglib-2.0-0.dll loads at 0x18C4. At a wild guess, it looks like LoadLibraryEx() maps DLLs into memory starting from the top of the dependency chain, but then calls the DLL's entry point starting from the bottom of the dependency chain (which makes all kinds of sense, but leads to this inversion of the load order in the child) So the problem basically arises because dlls in the child are not actually loaded in the same order as in the parent? In this case I assume that cygpyglib depends on cygglib, which suggests that we could avoid a lot of trouble by handling dependent children first. Also, it looks like the above is exactly the case I suspected -- the offending dll attempts to load *higher* than where we want it, so reserving space below does nothing for us. I assume there's a way to enumerate the dlls loaded in a given process; would it make sense to use a three-step algorithm? 1. Unload all currently-loaded dlls, complaining loudly to stderr or a log file (these are due to BLODA and deserve to be called out) 2. Load without deps every DLL and make sure it lands at the right address
Re: Re: Debugging help for fork failure: resource temporarily unavailable
On 2:59 PM, Corinna Vinschen wrote: On Mar 5 17:15, Ryan Johnson wrote: Might it be possible to do an LD_PRELOAD of some sort which hooks into fork() at the critical moment and prints the differences between /proc/$parent/maps and /proc/$child/maps? The code doesn't even need to be efficient; it just needs to be able to run when whatever internal helper of fork() returns an error but before the nascent child process is terminated. If there exists such a convenient instrumentation point, I might be up to the task of exploiting it, but I wouldn't know where to start. It's not that easy. LD_PRELOAD is only honored after the other stuff to duplicate the parent process has already taken place. This is definitely not something for 1.7.9, but maybe we can utilize the functionality we already have on board at one point. In fhandler_process.cc we have the function format_process_maps(), which creates a buffer with the content of /proc/$PID/maps. It might be possible to call this function from fork for parent and child if fork fails for this reason, and print this information. Just an idea. Somebody still would have to do it(*). I was actually thinking of an LD_PRELOAD in the parent process which would cause new/additional code to execute when that parent forks. However, after poking around in the code I'm not sure this is possible, since IIRC LD_PRELOAD can only override dynamically-linked functions. That probably means an actual change to cygwin is required, as you suggest. BTW, while looking at the code I noticed a potential source of remap problems: if B depends on A, and we remap A first, then only A's location will be checked carefully; B will be pulled in wherever it happens to end up when we do the full load of A. The code seems to assume that every DLL we try to remap is currently not loaded. I'm actually not sure what would happen when time came to remap B, because loading it would just return the handle we didn't know we had, and closing that handle wouldn't take its reference count to zero. Incidentally, this same problem would arise if a BLODA injected a DLL into the process -- that DLL would be on the todo list for fork() to process (because it was also injected into the parent process), but would already be loaded by the time we try to remap it. Also, if we do want to force Windows not to put a dll in a certain address, wouldn't it make more sense to reserve the (wrong) space it went into on the first try? Right now if the offending location is higher than the one we want, nothing stops Windows from just putting it right back in its old spot because the code only reserves locations lower than the desired one. Is this accurate or am I missing something here? I assume there's a way to enumerate the dlls loaded in a given process; would it make sense to use a three-step algorithm? 1. Unload all currently-loaded dlls, complaining loudly to stderr or a log file (these are due to BLODA and deserve to be called out) 2. Load without deps every DLL and make sure it lands at the right address (using memory reservation tricks if needed) 3. Reload with deps every DLL. Presumably once it has landed correctly once it will do so thereafter (the current code assumes this, at least) In theory, the first step might allow cygwin to resist dll injection (maybe on an opt-out basis?), though I don't know what the consequences of that choice would be. The third step would be significantly easier if we had a dependency graph so that we could ensure dependencies always get processed before they're needed, but I don't know if that's feasible. How expensive/embeddable is cygcheck? Ryan -- 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: Debugging help for fork failure: resource temporarily unavailable
On 2:59 PM, Ryan Johnson wrote: I'm hitting the oh-so-delightful fork failures when trying to compile a cross-compiler toolchain, which is a pain because one fork failure makes crosstool-ng start over. I've rebased, I've been over the BLODA (Windows Defender slipped in even after I rejected the download), and while they definitely helped there's likely to be at least one fork failure while compiling a big project like glibc. So, now comes my plea (I don't know enough about cygwin to do this myself). It seems like the usual culprit -- dll injection in the child at an address that the parent already used -- could easily be diagnosed by the code which notices and aborts the fork: given two dlls which want to use the same address in the child process, the one at a different address in the parent is probably to blame. Fingering this offending DLL, either as part of the fork failure message or in a log file of some sort, would make it infinitely easier for users to diagnose the problem, and would also give a much clearer idea of what really went wrong (we could order the BLODA by how often each app causes headaches, for example). Actually, a follow-up question: what is the difference between the fork (e.g. resource unavailable) failures vs. the errors about 'failed to remap dll ...' ? Looking at the code in dll_init.cc, if failure to remap a dll were really the source of fork failing, the error message should say so. Is there some other issue due to BLODA that also causes forks to fail? Also, how does the (new?) peflagsall script interact with dll injection? It sounds like it's supposed to fix dll remapping problems on machines which support ASLR... Thanks, Ryan -- 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
Debugging help for fork failure: resource temporarily unavailable
Hi all, I'm hitting the oh-so-delightful fork failures when trying to compile a cross-compiler toolchain, which is a pain because one fork failure makes crosstool-ng start over. I've rebased, I've been over the BLODA (Windows Defender slipped in even after I rejected the download), and while they definitely helped there's likely to be at least one fork failure while compiling a big project like glibc. So, now comes my plea (I don't know enough about cygwin to do this myself). It seems like the usual culprit -- dll injection in the child at an address that the parent already used -- could easily be diagnosed by the code which notices and aborts the fork: given two dlls which want to use the same address in the child process, the one at a different address in the parent is probably to blame. Fingering this offending DLL, either as part of the fork failure message or in a log file of some sort, would make it infinitely easier for users to diagnose the problem, and would also give a much clearer idea of what really went wrong (we could order the BLODA by how often each app causes headaches, for example). Might it be possible to do an LD_PRELOAD of some sort which hooks into fork() at the critical moment and prints the differences between /proc/$parent/maps and /proc/$child/maps? The code doesn't even need to be efficient; it just needs to be able to run when whatever internal helper of fork() returns an error but before the nascent child process is terminated. If there exists such a convenient instrumentation point, I might be up to the task of exploiting it, but I wouldn't know where to start. Thoughts? Ideas? Ryan -- 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
Changing mirrors in setup doesn't propagate forward
Hi all, I just ran into a minor annoyance while trying to run setup.exe (downloaded from cygwin.com just a few minutes ago): I accidentally selected a mirror on the wrong side of the ocean, so I hit 'back' and chose a different, much closer one. The package list was pulled from the local mirror, but when I actually started the download, setup used the first (transatlantic) mirror, resulting in 8kB/sec transfer rate. Cancelling and restarting setup, then selecting the local mirror the first time around, worked fine. Has anyone else seen this behavior? Thanks, Ryan -- 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
libglade2.0.sh exit code 2
Hi all, I just installed libglade as an automatically-detected dependency of pygtk, and it complained of an exit code 2 in the post-install. Looking at /var/log/install.log.full didn't show anything out of the ordinary (no error messages at all) Other than this, it seems to work fine. Is this just a stray exit code? Regards, Ryan -- 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: gitk kills bash shell
On 9/28/2010 9:40 PM, Jeremy Ramer wrote: On Tue, Sep 28, 2010 at 1:01 PM, Ryan Johnsonryanj...@ece.cmu.edu wrote: This sounds suspiciously similar to a problem that hit me a while back: http://www.cygwin.com/ml/cygwin/2010-09/msg00225.html The short version is, running certain apps in the background triggers a bug in tty handling. Last I heard Corinna was having trouble diagnosing because the bug also kills strace :) No fix yet AFAIK. I was afraid of that. It just started happening for me after upgrading to cygwin 1.7, as well as to others in my company. One nice thing, at least, is it takes a very specific setup to trigger the bug. You may be able to get a usable workaround by changing how it's called (see the thread above for ideas). Hopefully we get a fix for this soon, though. Ryan -- 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
mintty window won't open
Hi all, I switched from rxvt to mintty yesterday, and it worked great all day. However, today when I try to open a new mintty window from within an existing one, nothing happens. The process starts, but no window appears. This happens when attempting to open both 0.8.3 and 0.9b2 windows from a 0.9b2 window. The broken window also does the same thing to tkdiff but is able to run xterm without problems. Oddly, using the shortcut from the start menu (0.8.3) still works, and any windows I fire up from it (including 0.9b2) work fine after that and can in turn fire up their own new instances. The broken windows are also permanently in alternate screen mode as far as mouse wheel goes (up/down arrow keys instead of scrolling the buffer) and their scrollbars are disabled even though they have many hundreds of lines of scrollback. Running strace on a broken mintty instance shows: 220 5944199 [main] mintty 2908 peek_windows: window 4(0x0) ready 61 5944260 [main] mintty 2908 select_stuff::wait: gotone 1 58 5944318 [main] mintty 2908 select_stuff::wait: returning 0 55 5944373 [main] mintty 2908 select_stuff::cleanup: calling cleanup routines 3577 5947950 [main] mintty 2908 set_bits: me 0x4B6630, testing fd 4 (/dev/windows) 115 5948065 [main] mintty 2908 set_bits: ready 1 165 5948230 [main] mintty 2908 select_stuff::poll: returning 1 88 5948318 [main] mintty 2908 select_stuff::cleanup: calling cleanup routines 151 5948469 [main] mintty 2908 select_stuff::~select_stuff: deleting select records 981 5949450 [main] mintty 2908 cygwin_select: 5, 0x22CA60, 0x0, 0x0, 0x0 226 5949676 [main] mintty 2908 dtable::select_read: /dev/ptmx fd 3 254 5949930 [main] mintty 2908 dtable::select_read: /dev/windows fd 4 175 5950105 [main] mintty 2908 cygwin_select: to NULL, ms 102 5950207 [main] mintty 2908 cygwin_select: sel.always_ready 0 332 5950539 [main] mintty 2908 select_stuff::wait: m 2, ms 4294967295 25103 5975642 [main] mintty 2908 select_stuff::wait: woke up. wait_ret 2. verifying The above is repeated slightly more often than once a second and is the same every time. I don't know if this is relevant. I'm running cygwin-1.7.7-1 with XP Pro SP3; mintty-0.8.3-1, and mintty-0.9b2 built manually from source. I've suspended and resumed my machine several times since those windows were opened, maybe this has something to do with it? Thanks, Ryan -- 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: mintty window won't open
Apologies if the below didn't actually arrive before... sent from the wrong email account. In any case, I found the problem: the terminal was running an ssh session to localhost. I have vague memories that ssh and native windows apps don't mix? Regards, Ryan On 9/28/2010 12:23 PM, Ryan Johnson wrote: Hi all, I switched from rxvt to mintty yesterday, and it worked great all day. However, today when I try to open a new mintty window from within an existing one, nothing happens. The process starts, but no window appears. This happens when attempting to open both 0.8.3 and 0.9b2 windows from a 0.9b2 window. The broken window also does the same thing to tkdiff but is able to run xterm without problems. Oddly, using the shortcut from the start menu (0.8.3) still works, and any windows I fire up from it (including 0.9b2) work fine after that and can in turn fire up their own new instances. The broken windows are also permanently in alternate screen mode as far as mouse wheel goes (up/down arrow keys instead of scrolling the buffer) and their scrollbars are disabled even though they have many hundreds of lines of scrollback. Running strace on a broken mintty instance shows: 220 5944199 [main] mintty 2908 peek_windows: window 4(0x0) ready 61 5944260 [main] mintty 2908 select_stuff::wait: gotone 1 58 5944318 [main] mintty 2908 select_stuff::wait: returning 0 55 5944373 [main] mintty 2908 select_stuff::cleanup: calling cleanup routines 3577 5947950 [main] mintty 2908 set_bits: me 0x4B6630, testing fd 4 (/dev/windows) 115 5948065 [main] mintty 2908 set_bits: ready 1 165 5948230 [main] mintty 2908 select_stuff::poll: returning 1 88 5948318 [main] mintty 2908 select_stuff::cleanup: calling cleanup routines 151 5948469 [main] mintty 2908 select_stuff::~select_stuff: deleting select records 981 5949450 [main] mintty 2908 cygwin_select: 5, 0x22CA60, 0x0, 0x0, 0x0 226 5949676 [main] mintty 2908 dtable::select_read: /dev/ptmx fd 3 254 5949930 [main] mintty 2908 dtable::select_read: /dev/windows fd 4 175 5950105 [main] mintty 2908 cygwin_select: to NULL, ms 102 5950207 [main] mintty 2908 cygwin_select: sel.always_ready 0 332 5950539 [main] mintty 2908 select_stuff::wait: m 2, ms 4294967295 25103 5975642 [main] mintty 2908 select_stuff::wait: woke up. wait_ret 2. verifying The above is repeated slightly more often than once a second and is the same every time. I don't know if this is relevant. I'm running cygwin-1.7.7-1 with XP Pro SP3; mintty-0.8.3-1, and mintty-0.9b2 built manually from source. I've suspended and resumed my machine several times since those windows were opened, maybe this has something to do with it? Thanks, Ryan -- 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] Testing: mintty-0.9b2-1
On 9/28/2010 2:05 PM, Andy Koppe wrote: On 27 September 2010 17:02, Ryan Johnson wrote: FYI, it looks like you can enable extended mouse mode manually (echo -ne '\e[?1005h'), and it persists across normal mouse mode sessions. Does xterm do that differently? In that case I should change it. I don't know. I submitted two patches, one of which resets extended mode every time the mouse mode changes. Thomas didn't tell me which one he ended up using. I didn't even know it was in xterm until I downloaded the mintty sources to try and hack them... and found the change already there with a comment about xterm-262. To be honest, I like your way better (see below), even though it technically could theoretically break some apps under some circumstances. This is handy because (a) emacs-23 can use it out of the box and Emacs has got support for that already? I'm positively surprised by that given the feature only went into xterm a month ago. (Well done for getting your patch into xterm, btw.) Not quite :) Emacs-23 treats all input as utf-8, so xterm's default mouse mode confuses it horribly by producing things that look like (in)valid utf-8. Any x-coordinate 95 looks like the start of a multi-byte sequence which consumes the y, and y coordinates 95 consume whatever character comes after the mouse click, hanging until such a character arrives. The worst part is that it's unpredictable whether emacs will get confused enough to just emit both characters, so there's no reliable way to reprocess the input to fix the problem (I tried...). If xterm emits utf-8, emacs-23 suddenly just works. Emacs-22 needs a small change to xt-mouse.el in order to convert the utf-8 sequences manually, but that's not hard at all if you know they're coming. I can't see a buffer wider than 223 columns being particularly useful, so I guess the main use is with split windows? Exactly. Also, the emacs-23 utf-8 broken-ness kicks in at 95 columns, which is a reasonable size even for one buffer. That's actually what prompted the patch -- stray mouse clicks tended to dump random strings like M#äé into my code at arbitrary places, leading to frequent compile errors. (b) it works around gnu screen intercepting and ignoring the escape sequence I suppose that's useful at sizes95 already then? Screen filters out the \e[?1005h sequence (and other unknown sequences, plus several known ones like the OSI sequences). This makes it impossible to activate extended mouse mode if, e.g., you run emacs inside screen. Screen also rewrites redundant sequences like \e[?1000h\e[?1000h to their minimal equivalent, so I couldn't even use a port knocking approach to get around it. However, mintty lets you activate ext mouse mode before attaching screen, which works nicely around the problem. Given that screen's last release was about 4 years ago, this seems like a Good Thing to me... (Ironically, I think it was some old version of screen which did the utf-8 encoding trick years ago and inspired my patch. I have a six year old .emacs from an hpux machine which had reverse-engineered the encoding without even knowing it was utf-8). Regards, Ryan -- 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: gitk kills bash shell
Jeremy Ramer said: I have a very repeatable issue, but I'm not sure how to go about debugging it. I follow this process. 1) Start an rxvt bash shell 2) Go to a git repo folder 3) Start gitk gitk --all 4) Go back to bash and press any key except enter and bash closes I also get a similar problem with this process: 1) Start an rxvt bash shell 2) Go to a git repo folder 3) Start gitk gitk --all 4) Close gitk with the close button. Both gitk and bash close. Note that the issue does not happen if I don't start gitk as a background process. But then I can't use the shell. Any debugging tips? This sounds suspiciously similar to a problem that hit me a while back: http://www.cygwin.com/ml/cygwin/2010-09/msg00225.html The short version is, running certain apps in the background triggers a bug in tty handling. Last I heard Corinna was having trouble diagnosing because the bug also kills strace :) No fix yet AFAIK. Regards, Ryan -- 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] Testing: mintty-0.9b2-1
On 8:59 PM, Andy Koppe wrote: mintty 0.9b2-1 is on its way to the Cygwin mirrors. This is a test release. a .zip can be downloaded from http://mintty.googlecode.com. FWIW, I've been using a home-built mintty-0.9b2 from googlecode all day with no problems (loving extended mouse mode!). I swear I just checked setup.exe two hours ago, but I'll check again and switch to official one when I get a chance. FYI, it looks like you can enable extended mouse mode manually (echo -ne '\e[?1005h'), and it persists across normal mouse mode sessions. This is handy because (a) emacs-23 can use it out of the box and (b) it works around gnu screen intercepting and ignoring the escape sequence Xterm compatibility: - 'Extended Mouse Mode' as introduced in xterm #262 is now supported. This allows row/column positions greater than 255 (and up to 2015) to be reported, in case you do get that 30'' monitor ... Woohoo! Regards, Ryan -- 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: openssh port forwarding administratively prohibited
On 8:59 PM, Maring, Steven wrote: From a 50K foot perspective, what I'm trying to do is punch a hole through my corporate http proxy to get to github. By itself, cygwin, along with openssh and corkscrew, does not have a problem (i.e. remote git commands work). However, I would also like to make use of the eGit Eclipse plugin, which unfortunately does not support the notion of a proxy. So, I thought that if I could setup a local port forwarding I might be able to get eGit to connect ... but it isn't working.I've included the openssh, git, and corkscrew packages in my cygwin install. I then ran ssh-host-config, but I didn't think actually running the sshd via 'net start sshd' would be required. The port forwarding does not seem to work either way. snip $ ssh -L 22:github.com:22 -v -N g...@github.com snip and then try to connect from another console like this ... $ ssh -v -N g...@localhost snip then my tunnel says ... debug1: Connection to port 22 forwarding to github.com port 22 requested. debug1: channel 1: new [direct-tcpip] channel 1: open failed: administratively prohibited: open failed debug1: channel 1: free: direct-tcpip: listening port 22 for github.com port 22, connect from 127.0.0.1 port 1130, nchannels 2 This sounds like a vanilla ssh issue to me rather than anything cygwin-specific. Several things come to mind right off. First, I've seen the administratively prohibited message when there was no port forwarding in place at all. Not the most intuitive message, but whatever... Second, it's often difficult to forward to privileged ports ( 1024), though that wasn't a problem when I tested it on my cygwin install. Finally (and probably the real issue) ssh-host-config sets things up for (and starts) the sshd service, which means port 22 on your machine is already in use and the port forwarding comes up empty-handed. Try net stop sshd, or else tell ssh -L :github.com:22 and see if that gets you anywhere (I don't use git but I assume there's a way to point it at ports besides the default 22). Note that connecting this way will mess up the known_hosts file and make ssh yell at you if you ever happen to ssh to localhost (or to any other machine tunneled to localhost). I think there are ways around this with aliases or something... man ssh_config? Regards, Ryan -- 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
TCL exec kills its owning tty (was: Unable to initialize fd 0 for /dev/tty1)
On 9/6/2010 11:34 PM, Ryan Johnson wrote: The last couple days I've gotten some really strange errors. Sometimes I'll alt-tab to an xterm window and start typing, only to have it disappear at the first keystroke. Sometimes `emacs -nw' will get hit instead, leaving both emacs and the xterm pretty much unusable. I haven't been able to get a stack trace I can reproduce this bug reliably with both 1.7.7 and 1.7.6 versions of cygwin1.dll (which makes me suspect the problem is not there). The reason I couldn't get a stack trace is because the xterm doesn't receive an error... it just gets an EOF and dutifully exits. Sometimes you can see 'exit' appear just before the window closes. After some digging, it looks like TCL is the culprit (recall I was running tkdiff). Here's a minimal test case, which will close its controlling tty when it exits: $ echo 'exec ls' tty-killer; tclsh tty-killer Running the script in the foreground, passing it as a -c argument to bash, or piping it into tclsh, does *not* expose the bug. Ideas? Ryan -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 Hmm.. I don't get seg faults while resizing, but every once in a while I'll alt-tab to an xterm and start typing, only to have the xterm evaporate. Once it also happened to emacs, which left both emacs and the terminal pretty well unusable. Unfortunately, I don't get a stack trace or any messages in /var/log/XWin.*.log. It just goes away. I'd never seen this behavior with 1.8.2-0 (or earlier), so I'm rolling back to it. I'll holler if the problem continues. Ideas? Ryan -- 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/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 9/6/2010 11:01 PM, Ryan Johnson wrote: On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 Hmm.. I don't get seg faults while resizing, but every once in a while I'll alt-tab to an xterm and start typing, only to have the xterm evaporate. Once it also happened to emacs, which left both emacs and the terminal pretty well unusable. Unfortunately, I don't get a stack trace or any messages in /var/log/XWin.*.log. It just goes away. I'd never seen this behavior with 1.8.2-0 (or earlier), so I'm rolling back to it. I'll holler if the problem continues. Oops. It just happened for 1.8.2-0 and for diff.exe. I've posted the issue to the cygwin mailing list because it doesn't seem x-related if diff.exe dies... Ryan -- 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/
Re: Unable to initialize fd 0 for /dev/tty1
On 9/6/2010 11:45 PM, Eric Berge wrote: Ryan Johnson wrote: The last couple days I've gotten some really strange errors. Sometimes I'll alt-tab to an xterm window and start typing, only to have it disappear at the first keystroke. Sometimes `emacs -nw' will get hit instead, leaving both emacs and the xterm pretty much unusable. I saw these errors with cygwin 1.7.5 but they were fixed when I went to 1.7.6. If you're on 1.7.5 you might want to try upgrading. I'm on 1.7.7-19. Ryan -- 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: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 So far so good... I've switched monitors several times without problems (both with -resize and without). Thanks! Ryan -- 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/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/31/2010 7:00 PM, Jon TURNEY wrote: Okay, I think I have worked out the correct thing to do do to handle bpp changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps you could try it and see if it works for you? Note that you will need to use -resize with this build to turn on RANDR in any mode. If you can make this crash, with or without -resize, a backtrace would be very helpful. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 I'll give that a try in the next couple of days. Meanwhile, what kind of backtrace did you mean? Is the .exe.stackdump actually helpful? Ryan -- 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/
Re: xwin -multiwindow puts glass pane over windows taskbar
On 8/31/2010 7:06 PM, Jon TURNEY wrote: On 16/08/2010 11:57, Ryan Johnson wrote: The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? I don't see any behaviour like that, and I can't really visualize what you are describing. Can you upload some screenshots somewhere? Facts which might be relevant: - do you have the taskbar set to autohide? - what version of Windows are you using? - is this the same problem as you mentioned at [1]? [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00011.html Sorry my description was so vague. It is indeed the same problem as in [1] (I thought maybe the other had gotten lost in the shuffle and reposted it). Basically, you know how the previous bug would make X apps unresponsive to key presses and mouse events until you did an alt-tab to wake them? Now I never get that any more but I get virtually the same behavior with my XP Pro non-autohide task bar, which is docked on the left side of my screen. If I mouse over systray icons, the tooltips don't appear. Mousing over the window entries doesn't make them highlight. Clicking on a window's entry or the 'start' button does nothing. It really is like something invisible sits over the whole area and intercepts all mouse events. The behavior continues for around 5 seconds or until I alt-tab some other window to foreground (whichever comes first). This doesn't always happen, and it only happens when an X window is in the foreground. Ryan -- 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/
Re: Re: X-forwarding very very slow
On 8:59 PM, Jeremy Bopp wrote: On 8/18/2010 11:55 AM, Csaba Raduly wrote: On Wed, Aug 18, 2010 at 5:43 PM, Alberto Canestrelli wrote: Hi, I have a problem with Cygwin. I am connecting from USA by ssh to the Hector supermachine in Edinburgh ( I write startx in Cygwin and then I use ssh -Y v1aca...@login.hector.ac.uk ). Everything works fine, the only problem is that the forwarding of the windows is very very slow. Hi Alberto, It would be useful if you could try a non-Cygwin X server (e.g. a Linux or Solaris workstation). If X from under Linux appears fast, then the slowdown could be between your network card and display (probably Cygwin's fault). If X from Linux is also slow, the problem may be with the propagation of the X protocol between your network card and Hector (probably not Cygwin's fault) . You could also try enabling compression with -C. I have found this to be a necessity when connecting with X over ssh between work and home even though the locations are quite near each other and plain text based ssh access runs fine without the compression. In my experience, any off-campus access to X is best done via VNC or rdesktop (both over a compressed ssh tunnel). Triply so if you're crossing an ocean. The protocol simply was not designed with slow or laggy networks in mind, from what I can tell. There are faster X-servers for windows, but not free, and I haven't noticed that they reduce the amount of protocol chatter much, especially for the unbearably slow process of opening a new window. Regards, Ryan -- 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: Missing dependency for Athena libraries
On 8:59 PM, Andy Koppe wrote: On 14 August 2010 12:57, Ryan Johnson wrote: I just tried to pull down the Athena widget libraries (xaw and xaw3d) and got an unmet dependency message for libXpm-devel. It's not a big deal, since it offered to add it to my list, but a bit odd (I just clicked on each once... none of the cycling though install/keep/reinstall/etc which might have confused something). That's the new normal, following a change to setup.exe. Previously, dependencies would have been added instantly when you selected a package. The problem with that was that those dependencies weren't deselected if you changed your mind about a package. Also, it got in the way when you cycled through the package actions to get to 'Uninstall', and sometimes people were surprised about the number of packages being quietly pulled in by their selections. Therefore now the dependencies being added automatically are always listed on the 'Resolve Dependencies' page. Seems the wording on that page still needs some fine-tuning though. I presume it was the 'Unmet Dependencies Found' line that made you think there's a problem? Ah, OK. That seems fine -- I only worried because in the past that message meant something was wonky. Ryan -- 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/
xwin -multiwindow puts glass pane over windows taskbar
Hi all, The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? Ryan -- 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/
Missing dependency for Athena libraries
Hi all, I just tried to pull down the Athena widget libraries (xaw and xaw3d) and got an unmet dependency message for libXpm-devel. It's not a big deal, since it offered to add it to my list, but a bit odd (I just clicked on each once... none of the cycling though install/keep/reinstall/etc which might have confused something). Regards, Ryan -- 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/
libncurses-devel-5.7-18 doesn't create /usr/include/curses.h
Hi all, Getting compile errors about curses.h not found, and sure enough, it's not in /usr/include. After reinstalling libncurses-devel (I already had it), the problem didn't go away so I looked in the postinstall script. The comment at the top says: # This script will create symbolic links in the toplevel include # directory, pointing to files 'hidden' in the ncurses subdirectory. But I can't find anywhere in the script which actually does this for the .h files. Is this change intentional? Ryan -- 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: xterm and 7-bit control codes
On 8:59 PM, Thomas Dickey wrote: As far as I know, xterm's never sent more than one byte for either x/y in a button event. Ditto for rxvt. It sounds like a useful idea, except that it would of course be incompatible with the existing applications. So it would have to be enabled by a new control sequence. Hehe... very true about breaking existing apps. All those years ago the extra octet kick-started everything by confusing emacs (well, xterm-mouse-mode, really). I started looking at the character stream and reverse-engineered the above formula while trying to get rid of all the ascii garbage that polluted my buffers after stray mouse clicks. Only then did I realize I could exploit (rather than suppress) the extra octets to make large terminals behave better... (On the other hand, whatever application you were using at the time may have translated the characters in that manner). I dug up an old .emacs, and it actually mentions gnu screen. If so, that's definitely been fixed because I specifically tested screen on several machines (cygwin, solaris, linux), plus rxvt and the gnome terminal***) before posting here. Any ideas what other terminal emulators I might test? Side note: how much pain would it be asking for if I tried to add the double-octet behavior to xterm as a feature? Would it be better to tackle rxvt? Or would it be man-weeks of work no matter what and I should just drop it? Thanks, Ryan *** testing gnome terminal was hilarious: enabling mouse support and clicking on the wrong position sends a control sequence containing ^Z, which duly backgrounds the app! -- 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/
Change to gnuplot's handling of ^Z and ^C
Hi all, Recenty I noticed that gnuplot no longer responds instantly to control characters. You have to hit an additional key before they take effect. So, for example, if I type ^Zdfg\n I get the following: gnuplot ^Z [1]+ Stopped(SIGTSTP)gnuplot [r...@scovich] ~/experiments $ fg gnuplot d Notice that gnuplot, not bash, got the 'd'... I've also managed to close my terminal on accident once or twice, but I don't know what exact key sequence did it (it may have had something to do with ^S enabling flow control instead of starting a search in emacs, because the latter failed to come to fg when gnuplot slurped up the 'f'). Maybe it's some strange interaction between bash's readline and gnuplot's? The shell isn't affected, nor are non-readline utilities like cat and emacs. Thoughts? Ryan -- 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
xterm and 7-bit control codes
Hi all, I'm running into a strange one... At some point in the past (on linux because I didn't know about cygwin yet), xterm used to send the following control sequence for a mouse click at row 1, col 250 ESC [ M SPC \303\206 ! ESC [ M # \303\206 ! From what I could piece together, the formula for the x position was: \40+x (x 96) \300+X/64 \200+X%64 (otherwise) In other words, the first 96 characters were encoded as single octets, with all later ones encoded as an octet pair. I recently got back to using a wide monitor for the first time in years, and discovered that my hacks to emacs' xterm-mouse-mode no longer worked well because the two-octet code has been replaced by zero: ESC [ M SPC \000 ! ESC [ M # \000 ! This makes it hard to use the mouse on the right side of a large terminal window... I've verified that it's not emacs doing this (nor bash) by running directly (xterm -e) a small C utility which sends the mouse activation sequence and then converts stdin to an octet stream. Mouse clicks arrive just as emacs reported. Am I smoking something or has something about this control sequence changed in the last 5-6 years? I wonder if it has something to do with UTF-8 handling and if X changed somehow... The xfree86 control sequence documentation is less than helpful here [1]. For normal tracking mode it says: On button press or release, xterm sends CSI M C b C x C y . The low two bits of C b encode button information: 0=MB1 pressed, 1=MB2 pressed, 2=MB3 pressed, 3=release. The next three bits encode the modifiers which were down when the button was pressed and are added together: 4=Shift, 8=Meta, 16=Control. Note however that the shift and control bits are normally unavailable because xterm uses the control modifier with mouse for popup menus, and the shift modifier is used in the default translations for button events. The Meta modifier recognized by xterm is the mod1 mask, and is not necessarily the Meta key (see xmodmap). C x and C y are the x and y coordinates of the mouse event, encoded as in X10 mode. In X10 mode: On button press, xterm sends CSI M C b C x C y (6 characters). C b is button−1. C x and C y are the x and y coordinates of the mouse when the button was pressed. I remember reading the same thing all those years ago and being annoyed even then because it was so vague. Clearly the terminal was sending more than 6 octets (who knows how many characters that's supposed to be), and the spec doesn't mention the fact that all coordinates are offset by \40. How UTF-8, Unicode, and other encoding complexities fit in I have no clue... This may turn out to have nothing to do with cygwin/X; if so I'd appreciate ideas on where to send it next... Ideas? Ryan [1] http://www.xfree86.org/current/ctlseqs.html#Mouse%20Tracking -- 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/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/12/2010 5:46 PM, Jon TURNEY wrote: On 10/08/2010 06:48, Ryan Johnson wrote: On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. Oh dear. Well it seems I only thought I added code to only enable resize support in multiwindow mode when requested, so it's always on for multiwindow mode at the moment. That wouldn't be so bad, but it also seems that the -resize code completely fails to correctly handle a change of colour depth (e.g. from 32 bits to 16 bits or vice versa) leading to this segfault. Unfortunately, fixing this looks to be quite complex :-( Thanks for testing, anyhow :-) So... does that mean I have to roll back or face a seg fault after every commute? Or is there a way to explicitly disable it? Ryan -- 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/
Re: Re: Missing charsets in String to FontSet conversion
On 8:59 PM, Jon TURNEY wrote: On 03/08/2010 16:21, Ryan Johnson wrote: As I mentioned before, I'd seen references to those fonts but wasn't sure it would actually help me. I just installed them and, sure enough, there's still some (fewer?) missing charsets. The delay dropped to only 2-3 seconds now though, so I guess that helps. Is there a way to diagnose which fonts/charsets are still missing? Hmm. You could write a small test application which calls XCreateFontSet() with the base font of * and reports the list of missing charsets returned. It also seems that twm reports these problems in a slightly more useful fashion than libXt (saying font for charset charset is lacking), so running that (against an X server not started in multiwindow mode) might serve just as well. Hi Jon, Fortunately (for me, not for the bug hunt) I picked up the newer version of xterm at some point, which set the menu locale to C and ended the problems. Thanks, Ryan -- 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/
Re: SIGSEGV in xorg-1.8.2.0 during -resize operation
On 8/10/2010 12:02 AM, Jon TURNEY wrote: On 09/08/2010 22:14, Ryan Johnson wrote: I was overjoyed to see that the release notes for the new X server release mention support for resizing the X desktop with the windows desktop. Unfortunately, it didn't work :( I modified the xwin windows shortcut to run as follows: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize You need to quote the entire command you are passing to bash after -c i.e, try C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -resize Then started the server at 1920x1200x32bpp while my ThinkPad was attached to an external LCD. When I detached the monitor to leave the office, X disappeared with signal 11 (log attached). Oddly, the log file didn't mention -resize as an argument to XWin, but it did attempt to resize so I assume the feature was active. There have been some reports of the X server segfaulting when the resolution changed, prior the addition of -resize support. This is something which also needs to be fixed. Huh. So it wasn't trying to resize at all, and just seg faulted due to existing badness? Thanks for the heads-up about quoting... that also explains why my attempts to set the resolution weren't working... Ryan -- 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/
Re: Missing charsets in String to FontSet conversion
On 8/3/2010 3:35 PM, Jon TURNEY wrote: On 03/08/2010 10:00, Thomas Dickey wrote: On Tue, 3 Aug 2010, Ryan Johnson wrote: At some point an annoyance appeared with my xterm windows: The first time I use [ctrl]+mouse click in any window, that xterm becomes unresponsive for about 5 seconds with the CPU pegged to 100%. After the five seconds is up, whatever shell spawned the xterm receives the following message: Warning: Missing charsets in String to FontSet conversion After that all works normally (until I open the next xterm window). Is there a way to diagnose what the problem is? I don't know what FontSet string the error even refers to, let alone which parts of that string were invalid. In any case, it really shouldn't take five seconds of hard CPU crunching to detect and report an invalid input string. There's some more discussion at http://sourceware.org/bugzilla/show_bug.cgi?id=10948 Installing the fonts font-isas-misc, font-jis-misc and font-daewoo-misc should also work around the problem, which can also be seen with other applications, as that ensures that at least one font exists for every charset. I agree that the error message sucks and should tell you the charsets which are missing and what string it was attempting to convert. This topic came up last year, iirc the issue was this: http://invisible-island.net/xterm/xterm.faq.html#slow_menus The xterm FAQ's workaround (setting LANG=C) indeed works, but then I lose all of UTF-8, including some of the punctuation marks man pages and gcc errors like to use. As I mentioned before, I'd seen references to those fonts but wasn't sure it would actually help me. I just installed them and, sure enough, there's still some (fewer?) missing charsets. The delay dropped to only 2-3 seconds now though, so I guess that helps. Is there a way to diagnose which fonts/charsets are still missing? Regards, Ryan -- 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/
Re: Re: Slow response to keypresses in xorg-server-1.8.0-1
On 8:59 PM, Jon TURNEY wrote: I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 I just downloaded this version, and it indeed fixes the slow [alt]-[tab] behavior, but I'm still having one problem: the invisible xterm root window covers my windows taskbar until I've moused over it for several seconds (or alt-tab somewhere else first). Ideas? Ryan -- 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/
Re: RE: startxwin/XWin won't start properly
What Mike and I want is actually pretty reasonable. We want to be able to preserve the work we do in picking the wheat from the chaff (from our point of view) to avoid having our coworkers or ourselves duplicate that work, whether they understand Unix or not (I'm sorry I brought it up! It is largely irrelevant.). It seems simple--at some point the Setup program knows what was selected. It just needs to save it out and be able to read it back in. vote +1 I've also had this need many times. Most recently, the update to the latest cygwin dll, which the instructions specifically said should be a clean install rather than an in-place upgrade. Migration wizard would have been nice... Ryan -- 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/
Re: startx doesn't run proprely
On 8:59 PM, hakob...@ualberta.ca wrote: Dear Cygwin helper, After the startx command it doesn't open X terminal. In fact, it sometimes open Xterm sometimes not, givin the following error message: snip _XSERVTransMakeAlloCOTSServerListeners: server already running snip Please, tell me what to do to get rid of the problem? The above looks like a likely culprit. Make sure the last instance is really gone before starting a new one. Closing xterm doesn't shut down the server, and if you just want a new xterm use the Cygwin-X shortcuts or right click the 'X' in the system tray and find it in the 'Applications' list of the menu that pops up. Good luck, Ryan -- 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/
Re: Can't alt-tab to Xterm window
On 8:59 PM, Craig Moore wrote: If I switch away from my xterm window (alt-tab), and then try to switch back, nothing happens. I have to right-click on the title of the window in the taskbar, which usually activates the window and brings it to the font. It happens pretty consistently so I was wondering if anyone knew how to fix this? This is a fairly well-known (but still undiagnosed?) bug in the 1.8 server. Workaround is to roll back to the previous 1.7 series. You can see a discussion about it in the list archives with the subject Slow response to keypresses in xorg-server-1.8.0-1 Regards, Ryan -- 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/
Re: Re: Slow response to keypresses in xorg-server-1.8.0-1
On 8:59 PM, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig ' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Is there any progress on this? I'm also seeing these symptoms after upgrading to 1.8. Very annoying. Thanks, Ryan -- 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/
Tee broken under process substitution?
Hi all, It appears that 'tee' can't handle process substitution as its target file. It works fine on my Solaris machine at work, and the coreutils info pages explicitly say it should work: solaris$ echo hi | tee (cat) hi hi cygwin$ echo hi | tee (cat) hi tee: /dev/fd/63: Bad file descriptor Does anyone have any ideas or workarounds? Unfortunately google tends to ignore three-letter words, so I couldn't determine if this has been reported/solved before... Thanks, Ryan -- 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
X11 + remote desktop + clipboard = hang
Hi all, I noticed today that trying to cut and paste between an xterm and a remote desktop session causes the remote desktop to hang with a CPU pegged. I have vague memories of this sort of thing happening before (but with a VNC client causing the problem instead of rdtsc.exe). The fix then was to install Jon Turney's hacked version of xwin.exe [1], but that binary targeted v1.5 and I'm running v1.7 now... Thoughts? Ryan [1] http://www.cygwin.com/ml/cygwin-xfree/2009-02/msg00276.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: Re: 1.5.25-15: pthread_join deadlocks
Corinna Vinschen wrote: On Nov 19 12:29, Ryan Johnson wrote: Hi all, I'm hitting a deadlock with cygwin pthreads when joining on a short-lived thread -- for me the second such thread creation will almost never return. It looks *exactly* like a problem that others noticed as far back as early 2005 [0], and from the output of strace on the test case (below) the culprit is almost certainly a racy optimization in __cygwin_lock_* for which a patch was submitted six months ago [1]. As of today my cygwin distribution is completely up to date. Any hope of an update coming out soon? The update will be Cygwin 1.7. You testcase works fine for me on Cygwin 1.7, so maybe you should try this path. See http://cygwin.com/#beta-test Ah, that's good to know. I'll try it out when I get a few minutes. Meanwhile, firing up an extra thread at program start, and having it just block on a cond var nobody will ever signal, seems to avoid the problem completely. Out of curiosity, how much did removing the racy optimization hurt performance? The patch just yanked it completely iirc. An alternative might be to have the main thread check for single-thread environment only at acquire time, and then release only if it acquired (the latter is probably a good idea regardles...). Thanks, Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.5.25-15: pthread_join deadlocks
Hi all,
I'm hitting a deadlock with cygwin pthreads when joining on a
short-lived thread -- for me the second such thread creation will almost
never return. It looks *exactly* like a problem that others noticed as
far back as early 2005 [0], and from the output of strace on the test
case (below) the culprit is almost certainly a racy optimization in
__cygwin_lock_* for which a patch was submitted six months ago [1].
As of today my cygwin distribution is completely up to date. Any hope of
an update coming out soon?
Regards,
Ryan
[0]
http://coding.derkeiler.com/Archive/General/comp.programming/2005-02/0786.html
[1] http://www.mail-archive.com/cygwin-patc...@cygwin.com/msg04323.html
$ cat bug.cpp
#include pthread.h
#include cassert
#include cstdio
#define ANNOUNCE(what) fprintf(stderr, what \n)
extern C void* run(void*) {
ANNOUNCE(Running);
return 0;
}
int main() {
pthread_t tid;
ANNOUNCE(Starting);
for(int i=0; i 10; i++) {
ANNOUNCE(Creating thread);
assert(0 == pthread_create(tid, 0, run, 0));
ANNOUNCE(Joining thread);
assert(0 == pthread_join(tid, 0));
}
ANNOUNCE(Done);
}
$ g++ -Wall -g -mthreads bug.cpp strace
--mask=all+thread+paranoid+debug+uhoh ./a.exe
**
Program name: C:\cygwin\home\Ryan\experiments\a.exe (pid 2860, ppid 1)
App version: 1005.25, api: 0.156
DLL version: 1005.25, api: 0.156
DLL build:2008-06-12 19:34
OS version: Windows NT-5.1
Heap size:402653184
Date/Time:2009-11-19 11:58:33
**
48 32123 [main] a 2860 __cygwin_lock_lock: threadcount 1. not locking
24 32147 [main] a 2860 __cygwin_lock_unlock: threadcount 1. not
unlocking
25 32172 [main] a 2860 __cygwin_lock_lock: threadcount 1. not locking
Starting
24 33868 [main] a 2860 __cygwin_lock_unlock: threadcount 1. not
unlocking
23 33891 [main] a 2860 __cygwin_lock_lock: threadcount 1. not locking
Creating thread
23 34109 [main] a 2860 __cygwin_lock_unlock: threadcount 1. not
unlocking
260 34369 [unknown (0x1C8C)] a 2860 pthread::thread_init_wrapper:
started thread 0x100428B0 0xD8D008 0x61102D90 0x100428B0 0x401145 0x0
33 34402 [unknown (0x1C8C)] a 2860 __cygwin_lock_lock: threadcount
2. locking
39 34561 [main] a 2860 __cygwin_lock_lock: threadcount 2. locking
Running
91 34860 [unknown (0x1C8C)] a 2860 __cygwin_lock_unlock:
threadcount 2. unlocked
* Child thread exits here *
Joining thread
* Main thread decides it doesn't need to release the lock *
22 35166 [main] a 2860 __cygwin_lock_unlock: threadcount 1. not
unlocking
56 35222 [main] a 2860 __cygwin_lock_lock: threadcount 1. not locking
Creating thread
24 36990 [main] a 2860 __cygwin_lock_unlock: threadcount 1. not
unlocking
156 37146 [unknown (0x10B8)] a 2860 pthread::thread_init_wrapper:
started thread 0x100428B0 0xD8D008 0x61102D90 0x100428B0 0x401145 0x0
29 37175 [unknown (0x10B8)] a 2860 __cygwin_lock_lock: threadcount
2. locking
* Second child thread now blocked the lock which main thread holds *
25 37200 [main] a 2860 __cygwin_lock_lock: threadcount 2. locking
Joining thread
* Apparently recursive lock acquires work? *
25 38604 [main] a 2860 __cygwin_lock_unlock: threadcount 2. unlocked
* Unfortunately main still holds the lock and is now joined on the
child it blocks *
--
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
Unexpected unmet dependencies with installer
Hi all, I just tried to download the 'screen' package through Cygwin's setup.exe, and set the mode to 'Keep' to avoid pulling down the umpteen updated packages it found. Then I selected 'screen' from the list. However, when I tried to complete the install I got warnings about jasper, libglut3, libImageMagick1, and others having unmet dependencies on libGL1, libX11_6, libXt6, etc. Every packages listed is one the installer wanted to upgrade, and none seem related to screen in any way (they being image libraries and it being a terminal program); is it possible that Setup didn't clear the dependency list properly when I selected 'Keep' mode? Or is Setup's dire warning about my installation not functioning properly if I continue likely to be true? I tried searching the mailing list archives with no luck, so hopefully this hasn't been beaten to death previously. Thanks, Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin/X + Solaris = no function keys
Hi, I use the latest version of cygwin/X (updated yesterday) to connect to a Solaris 10 box. Certain keys like page up and page down don't work for any programs besides xemacs, but when I run SunStudio 11 (a Java app) I lose everyting except alphanumerics and punctuation. This makes it virtually impossible to use the program. I've narrowed the problem down to trusted X connections: given hosts cygwin.box and solaris.box, the bug appears if you use a direct connection: cygwin.box $ xhost solaris.box solaris.box $ DISPLAY=cygwin.box:0.0 sunstudio or a trusted X connection over ssh: cygwin.box $ ssh -fY solaris.box sunstudio Using an untrusted connection instead fixes the problem, but I give up all clipboard integration (which requires -Y): cygwin.box $ ssh -fX solaris.box sunstudio *sigh* at least trying to use the clipboard in Java doesn't make it crash with a BadAtom error like all the x-apps do. Has anyone else seen this issue? It seems similar to a couple of messages about eclipse from April 2005, but those had no resolution. Thanks, Ryan Johnson -- 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/
