[ANNOUNCEMENT] Updated: mesa-10.5.6-1
The following packages have been updated in the Cygwin distribution: * dri-drivers-10.5.6-1 * libEGL1-10.5.6-1 * libEGL-devel-10.5.6-1 * libGL1-10.5.6-1 * libGL-devel-10.5.6-1 * libGLESv2_2-10.5.6-1 * libGLESv2-devel-10.5.6-1 * libglapi0-10.5.6-1 * libOSMesa8-10.5.6-1 * libOSMesa-devel-10.5.6-1 * windowsdriproto-10.5.6-1 Mesa is an open-source implementation of the OpenGL, EGL, and OpenGL ES specifications for rendering interactive 3D graphics. This is an update to the latest upstream release. Complete documentation on OpenGL usage and configuration can be found here: http://x.cygwin.com/docs/ug/using-aiglx.html -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: llvm/clang-3.5.2-1
The following packages have been updated in the Cygwin distribution: * llvm-3.5.2-1 * llvm-doc-3.5.2-1 * libllvm3.5-3.5.2-1 * libllvm-devel-3.5.2-1 * libllvm-devel-static-3.5.2-1 * clang-3.5.2-1 * clang-analyzer-3.5.2-1 * libclang-3.5.2-1 * libclang-devel-3.5.2-1 * libclang-devel-static-3.5.2-1 * python-clang-3.5.2-1 * python3-clang-3.5.2-1 The LLVM suite provides libraries and tools for code generation and optimization. Also included is Clang, an LLVM native C/C++/ObjC compiler, and the Clang Static Analyzer, a tool that automatically finds bugs in code. This is the latest upstream release in the 3.5 stable branch. -- Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
FW: fata signla received in thread
From: Julie Ann Connary (jconnary) Sent: Tuesday, May 26, 2015 6:13 PM To: 'cygwin@cygwin.com'; 'support@mobatek.net' Subject: fata signla received in thread Hi, I just reinstalled with the latest Cygwin but continue to get the following error when running my X11 wireshark application in mobaxterm out of a linux VM running in VBOX. How do I resolve this? [jconnary.JCONNARY-WS01] ➤ more XWin.0.log Welcome to the XWin X Server Vendor: Moba/X Release: 1.16.3.0 OS: CYGWIN_NT-6.1-WOW JCONNARY-WS01 1.7.34(0.285/5/3) 2015-02-04 20:59 i686 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version built 2015-03-17 XWin was started with the following command line: /bin/XWin_1.16.3 -silent-dup-error -notrayicon -nolisten inet6 -hostintitle +bs -clipboard -ac -screen 0 @1 -mwextwm -noreset -fp /usr/share/fonts/misc,/usr/share/fonts/75dpi,/usr/share/fonts/100dpi,/usr/share/fonts/Speedo,/usr/share/fonts/OTF,/usr/share/fonts/TTF,/usr/share/fonts/cyrillic,/usr/share/fonts/Type1 :0 ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1680 h 1050 winInitializeScreenDefaults - native DPI x 96 y 96 winInitializeScreens - 1 winInitializeScreen - 0 ddxProcessArgument - screen - Found Valid ``@Monitor'' = 1 arg [ 2574.796] (II) xorg.conf is not supported [ 2574.796] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 2574.796] (++) FontPath set to "/usr/share/fonts/misc,/usr/share/fonts/75dpi,/usr/share/fonts/100dpi,/usr/share/fonts/Speedo,/usr/share/fonts/OTF,/usr/share/fonts/TTF,/usr/share/fonts/cyrillic,/usr/share/fonts/Type1" [ 2574.796] LoadPreferences: /home/mobaxterm/.XWinrc not found [ 2574.796] LoadPreferences: /etc/X11/system.XWinrc not found [ 2574.796] LoadPreferences: See "man XWinrc" to customize the XWin menu. [ 2574.796] LoadPreferences: Loading built-in default [ 2574.796] (II) Detecting supported engines... [ 2574.843] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 2574.843] winDetectSupportedEngines - Returning, supported engines 0015 [ 2574.843] (II) Loading libraries for taskbar grouping... [ 2574.843] (II) Storing the instance handle... [ 2574.843] (II) Creating the messaging window... [ 2574.843] (II) winCreateMsgWindow - Initializing the thread for the messaging window... [ 2574.843] (II) winCreateMsgWindow - Creating the thread for the messaging window... [ 2574.843] [ 2574.843] (II) winMsgWindowThreadProc - Creating Message window... (II) winCreateMsgWindow - pthread_create succeeded. [ 2574.843] (II) Initializing each screen... [ 2574.843] (II) Initializing screen 0... [ 2574.843] Starting winScreenInit - dwWidth: 1680 dwHeight: 1050... [ 2574.843] Starting winSetEngine... [ 2574.843] winSetEngine - Multi Window or Rootless => ShadowGDI [ 2574.843] winScreenInit - Using Windows display depth of 32 bits per pixel [ 2574.858] (II) winMsgWindowThreadProc - Created Message window successfully. [ 2574.858] winAllocateFBShadowGDI - Creating DIB with width: 3600 height: 1080 depth: 32 [ 2574.858] winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 2574.858] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [ 2574.858] (II) --> SUCCESS! [ 2574.858] MIT-SHM extension disabled due to lack of kernel support [ 2574.858] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 2574.874] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' [ 2574.874] (II) AIGLX: Testing pixelFormatIndex 1 [ 2574.983] GL_VERSION: 4.0.0 - Build 9.17.10.2843 [ 2574.983] GL_VENDOR: Intel [ 2574.983] GL_RENDERER: Intel(R) HD Graphics 4000 [ 2574.983] (II) AIGLX: enabled GLX_SGI_make_current_read [ 2574.983] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 2574.983] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [ 2574.983] (II) AIGLX: enabled GLX_SGIX_pbuffer [ 2574.983] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample [ 2574.983] (II) 66 pixel formats reported by wglGetPixelFormatAttribivARB [ 2574.983] (II) AIGLX: Set GLX version to 1.4 [ 2574.983] (II) 21 fbConfigs [ 2574.983] (II) ignored pixel formats: 0 not OpenGL, 6 RBGA float, 3 RGBA unsigned float, 0 unknown pixel type, 36 unaccelerated [ 2574.983] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [ 2575.529] winPointerWarpCursor - Discarding first warp: 1800 540 [ 2575.529] (--) 16 mouse buttons found [ 2575.529] (--) Setting autorepeat to delay=500, rate=31 [ 2575.529] (--) Windows keyboard layout: "0409" (0409) "US", type 4 [ 2575.529] (--) Found matching XKB configuration "English (USA)" [ 2575.529] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 2575.529] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 2575.545] winProcEstablishConnection - wi
Re: Doing vfork: resource temporarily unavailable
Rockefeller, Harry writes: > Instructions above state running setup-x86.exe not setup-x86_64.exe. > Does anyone experience frequent emacs vfork errors running 64-bit Cygwin? > Maybe it's time for me to try running that again? DLL collisions are _much_ less likely on x86_64 out of the gate, but they do occur from time to time. > What I've successfully done, twice :-), to fix my vfork errors is to follow > the > above procedure: run rebase-trigger, stop all Cygwin, then run setup-x86.exe, > followed by a reboot, then bring up cmd window where I run, > cd c:/cygwin; cd bin; ash; /usr/bin/rebaseall -v That's the wrong procedure. You run rebase-trigger fullrebase then reboot (if you have reason to suspect that a reboot might help, then run setup.exe (either architecture). An additional rebaseall beyond that isn't going to do anything useful. A full rebase on the same installation is deterministic, it will always chose the same base addresses. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- 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: Doing vfork: resource temporarily unavailable
Re: BLODA This is what worked for me over the weekend. I use Microsoft Security Essentials, no other anti-virus/malware/etc. software: - in MSE, disable real-time checking - reboot - trigger full rebaseall - run Cygwin setup - in MSIE, re-enable real-time checking I have not had any problems since. - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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
Non-Cygwin slaves inside tmux
Hi. My testcase: run mintty-bash, run tmux inside and run netsh inside. Try to type. Result: horrible lags Expected result: it's possible to type normally I tried multiple Cygwin snapshots from the last 5 months, hoping that it could be a regression (therefore easily fixable), but all of them exhibit the same issue. A quick Google search didn't show any similar errors, so I'm reporting here in hope someone will be able to say "yeah, that's easy, let me fix that". :) Assuming I understand correctly the roles here -- bash does fork+exec(netsh) and Cygwin emulates that by creating a bash subprocess which creates a netsh subprocess; the bash process that is spawned to execute the native executable is creating threads and named pipes like crazy. Every few seconds a new pipe and thread pop up. All the old threads seem to be stuck in: #0 0x7ffad7f3120a in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll #1 0x7ffad53b1118 in WaitForSingleObjectEx () from /cygdrive/c/Windows/system32/KERNELBASE.dll #2 0x000180134cfb in muto::acquire (this=0x639363438, ms=ms@entry=4294967295) at /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sync.cc:87 #3 0x0001800f9ed9 in lock_process (exiting=false, this=) at /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/sync.h:53 #4 commune_process (arg=0x6e7cb90) at /usr/src/debug/cygwin-2.0.2-1/winsup/cygwin/pinfo.cc:542 ... several other frames which are related to Cygwin threads, I assume ... strace shows tmux getting these: seterrno_from_win_error: /usr/src/ports/cygwin/cygwin-2.0.2-1.x86_64/src/newlib-cygwin/winsup/cygwin/pinfo.cc:737 windows error 995 -- David Macek smime.p7s Description: S/MIME Cryptographic Signature
Re: w32api-runtime-4.0.2-1 fails to install
On 5/26/2015 06:36, Ken Turner wrote: > w32api-runtime-4.0.2-1 fails during installation with "unable to extract > /pypy-c.exe.stackdump". Clicking Retry causes a repeat of the same message, > and clicking Continue causes setup to hang. > > This appears to be due to a stray file "pypy-c.exe.stackdump" at the top > level of the package. Removing this seems to allow a correct installation. > I reuploaded the tarball with it removed, should be fixed now. signature.asc Description: OpenPGP digital signature
RE: Doing vfork: resource temporarily unavailable
>To: cygwin@cygwin.com >Subject: Re: Doing vfork: resource temporarily unavailable > >"Rockefeller, Harry" writes: > >>>-Original Message- >>>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On >>>Behalf Of Jim Reisert AD1C >>>Sent: Wednesday, May 20, 2015 8:54 AM >>>To: cygwin@cygwin.com >>>Subject: Re: Doing vfork: resource temporarily unavailable >>> This indicates that you need to run a full rebase (https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures). The simplest way to do this is to run '/usr/bin/rebase-trigger full', then stop all Cygwin processes and services, and then run setup-x86.exe. The _autorebase postinstall script will then take care of the rebase. I have occasionally found it necessary to reboot the computer before doing this. >>> >>>This doesn't always work for me. In fact, I just did this - set the >>>trigger, rebooted, then ran Cygwin Setup. The first time I started Emacs, >>>no problem (only one dbus warning). >>>The very next time, this: >>> >>> 0 [main] emacs-X11 2512 child_info_fork::abort: >>>C:\Cygwin\bin\cygMagickCore-6.Q16-2.dll: Loaded to different address: >>>parent(0x171) != child(0x192) >> >> Recently I spent about an hour running numerous rebaseall commands >> interspersed with at least one rerun of setup-x86 and 3 reboots before my >> emacs vfork errors went away. >> I don't know if it was the third reboot or something else such as >> deleting some of my biggest emacs buffers ( I use desktop-save-mode) that >> finally cured the problem. >> If there is a "bottom" to this problem I would be willing to participate as >> a tester. >The autorebase did not work for me, even after several trials. >I finally de-installed Cygwin, and reinstalled it (in its 64bit version which >I did not use up to now). >Now everything is back on track. Thanks. >Best regards, > Seb >-- >Sebastien Vauban Instructions above state running setup-x86.exe not setup-x86_64.exe. Does anyone experience frequent emacs vfork errors running 64-bit Cygwin? Maybe it's time for me to try running that again? What I've successfully done, twice :-), to fix my vfork errors is to follow the above procedure: run rebase-trigger, stop all Cygwin, then run setup-x86.exe, followed by a reboot, then bring up cmd window where I run, cd c:/cygwin; cd bin; ash; /usr/bin/rebaseall -v -- 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: Doing vfork: resource temporarily unavailable
"Rockefeller, Harry" writes: >>-Original Message- >>From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of >>Jim Reisert AD1C >>Sent: Wednesday, May 20, 2015 8:54 AM >>To: cygwin@cygwin.com >>Subject: Re: Doing vfork: resource temporarily unavailable >> >>> This indicates that you need to run a full rebase >>> (https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures). The >>> simplest way to do this is to run '/usr/bin/rebase-trigger full', then >>> stop all Cygwin processes and services, and then run setup-x86.exe. >>> The _autorebase postinstall script will then take care of the rebase. >>> >>> I have occasionally found it necessary to reboot the computer before >>> doing this. >> >>This doesn't always work for me. In fact, I just did this - set the trigger, >>rebooted, >>then ran Cygwin Setup. The first time I started Emacs, no problem (only one >>dbus warning). >>The very next time, this: >> >> 0 [main] emacs-X11 2512 child_info_fork::abort: >>C:\Cygwin\bin\cygMagickCore-6.Q16-2.dll: Loaded to different address: >>parent(0x171) != child(0x192) > > Recently I spent about an hour running numerous rebaseall commands > interspersed with > at least one rerun of setup-x86 and 3 reboots before my emacs vfork errors > went away. > I don't know if it was the third reboot or something else such as deleting > some of my > biggest emacs buffers ( I use desktop-save-mode) that finally cured the > problem. > If there is a "bottom" to this problem I would be willing to participate as a > tester. The autorebase did not work for me, even after several trials. I finally de-installed Cygwin, and reinstalled it (in its 64bit version which I did not use up to now). Now everything is back on track. Thanks. Best regards, Seb -- Sebastien Vauban -- 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
