Re: noDosFileWarning no longer required?
On Jul 28 18:59, Steven Penny wrote: > It appears the infamous "MS-DOS style path detected" warning is no longer > generated, regardless of CYGWIN variable. Is this the case, and if so why? It is still generated, and just like before, it is generated only the first time it shows up. The only change here is that it's not any longer generated by default, but only if you set CYGWIN to contain "dosfilewarning". > It was a long time annoyance so I would be glad to be rid of the > warning, but I would just like to confirm that it is in fact gone, and > intentionally gone. It's intentionally not the default anymore due to it's annoying "feature" to sometimes show up in circumstances not under control of the user. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpo4R2nywiVM.pgp Description: PGP signature
Problems running "hg convert" with "subversion[-python]" 1.8.13-2
Greetings, having installed Cygwin's version 1.8.13-2 of both, "subversion" and "subversion-python", I get $ hg convert -d hg -s svn http://gpsbabel.googlecode.com/svn/ gpsbabel ** unknown exception encountered, please report by visiting ** http://mercurial.selenic.com/wiki/BugTracker ** Python 2.7.10 (default, Jun 1 2015, 18:17:45) [GCC 4.9.2] ** Mercurial Distributed SCM (version 3.4.2+5-601da1db19f7) ** Extensions loaded: convert, histedit, strip, mq Traceback (most recent call last): File "/home/Rainer/bin/hg", line 43, in mercurial.dispatch.run() File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 29, in run sys.exit((dispatch(request(sys.argv[1:])) or 0) & 255) File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 91, in dispatch ret = _runcatch(req) File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 160, in _runcatch return _dispatch(req) File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 885, in _dispatch cmdpats, cmdoptions) File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 646, in runcommand ret = _runcommand(ui, options, cmd, d) File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 976, in _runcommand return checkargs() File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 947, in checkargs return cmdfunc() File "/home/Rainer/repo/mercurial/mercurial/dispatch.py", line 882, in d = lambda: util.checksignature(func)(ui, *args, **cmdoptions) File "/home/Rainer/repo/mercurial/mercurial/util.py", line 716, in check return func(*args, **kwargs) File "/home/Rainer/repo/mercurial/hgext/convert/__init__.py", line 338, in convert return convcmd.convert(ui, src, dest, revmapfile, **opts) File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 106, in __getattribute__ self._load() File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 78, in _load mod = _hgextimport(_import, head, globals, locals, None, level) File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/home/Rainer/repo/mercurial/hgext/convert/convcmd.py", line 13, in from subversion import svn_source, svn_sink File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 134, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/home/Rainer/repo/mercurial/hgext/convert/subversion.py", line 25, in from svn.core import SubversionException, Pool File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 134, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/site-packages/svn/core.py", line 26, in from libsvn.core import * File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 115, in _demandimport return _hgextimport(_import, name, globals, locals, fromlist, level) File "/home/Rainer/repo/mercurial/mercurial/demandimport.py", line 47, in _hgextimport return importfunc(name, globals, *args) File "/usr/lib/python2.7/site-packages/libsvn/core.py", line 7285, in svn_pool_create() TypeError: svn_pool_create() takes exactly 2 arguments (0 given) However, going back to version 1.8.13-1 of both, "subversion" and "sub- version-python", I get the expected result: $ hg convert -d hg -s svn http://gpsbabel.googlecode.com/svn/ gpsbabel initializing destination gpsbabel repository scanning source... ... and so on ... Sincerely, Rainer PS: I "Cc:"-ed the Mercurial people because -- even though I'm convinced this is a Cygwin problem -- I think they should at least know. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Shell Fails to Start when Enabling High Address
On Jul 28 17:26, Benjamin Cao wrote: > Corinna, > > When I start Cygwin, with the AllocationPreference registry enable for > VirtualAlloc, the shell immediate closes. I get the below error. > > 2 [main] sh 5240 c:\cygwin\bin\sh.exe: *** fatal error - internal > error reading the windows environment - too many environment > variables? > > I guess you have answered the question to when we could get our > testing running on Cygwin, but I'm unable to get to that point if the > shell cannot start. Any advice on what I'm seeing now? A bug in Cygwin. Actually, 2 bugs, one generic bug and one in 64 bit Cygwin only. I applied patches to the git repo and I just uploaded new developer snapshots to https://cygwin.com/snapshots/ which contain the fixes. I'm also creating new test releases 2.2.0-0.4 and upload and announce them later today. Please give any of them a try, preferredly today, so I may be able to create the offical Cygwin 2.2.0 release today as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpfwSz5hlSUl.pgp Description: PGP signature
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.2.0-0.4
Hi Cygwin friends and users, I released a new TEST version of Cygwin. The version number is 2.2.0-0.4. New in this version: - Fix crashes under AllocationPreference=0x10 condition Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00765.html I plan to release 2.2.0-1 today or, if testing of the above isn't performed today, next Monday. What's new: --- - New APIs: getcontext, setcontext, makecontext, swapcontext. - New functions: sigsetjmp, siglongjmp. These were only available as macros up to now, but POSIX requires that siglongjmp has to be available as function. What changed: - - When started from a non-Cygwin process, check if $HOME starts with a slash (absolute POSIX path). Otherwise ignore it. Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00344.html Bug Fixes - - Fix potential hang running ldd(1). Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00292.html - Fix crashes under AllocationPreference=0x10 condition Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00765.html Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Cygwin Shell Fails to Start when Enabling High Address
Hi Corinna, I have tried the latest snapshot and have confirmed that with AllocationPreference enabled, I can start Cygwin without any crashes. Thanks, Ben Cao -Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Corinna Vinschen Sent: Wednesday, July 29, 2015 7:49 AM To: cygwin@cygwin.com Subject: Re: Cygwin Shell Fails to Start when Enabling High Address On Jul 28 17:26, Benjamin Cao wrote: > Corinna, > > When I start Cygwin, with the AllocationPreference registry enable for > VirtualAlloc, the shell immediate closes. I get the below error. > > 2 [main] sh 5240 c:\cygwin\bin\sh.exe: *** fatal error - internal > error reading the windows environment - too many environment > variables? > > I guess you have answered the question to when we could get our > testing running on Cygwin, but I'm unable to get to that point if the > shell cannot start. Any advice on what I'm seeing now? A bug in Cygwin. Actually, 2 bugs, one generic bug and one in 64 bit Cygwin only. I applied patches to the git repo and I just uploaded new developer snapshots to https://cygwin.com/snapshots/ which contain the fixes. I'm also creating new test releases 2.2.0-0.4 and upload and announce them later today. Please give any of them a try, preferredly today, so I may be able to create the offical Cygwin 2.2.0 release today as well. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
What generates colossal 1.4G /usr/share/icons/
My preferred version of Cygwin is rather sparse, being Base + a few additions from Utilities + gcc + latex + gnuplot + various minor for Cygwin-X. Recently my footprint grew by much more than 1G. What is it that generates the **absolutely massive** /usr/share/icons/? I've had a hunt through "requires:" in setup.ini but got lost. Thank you! Fergus -- 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: httpd immediate segfault on startup
On 7/26/2015 5:24 PM, Jim Garrison wrote: > Updated all cygwin packages to current versions, installed httpd > 2.4.16-1. On startup httpd segfaults: > > Exception: STATUS_ACCESS_VIOLATION at eip=65DC5D78 > eax=8004E028 ebx=0001 ecx= edx=8004DFF0 esi=80014490 > edi=80016498 > ebp=0028CC78 esp=0028CB5C program=C:\cygwin\usr\sbin\httpd.exe, pid > 25500, thread main > cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B > Stack trace: > Frame Function Args > 0028CC78 65DC5D78 (0003, 0028CC9C, 80010100, 0020) > 0028CD28 6100846A (, 0028CD84, 610074F0, ) > End of stack trace > > The log contains the following: > > [Sun Jul 26 16:59:15.693980 2015] [core:emerg] [pid 19552] (88)Function > not implemented: AH00023: Couldn't create the proxy mutex > [Sun Jul 26 16:59:15.693980 2015] [proxy:crit] [pid 19552] (88)Function > not implemented: AH02478: failed to create proxy mutex > AH00016: Configuration Failed > > Google turned up one other question citing the same symptoms, but on a > Chinese website, no answers so far. > > cygcheck.out attached > > Suggestions on how to troubleshoot? I can provide an strace output > (67k lines, 460kB gzipped) if desired. [Crickets...] I can do more troubleshooting if someone can point me in the right direction. Thanks. -- Jim Garrison (j...@acm.org) PGP Keys at http://www.jhmg.net RSA 0x04B73B7F DH 0x70738D88 -- 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: Applications no longer launching from xdg
On 24/07/2015 15:14, Jim Reisert AD1C wrote: This seems to be the real error, when I try to start an xterm from the xdg menu: executing 'xterm', pid 11044 pid 11044 exited with status b What is status b? Status 11, but in hexadecimal :) I'm not sure this is a valid exit status, which is perplexing. Taken in conjunction with the other mesages in ~/.xsession-errors, something is not right, but I don't know what. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Problems running "hg convert" with "subversion[-python]" 1.8.13-2
On Wed, 2015-07-29 at 12:48 +0200, Dr Rainer Woitok wrote: > File "/usr/lib/python2.7/site-packages/libsvn/core.py", line 7285, in > > svn_pool_create() > TypeError: svn_pool_create() takes exactly 2 arguments (0 given) This is apparently known breakage with libsvn's SWIG bindings related to new versions of SWIG. We're more or less powerless to do anything about it. You can tell it's not Mercurial's problem because the error occurs -in libsvn/core.py- while it's calling SVN. https://encrypted.google.com/search?output=search&sclient=psy-ab&q=svn_pool_create&=&=&oq=&gs_l=&pbx=1#q=svn_pool_create+exactly+2+arguments -- Mathematics is the supreme nostalgia of our time. -- 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: Xwin 1.17.2.1 exits early
On 28/07/2015 16:43, Rainer Blome wrote:
For a few months now, the only way for me to get Cygwin/X to run
was to start a Cygwin terminal ("C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico
-"),
then run "XWin -multiwindow -clipboard" from there, in the foreground.
That has worked for many weeks now.
I think this is saying that using the start menu shortcuts doesn't work,
but I'm not sure.
Today, I upgraded from 1.17.1-5 to 1.17.2-1 (I think),
and XWin no longer starts as it used to.
No X icon appears, XWin exits almost immediately, with return code zero.
This is the output:
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.17.2.0
OS: CYGWIN_NT-6.1-WOW 2.1.0(0.287/5/3) 2015-07-14 21:26 i686
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
Package: version 1.17.2-1 built 2015-07-09
XWin was started with the following command line:
Xwin -multiwindow
(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /cygdrive/c/blome/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 0005
This is pretty odd.
* I tried leaving out all command-line args but "-multiwindow". Still no
success.
How about leaving out all command-line args completely?
* I used the Cygwin installer to roll back to 1.17.1.5. Still no success.
This tends to argue against that you were using 1.17.1-5 previously, or
that other things e.g. the cygwin DLL were upgraded at the same time.
How can I troubleshoot this further?
Can you provide the logfile written by 'strace -o logfile XWin
-multiwindow' which might shed some light.
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin Shell Fails to Start when Enabling High Address
On Jul 29 13:10, Benjamin Cao wrote: > Hi Corinna, > > I have tried the latest snapshot and have confirmed that with > AllocationPreference enabled, I can start Cygwin without any crashes. Thanks for testing. Unfortunately another bug showed up, so I push the offical release into next week. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpsl9aAs7Cea.pgp Description: PGP signature
RE: httpd immediate segfault on startup
>On 7/26/2015 5:24 PM, Jim Garrison wrote: >> Google turned up one other question citing the same symptoms, but on a >> Chinese website, no answers so far. >> >> cygcheck.out attached >> >> Suggestions on how to troubleshoot? I can provide an strace output >> (67k lines, 460kB gzipped) if desired. > >[Crickets...] > >I can do more troubleshooting if someone can point me in the right direction. >Thanks. I can't actually help much other than to give you a cygcheck.out from a working system (attached) which was also updated fairly recently. Also, I have used auto-translation tools (translate.google.com) to help me read Chinese websites in the past, might be worth giving it a try. Wish I could be more help, let me know if you think of something further I can do. Dave cygcheck.out Description: cygcheck.out -- 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: What generates colossal 1.4G /usr/share/icons/
Fergus bonhard.uklinux.net> writes: > What is it that generates the **absolutely massive** /usr/share/icons/? > I've had a hunt through "requires:" in setup.ini but got lost. $ zgrep -c usr/share/icons/ /etc/setup/*lst.gz | grep -v :0 /etc/setup/adwaita-icon-theme.lst.gz:5135 /etc/setup/emacs.lst.gz:22 /etc/setup/file-roller.lst.gz:20 /etc/setup/gnome-icon-theme.lst.gz:5967 /etc/setup/hicolor-icon-theme.lst.gz:3 /etc/setup/inkscape.lst.gz:20 /etc/setup/lyx.lst.gz:8 /etc/setup/mintty.lst.gz:20 /etc/setup/octave.lst.gz:32 /etc/setup/xcursor-themes.lst.gz:159 /etc/setup/xinit.lst.gz:11 $ du -sh /usr/share/icons 114M/usr/share/icons These icon directories have a _lot_ of symlinks, did you perhaps copy your installation and flatten them? Regards, Achim.
Re: Problems running "hg convert" with "subversion[-python]" 1.8.13-2
Matt Mackall wrote: > On Wed, 2015-07-29 at 12:48 +0200, Dr Rainer Woitok wrote: >> File "/usr/lib/python2.7/site-packages/libsvn/core.py", line 7285, in >> >> svn_pool_create() >> TypeError: svn_pool_create() takes exactly 2 arguments (0 given) > > This is apparently known breakage with libsvn's SWIG bindings related to > new versions of SWIG. We're more or less powerless to do anything about > it. You can tell it's not Mercurial's problem because the error occurs > -in libsvn/core.py- while it's calling SVN. > > https://encrypted.google.com/search?output=search&sclient=psy-ab&q=svn_pool_create&=&=&oq=&gs_l=&pbx=1#q=svn_pool_create+exactly+2+arguments It looks like Fedora has a patch for this. I'll try applying it to Subversion this weekend and make a new release. I don't use Mercurial, but hopefully someone can test the new release. Thanks, Matt, for the useful link. -- David Rothenberger daver...@acm.org -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Aw: Re: Xwin 1.17.2.1 exits early
Gesendet: Mittwoch, 29. Juli 2015 um 18:14 Uhr Von: "Jon TURNEY" > I think this is saying that using the start menu shortcuts doesn't work, > but I'm not sure. Yes, a few months ago, they stopped working for me. For my report this is "merely" context, although I would appreciate it if they worked. On 28/07/2015 16:43, Rainer Blome wrote: >> * I tried leaving out all command-line args but "-multiwindow". Still no >> success. > How about leaving out all command-line args completely? Same symptoms, exits after less than a second with same output (didn't diff, though). >> * I used the Cygwin installer to roll back to 1.17.1.5. Still no success. > This tends to argue against that you were using 1.17.1-5 previously, or > that other things e.g. the cygwin DLL were upgraded at the same time. Yes, I may have come to 1.17.2 from a release earlier than 1.17.1-5 To be able to work, I installed VcXsrv which has "1.17.0.0" in its version string. That mostly works fine, except that it refuses connections from remote SSH-X-forwarding clients (did not try to troubleshoot that yet, it's just been a few hours). >> How can I troubleshoot this further? > Can you provide the logfile written by 'strace -o logfile XWin -multiwindow' > which might shed some light. Yes, attached. Regards, Rainer --- Process 7432 created --- Process 7432 loaded C:\Windows\SysWOW64\ntdll.dll at 77D8 --- Process 7432 unloaded DLL at 77A8 --- Process 7432 unloaded DLL at 7692 --- Process 7432 unloaded DLL at 77A8 --- Process 7432 unloaded DLL at 7798 --- Process 7432 loaded C:\Windows\SysWOW64\kernel32.dll at 7692 --- Process 7432 loaded C:\Windows\SysWOW64\KernelBase.dll at 76AD --- Process 7432 loaded C:\Windows\SysWOW64\sysfer.dll at 756C --- Process 7432 loaded C:\ProgramData\Symantec\Symantec Endpoint Protection\12.1.4013.4013.105\Data\Definitions\BASHDefs\20150625.011\UMEngx86.dll at 6E5D --- Process 7432 loaded C:\cygwin\bin\cygwin1.dll at 6100 --- Process 7432 loaded C:\cygwin\bin\cygxcb-icccm-4.dll at 5ED9 --- Process 7432 loaded C:\cygwin\bin\cygxcb-1.dll at 5EDC --- Process 7432 loaded C:\cygwin\bin\cygXau-6.dll at 6A2B --- Process 7432 loaded C:\cygwin\bin\cygXdmcp-6.dll at 6A20 --- Process 7432 loaded C:\cygwin\bin\cygxcb-image-0.dll at 5ED8 --- Process 7432 loaded C:\cygwin\bin\cygxcb-shm-0.dll at 5ED6 --- Process 7432 loaded C:\cygwin\bin\cygxcb-util-1.dll at 5ED5 --- Process 7432 loaded C:\cygwin\bin\cyggcc_s-1.dll at 6895 --- Process 7432 loaded C:\cygwin\bin\cygpixman-1-0.dll at 618C --- Process 7432 loaded C:\cygwin\bin\cygX11-xcb-1.dll at 6A2C --- Process 7432 loaded C:\cygwin\bin\cygX11-6.dll at 6A2D --- Process 7432 loaded C:\cygwin\bin\cygXfixes-3.dll at 6A1D --- Process 7432 loaded C:\cygwin\bin\cygXfont-1.dll at 6A19 --- Process 7432 loaded C:\cygwin\bin\cygbz2-1.dll at 697E --- Process 7432 loaded C:\cygwin\bin\cygfontenc-1.dll at 68BA --- Process 7432 loaded C:\cygwin\bin\cygz.dll at 5EB5 --- Process 7432 loaded C:\cygwin\bin\cygfreetype-6.dll at 689A --- Process 7432 loaded C:\cygwin\bin\cygpng16-16.dll at 616D --- Process 7432 loaded C:\Windows\SysWOW64\advapi32.dll at 75CA --- Process 7432 loaded C:\Windows\SysWOW64\msvcrt.dll at 7687 --- Process 7432 loaded C:\Windows\SysWOW64\sechost.dll at 766A --- Process 7432 loaded C:\Windows\SysWOW64\rpcrt4.dll at 7785 --- Process 7432 loaded C:\Windows\SysWOW64\sspicli.dll at 7589 --- Process 7432 loaded C:\Windows\SysWOW64\cryptbase.dll at 7588 --- Process 7432 loaded C:\Windows\SysWOW64\gdi32.dll at 76A4 --- Process 7432 loaded C:\Windows\SysWOW64\user32.dll at 7614 --- Process 7432 loaded C:\Windows\SysWOW64\lpk.dll at 7658 --- Process 7432 loaded C:\Windows\SysWOW64\usp10.dll at 75B7 --- Process 7432 loaded C:\Windows\SysWOW64\ole32.dll at 7671 --- Process 7432 loaded C:\Windows\SysWOW64\opengl32.dll at 5E24 --- Process 7432 loaded C:\Windows\SysWOW64\glu32.dll at 5E51 --- Process 7432 loaded C:\Windows\SysWOW64\ddraw.dll at 6BDB --- Process 7432 loaded C:\Windows\SysWOW64\dciman32.dll at 6BDA --- Process 7432 loaded C:\Windows\SysWOW64\setupapi.dll at 7624 --- Process 7432 loaded C:\Windows\SysWOW64\cfgmgr32.dll at 7780 --- Process 7432 loaded C:\Windows\SysWOW64\oleaut32.dll at 75C1 --- Process 7432 loaded C:\Windows\SysWOW64\devobj.dll at 7783 --- Process 7432 loaded C:\Windows\SysWOW64\dwmapi.dll at 74AA --- Process 7432 loaded C:\Windows\SysWOW64\shell32.dll at 76B2 --- Process 7432 loaded C:\Windows\SysWOW64\shlwapi.dll at 758F --- Process 7432 thread 7692 created 1 1 [main] XWin (7432) ** 239 240 [main] XWin (7432) Program name: C:\cygwin\bin\XWin.exe (windows pid 7432) 145 385 [main] XWin (7432) OS version: Windows NT-6.1 201 586 [main] XWin (7432) *
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.2.0-0.5
Hi Cygwin friends and users, I released a new TEST version of Cygwin. The version number is 2.2.0-0.5. New in this version: - In https://cygwin.com/ml/cygwin-patches/2015-q3/msg00010.html Roman Petrovski points out that RtlFillMemory and RtlCopyMemory only work for memory regions up to 2 Gigs. I took the opportunity to convert memset, memmove, memcpy, wmemset, wmemmove and wmemcpy to assembler code based on NetBSD code. Since I have no chance to do it this week, I plan to release 2.2.0-1 next Monday, if the above patch doesn't introduce new regressions. What's new: --- - New APIs: getcontext, setcontext, makecontext, swapcontext. - New functions: sigsetjmp, siglongjmp. These were only available as macros up to now, but POSIX requires that siglongjmp has to be available as function. What changed: - - When started from a non-Cygwin process, check if $HOME starts with a slash (absolute POSIX path). Otherwise ignore it. Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00344.html Bug Fixes - - Fix potential hang running ldd(1). Addresses: https://cygwin.com/ml/cygwin/2015-07/msg00292.html - Fix crashes under AllocationPreference=0x10 condition Addresses: https://cygwin.com/ml/cygwin/2015-02/msg00765.html - x86_64 only: Implement memset, memmove, memcpy, wmemmove, wmemcpy in assembler derived from NetBSD. Addresses: https://cygwin.com/ml/cygwin-patches/2015-q3/msg00010.html Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Aw: Re: Xwin 1.17.2.1 exits early
On 29/07/2015 18:49, Rainer Blome wrote: Gesendet: Mittwoch, 29. Juli 2015 um 18:14 Uhr Von: "Jon TURNEY" >I think this is saying that using the start menu shortcuts doesn't work, >but I'm not sure. Yes, a few months ago, they stopped working for me. For my report this is "merely" context, although I would appreciate it if they worked. On 28/07/2015 16:43, Rainer Blome wrote: >>* I tried leaving out all command-line args but "-multiwindow". Still no success. >How about leaving out all command-line args completely? Same symptoms, exits after less than a second with same output (didn't diff, though). >>* I used the Cygwin installer to roll back to 1.17.1.5. Still no success. >This tends to argue against that you were using 1.17.1-5 previously, or >that other things e.g. the cygwin DLL were upgraded at the same time. Yes, I may have come to 1.17.2 from a release earlier than 1.17.1-5 To be able to work, I installed VcXsrv which has "1.17.0.0" in its version string. That mostly works fine, except that it refuses connections from remote SSH-X-forwarding clients (did not try to troubleshoot that yet, it's just been a few hours). >>How can I troubleshoot this further? >Can you provide the logfile written by 'strace -o logfile XWin -multiwindow' which might shed some light. Yes, attached. Thanks for this. strace-XWin-multiwindow-RB.log --- Process 7432 created --- Process 7432 loaded C:\Windows\SysWOW64\ntdll.dll at 77D8 --- Process 7432 unloaded DLL at 77A8 --- Process 7432 unloaded DLL at 7692 --- Process 7432 unloaded DLL at 77A8 --- Process 7432 unloaded DLL at 7798 --- Process 7432 loaded C:\Windows\SysWOW64\kernel32.dll at 7692 --- Process 7432 loaded C:\Windows\SysWOW64\KernelBase.dll at 76AD --- Process 7432 loaded C:\Windows\SysWOW64\sysfer.dll at 756C --- Process 7432 loaded C:\ProgramData\Symantec\Symantec Endpoint Protection\12.1.4013.4013.105\Data\Definitions\BASHDefs\20150625.011\UMEngx86.dll at 6E5D [...] --- Process 7432 thread 8132 created --- Process 7432, exception 8001 at 756F69C1 --- Process 7432 thread 8132 exited with status 0x8001 --- Process 7432 thread 8184 exited with status 0x8001 --- Process 7432 thread 7692 exited with status 0x8001 --- Process 7432 thread 7256 exited with status 0x8001 --- Process 7432 exited with status 0x8001 This looks very much like an exception is occurring in sysfer.dll (which is part of 'Symantec Endpoint Protection' This has been reported as causing problems a few times recently (See [1],[2]). If possible, you should try to update it or create an exception for XWin.exe I think exception 0x8001 is STATUS_GUARD_PAGE_VIOLATION. I'm not sure why this doesn't get translated into a non-zero exit code by Cygwin. [1] https://cygwin.com/ml/cygwin/2015-03/msg00080.html [2] https://cygwin.com/ml/cygwin/2015-05/msg00146.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
Analyzing a SEG FAULT that gdb doesn't help with
've got a program which was running but suddenly does not run. I've been trying to debug in the usual way but all I get is a stackdump. I consulted the internet for advice on how to use a stackdump and it was pretty clear. I also brought LDD into the mix. The IP register when the SEGV occurs is at 6155d363. Below are the ranges per DLL that LDD prints for my system (updated today by the way). ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7784) kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x754a) KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll (0x7582) cygwin1.dll => /usr/bin/cygwin1.dll (0x6100) cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x6f63) cygmozjs185-1.0.dll => /usr/bin/cygmozjs185-1.0.dll (0x6e59) cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6f58) cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x6d00) cygffi-6.dll => /usr/bin/cygffi-6.dll (0x6f60) cygnspr4.dll => /usr/bin/cygnspr4.dll (0x6df7) So I tried to addr2line /usr/bin/cygwin1.dll 6155d363 and I got nothing (?? at ??:?) I then reviewed in setup-x86 the possible cygwin packages to see if there was a missing package I could use to enable cygwin1.dll's addresses to be translated but I didn't recognize anything. I also tried strace. I got very little information regarding whatever the programming failure is: -8 cut here 8--- Installation of CLOCK_SYNC_GET_CAPS_EX.txt successful 107 1561415 [main] cdiclient 4536 write: 54 = write(1, 0x801BA9F8, 54) 15458 1576873 [main] cdiclient 4536 fhandler_pty_slave::write: pty0, write(0x801BA9F8, 17) 121 1576994 [main] cdiclient 4536 fhandler_pty_common::process_opost_output: (1852): pty output_mutex (0x150): waiting -1 ms 94 1577088 [main] cdiclient 4536 fhandler_pty_common::process_opost_output: (1852): pty output_mutex: acquired 118 1577206 [main] cdiclient 4536 fhandler_pty_common::process_opost_output: (1891): pty output_mutex(0x150) released 99 1577305 [main] cdiclient 4536 write: 17 = write(1, 0x801BA9F8, 17) --- Process 4536, exception c005 at 6115D363 77604 1654909 [main] cdiclient 4536 exception::handle: In cygwin_except_handler exception 0xC005 at 0x6115D363 sp 0x28BFA4 146 1655055 [main] cdiclient 4536 exception::handle: In cygwin_except_handler signal 11 at 0x6115D363 -8 cut here 8--- There is a write to stdout immediately preceding the crash. I would not guess that that is causing the problem. The write is using the same buffer as the one just before it and any others I found and the return value is equal to the byte count argument. The write to stdout precedes the part of the program where I instruct the JavaScript interpreter to call a function defined by the file that has been interpreted already. It's possible that in the course of executing that JavaScript it called into one of my JavaScript extensions and that the problem lies there. But I can't even identify where within cygwin1 or any other executable the SEGV occurred. 1) Why is it not the case that gdb handles this SEGV in the usual manner? It too just allows the stackdump to be made and lets me know that the inferior has run its course. 2) What tools have I overlooked in debugging this? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
find_fast_cwd : warning : Couldn't compute FAST_CWD pointer
To who it may concern, I am seeing several of these "Couldn't compute FAST_CWD pointer" warnings I am compiling an R package. I am using R version 2.15.1 and Rtools version 2.15.0.1919 Rtools includes Cygwin My build system is Windows Server 2012 R2. My previous build system was Windows 7 Enterprise SP1 Everything else was that same and this warning did not appear. Attached is the log file from this build that contains this warning message. It is unclear if this warning will cause any problems with the build. Please let me know. Best Regards, Rob McAllister Keysight Technologies R-PADB.log Description: R-PADB.log -- 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: lzip-1.17.1 and lziprecover-1.17-1
Version 1.17-1 of lzip and lziprecover has been uploaded for both 32bit and 64bit Cygwin. lzip is an alternative to the bzip2 compressor. lziprecover is responsible for fixing corrupted lzip compressed files. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. signature.asc Description: OpenPGP digital signature
Re: What generates colossal 1.4G /usr/share/icons
>> What is it that generates the **absolutely massive** /usr/share/icons/? >> I've had a hunt through "requires:" in setup.ini but got lost. > $ du -sh /usr/share/icons > 114M /usr/share/icons > These icon directories have a _lot_ of symlinks, did you perhaps copy your > installation and flatten them? Thank you. $ du -sh /usr/share/icons/ 1.5G /usr/share/icons/ I did not intentionally flatten them, but I must have: 1.5G >> 114M. Unflattening is presumably not possible (how would it be driven?) so: I had better re-install and hope that multiple symlinks are recovered. Can you say what original package installation might have induced this directory? Fergus -- 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
