Re: Window manager commands in native window manager multiwindow mode
On 10/7/2015 11:48 AM, Ken Brown wrote:
On 10/7/2015 11:20 AM, Gulliver Smith wrote:
I ask this question from time to time just in case someone new sees it
and decides to work on it or others might agree that it is a priority.
Other people have raised this over the last few years as well.
The issue is that I would like to raise windows from within a program
(Emacs to be precise), but it doesn't work with the native window
manager running in multiwindow mode.
Emacs has several nice commands for which I have not-so-nice work
arounds (opening and closing windows). These are:
(raise-frame f)
(iconify-frame f)
(decionify-frame f)
(make-frame-visible f)
None of these work with Cygwin X.
Please give a detailed recipe for reproducing the problem.
Never mind. I searched the archive and found the details in an earlier
post of yours:
https://sourceware.org/ml/cygwin-xfree/2011-08/msg00046.html
Here's what I found when I tried to reproduce the problem:
>> (raise-frame f)
I agree that this doesn't work. But there's a post by Oliver Schmidt
(https://sourceware.org/ml/cygwin-xfree/2011-08/msg00047.html)
purporting to have a fix for this. There is later discussion in which
Jon Turney had some questions about the patch, but I didn't read all of
it. Jon, was this ever resolved?
>> (iconify-frame f)
This works.
>> (decionify-frame f)
There's no such function in GNU emacs (even after correcting the obvious
typo).
>> (make-frame-visible f)
This seems to be working. Maybe you're misunderstanding what "visible"
means in this context (or maybe I am). The frame is initially visible,
even if other windows are hiding it, as evidenced by the fact that
(frame-visible-p f) evaluates to something non-nil ('icon' if the frame
is iconified, 't' otherwise). If I now make it invisible by evaluating
(make-frame-invisible f), both the frame and its icon disappear.
There's no way to bring it to the front by using Alt-Tab. The frame and
icon reappear if I now evaluate (make-frame-visible f).
In summary, the only problem I see is with raise-frame, and maybe that
one is fixable. We'll have to wait to hear from Jon and/or Oliver.
Ken
--
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: Window manager commands in native window manager multiwindow mode
On 10/7/2015 11:20 AM, Gulliver Smith wrote: I ask this question from time to time just in case someone new sees it and decides to work on it or others might agree that it is a priority. Other people have raised this over the last few years as well. The issue is that I would like to raise windows from within a program (Emacs to be precise), but it doesn't work with the native window manager running in multiwindow mode. Emacs has several nice commands for which I have not-so-nice work arounds (opening and closing windows). These are: (raise-frame f) (iconify-frame f) (decionify-frame f) (make-frame-visible f) None of these work with Cygwin X. Please give a detailed recipe for reproducing the problem. I just tried the following: 1. Start the X server by running startxwin in a Cygwin Terminal (mintty). 2. Use the xdg menu icon to start xterm. 3. In xterm, run 'emacs&'. 4. In emacs, run 'M-x iconify-frame'. The current frame did indeed get iconified, as expected. I'm not sure how to test the other commands. Ken P.S. The cygwin-xfree mailing list is obsolete. You should use the main cygwin mailing list in the future to make sure your mail is seen by the maximum number of people. -- 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: xpdf zoom-in/out ("-"/"+") doesn't work after "z"/"w"
On 9/19/2015 1:24 AM, Csaba Raduly wrote: On Fri, Sep 18, 2015 at 10:37 PM, Ken Brown wrote: On 9/17/2015 1:08 AM, Paul wrote: After I press "z" to fit the page to the window, or "w" to fit the page width within the window, I'm finding that "-" & "+" is unresponsive. I can get it responding again by first pression "0" to zoom to 125%, but I really hope that this is not necessary. Is anyone else experiencing this? I didn't use xpdf on this computer before, and just loaded the package tonight. I can confirm this, but I'm not convinced it's a bug. 'man xpdf' says: 0 Set the zoom factor to 125%. + Zoom in (increment the zoom factor by 1). - Zoom out (decrement the zoom factor by 1). z Set the zoom factor to 'page' (fit page to window). w Set the zoom factor to 'width' (fit page width to window). If the zoom factor is 'page' or 'width', what would it mean to increment or decrement the zoom factor by 1? One more/less than the zoom factor needed to achieve "fit page" or "fit width". Sorry, I wasn't clear. In the context of the manual entry, it's not obvious that the program author(s) intended zoom factors of 'page' and 'width' to be subject to incrementing/decrementing. I get the same impression from looking at the zoom box at the bottom of the screen: The choices are 400%, 200%, ..., 12.5%, "fit page", and "fit width". So it seems quite possible that the program is behaving as designed. There's also no reason to think that this is a bug in the Cygwin implementation of xpdf, unless the OP finds that it behaves differently on other systems. Ken -- 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: xpdf zoom-in/out ("-"/"+") doesn't work after "z"/"w"
On 9/17/2015 1:08 AM, Paul wrote: After I press "z" to fit the page to the window, or "w" to fit the page width within the window, I'm finding that "-" & "+" is unresponsive. I can get it responding again by first pression "0" to zoom to 125%, but I really hope that this is not necessary. Is anyone else experiencing this? I didn't use xpdf on this computer before, and just loaded the package tonight. I can confirm this, but I'm not convinced it's a bug. 'man xpdf' says: 0 Set the zoom factor to 125%. + Zoom in (increment the zoom factor by 1). - Zoom out (decrement the zoom factor by 1). z Set the zoom factor to 'page' (fit page to window). w Set the zoom factor to 'width' (fit page width to window). If the zoom factor is 'page' or 'width', what would it mean to increment or decrement the zoom factor by 1? Ken P.S. The cygwin-xfree list is obsolete. You'll reach more people if you use the main cygwin list. -- 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: X no longer spawning windows after update
On 7/25/2015 4:00 AM, xxx wrote: Think it would be good if the Cygwin installer threw vital changes to behaviour in packages (like the one referenced below) in face to click through before doing installs. If it's a deliberate change, document it in the installer loading in package-specific readmes so that user accepts the change before discovery and being launched into the unknown, You could also subscribe to the cygwin-announce list. It's a low-volume list and shouldn't be much of a burden. Ken -- 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: [ANNOUNCEMENT] Updated: packages rebuilt for libpng16, tiff-4
On 2/11/2015 7:39 PM, Yaakov Selkowitz wrote: On Wed, 2015-02-11 at 18:12 -0500, Ken Brown wrote: On 2/8/2015 9:56 PM, Yaakov Selkowitz wrote: * fontconfig-2.11.1-2 I see that you decided not to restore the TeX Live font directories to /etc/fonts/fonts.conf. If that's your actual decision, and not just an oversight, It was an oversight; thanks for the reminder. As for a decision: AFAICS these fonts aren't intended for general usage (e.g. within X), so I've tried to understand how fontconfig should be used within TeX Live. In Fedora, for instance, the texlive font directories are not in fonts.conf: http://pkgs.fedoraproject.org/cgit/fontconfig.git/tree/fontconfig.spec#n66 and the texlive package doesn't include any references to conf.d or conf.avail: http://pkgs.fedoraproject.org/cgit/texlive.git/tree/texlive.spec However, Arch Linux's documentation actually addresses this clearly: https://wiki.archlinux.org/index.php/TeX_Live#Fonts and suggests a solution similar to yours by providing the file in conf.avail without automatically creating the symlink. The TeX Live manual further suggests that such a file may already included in xetex: https://www.tug.org/texlive/doc/texlive-en/texlive-en.html#x1-350003.4.4 But I don't see such a file on my system, nor is it mentioned in Fedora's texlive.spec. Besides the location, though, the solution is the same. then I guess one of the TeX Live packages should add a suitable file to /usr/share/fontconfig/conf.avail, with a link to it in /etc/fonts/conf.d. Or I could just add the file directly to /etc/fonts/conf.d and skip the symlink, whichever you prefer. The contents would be /usr/share/texmf-dist/fonts/opentype /usr/share/texmf-dist/fonts/truetype /usr/share/texmf-dist/fonts/type1 and I would call it 09-texlive.conf, as suggested in the TeX Live manual. Is this how you want me to handle it? Based on the above, and various mailing list discussions on the topic, I think we should provide that file but NOT the symlink, and document this in an appropriate place. That sounds reasonable. I think I'll provide the file in texlive-collection-basic, and I'll put the documentation in a suitable README file and in the release announcement. Ken -- 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: [ANNOUNCEMENT] Updated: packages rebuilt for libpng16, tiff-4
On 2/8/2015 9:56 PM, Yaakov Selkowitz wrote: * fontconfig-2.11.1-2 I see that you decided not to restore the TeX Live font directories to /etc/fonts/fonts.conf. If that's your actual decision, and not just an oversight, then I guess one of the TeX Live packages should add a suitable file to /usr/share/fontconfig/conf.avail, with a link to it in /etc/fonts/conf.d. Or I could just add the file directly to /etc/fonts/conf.d and skip the symlink, whichever you prefer. The contents would be /usr/share/texmf-dist/fonts/opentype /usr/share/texmf-dist/fonts/truetype /usr/share/texmf-dist/fonts/type1 and I would call it 09-texlive.conf, as suggested in the TeX Live manual. Is this how you want me to handle it? Ken -- 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: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
On 11/30/2014 2:44 AM, Yaakov Selkowitz wrote: On 2014-11-30 00:36, Nem W Schlecht wrote: I had never used/run/heard of fbpanel before this release. I was seeing the same blank bar and had to do as you suggested: cp -f /usr/share/fbpanel/multiwindow ~/.config/fbpanel/ To get anything useful. Might want to add this command as part of the installation process (with a simple file check to make sure ~/.config/fbpanel/multiwndow doesn't exist before copying, of course). I was about to say that fbpanel handles this itself (see /usr/libexec/fbpanel/make_profile). But looking at the code, I think I see what may be happening. If you have *none* of the following in your PATH: firefox gnome-terminal opera pcmanfm rox (rox-filer) urxvt (rxvt-unicode) thunar then by mistake it results in a syntax error with sed, which ends up making an empty profile. I just uploaded fbpanel-6.1-5 to sourceware; once it hits the mirrors and you install it, please remove your empty ~/.config/fbpanel/multiwindow and it should work as designed. That fixed it. Thanks. Ken -- 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: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
On 11/27/2014 10:03 PM, Yaakov Selkowitz wrote: * The new default startxwinrc also launches a miniature fbpanel in the upper left corner of the screen which contains an XDG application menu (the 'X' icon) for launching X applications, plus an on-demand area for X tray icons. After the first run, the panel and menu can be customized in ~/.config/fbpanel/multiwindow. This is not working well for me. I've tested on both 32-bit and 64-bit Cygwin with no .startxwinrc and no .[xX]* files, and I've tested on two different computers (both running Windows 7). I started the X server via the new start menu shortcut. What happens is that a band appears across the bottom of the screen (full width), hiding about 2/3 of the taskbar. This makes it impossible to access the icons on the right side of the taskbar. Also, there's no X icon in the upper left corner of the screen. But there is a large X icon in the taskbar, partially visible above the band, and when I mouse over it, I see a little window that says "X panel". Closing this window makes the band go away. So I guess this band is the miniature fbpanel referred to above, but it's appearing in the wrong place. I don't see anything suspicious in XWin.0.log, but .xsession-errors says, "fbpanel: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.". But this only appears after I've exited the server, so maybe it's normal. Finally, ~/.config/fbpanel/multiwindow exists but is empty. Ken -- 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: cygwin emacs failing siletnly
On 11/25/2014 8:54 PM, Gulliver Smith wrote: Thanks for all of the advice on fc-cache, but it doesn't help my emacs run. Does anyone else have any ideas why the fonts are causing emacs to blow up? You said in one of your messages of October 13 that fc-cache is failing. emacs-X11 is not going to be able to find any fonts if there's something wrong with your fontconfig setup. You might try running fc-cache under strace to see if that gives any clues. Ken -- 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: [ANNOUNCEMENT] Updated: fontconfig-2.11.1-1
On 5/13/2014 4:38 PM, Yaakov (Cygwin/X) wrote: On 2014-05-12 20:45, Ken Brown wrote: On 5/9/2014 11:07 AM, Yaakov (Cygwin/X) wrote: This is an update to the latest upstream release. The Windows font directory has been removed from the default fonts path due to issues caused by stale caches; a separate package to add it to the path, as well as keep the cache current automatically, should be available soon. You also removed /usr/share/ghostscript/fonts, /usr/share/texmf-dist/fonts/opentype, /usr/share/texmf-dist/fonts/truetype, and /usr/share/texmf-dist/fonts/type1. Was that intentional? Yes, because it seems that they would also have this issue because nothing in the providing packages updates the cache. (cygport only generates fontconfig postinstall scripts for /usr/share/fonts.) I don't know about the ghostscript fonts, but cygport does generate the appropriate fc-cache commands in the postinstall scripts for the texlive-collection-* packages that install fonts. This is done in __prep_texlive() in src_postinst.cygpart. Ken -- 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: [ANNOUNCEMENT] Updated: fontconfig-2.11.1-1
On 5/9/2014 11:07 AM, Yaakov (Cygwin/X) wrote: The following packages have been updated for the Cygwin distribution: *** fontconfig-2.11.1-1 *** libfontconfig1-2.11.1-1 *** libfontconfig-devel-2.11.1-1 Fontconfig is a library designed to provide system-wide font configuration, customization and application access. This is an update to the latest upstream release. The Windows font directory has been removed from the default fonts path due to issues caused by stale caches; a separate package to add it to the path, as well as keep the cache current automatically, should be available soon. You also removed /usr/share/ghostscript/fonts, /usr/share/texmf-dist/fonts/opentype, /usr/share/texmf-dist/fonts/truetype, and /usr/share/texmf-dist/fonts/type1. Was that intentional? Ken -- 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: Emacs just stopped working for no reason
On 3/5/2014 8:28 PM, Jim Reisert AD1C wrote: I was away on vacation for a week. Cygwin / X / GNU Emacs 24.3.1 were all working normally when I left. I left the computer powered on while I was away. No software was updated on the computer during that time, though I am running the BOINC software for World Community Grid. Computer is running Windows 7 Pro 64-bit. I left a couple of xterm windows open before I left, because there was some work I wanted to be reminded of when I got home. Upon arriving home last night, I tried to fire up Emacs, but now it's not working. It either says "memory exhausted" or just hangs. I rebooted, nothing changed. I started "ash" and ran "rebaseall -v". Still, nothing changed. This is not the first time that Emacs has died. The only way to fix the problem is to completely re-install Cygwin from scratch. Is there *any* way to try to figure out what is causing this? You might check to see if this is the fontconfig problem that others have reported (see http://cygwin.com/ml/cygwin/2013-12/msg00248.html): Try running "fc-cache -fsv". Ken -- 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: gtk+ applications crash when filechooser opened
[This is a followup to http://cygwin.com/ml/cygwin/2013-12/msg00255.html; see also http://cygwin.com/ml/cygwin/2013-12/msg00146.html] On 12/13/2013 2:12 AM, Carl Michal wrote: I recently started trying to port a gtk program to cygwin, and have found that my program crashes everytime it tries to open a file chooser widget. This doesn't happen with just my own programs, but also with gvim and emacs-x11. Either will start up ok, but both crash as soon as File->Open is selected. FWIW, here's one more data point. I can confirm this behavior of gvim and emacs-X11, but on x86 only. The File->Open dialog works fine in both gvim and emacs-X11 on x86_64. Ken -- 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: [ANNOUNCEMENT] Uploads for 12 August
On 8/14/2013 8:14 AM, Ken Brown wrote: On 8/14/2013 7:59 AM, Corinna Vinschen wrote: On Aug 14 13:33, Corinna Vinschen wrote: On Aug 14 12:53, Corinna Vinschen wrote: On Aug 14 06:28, Ken Brown wrote: On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Thanks. It should only be emacs that needs rebuilding; glib doesn't supply its own malloc, but emacs does. I'll test it and report back. Success! Thanks very much for the quick fix. I've got new emacs packages ready to go for both 32-bit and 64-bit. Do you expect to release cygwin-1.7.24 soon? If not, I'll upload the new packages as test releases for anyone who wants to install the snapshot. Ken P.S. For anyone (like Angelo) who wants to build the emacs trunk, I need to patch gmalloc.c upstream before the fix will take effect. -- 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: [ANNOUNCEMENT] Uploads for 12 August
On 8/14/2013 7:59 AM, Corinna Vinschen wrote: On Aug 14 13:33, Corinna Vinschen wrote: On Aug 14 12:53, Corinna Vinschen wrote: On Aug 14 06:28, Ken Brown wrote: On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Given that, we should perhaps skip the memalign override. On second (third? fourth?) thought, I think we should do this with posix_memalign only. valloc is just as obsolete as posix_memalign. I applied the patch to allow overriding posix_memalloc only, and I'm building snapshots right now. For testing, this requires to rebuild either emacs, or glib, or both, I'm not sure. Make sure to link against the new crt0.o/libcygwin.a and use the new Cygwin DLL for testing. Thanks. It should only be emacs that needs rebuilding; glib doesn't supply its own malloc, but emacs does. I'll test it and report back. Ken -- 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: [ANNOUNCEMENT] Uploads for 12 August
On 8/14/2013 5:16 AM, Corinna Vinschen wrote: On Aug 14 10:10, Corinna Vinschen wrote: On Aug 13 18:00, Ken Brown wrote: On 8/13/2013 2:26 PM, Corinna Vinschen wrote: On Aug 13 13:09, Yaakov (Cygwin/X) wrote: On 2013-08-13 09:13, Ken Brown wrote: Yaakov, is there any chance that you could patch Glib to do the equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an emacs issue. It would affect any GTK application that provides its own malloc rather than using Cygwin's malloc. (But emacs is probably the only such application in the distro.) Given that the only programs which seem to be *practically* affected by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't have yet), and using G_SLICE=always-malloc apparently affects performance, I don't think that would be an appropriate solution. For now, I think you'll have to add a wrapper script. Can anybody of you explain to me what the actual underlying problem is? I mean, why this error message: ***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes (alignment: 512): Function not implemented What function is not implemented? Is that something we can fix, perhaps in the Cygwin DLL? It's memalign, or at least that's what it was in 2007. See http://cygwin.com/ml/cygwin/2007-02/msg00678.html So it's using its own malloc but we don't support overriding other functions besides malloc/realloc/calloc/free. In theory we could do that in future. We still have room for 10 (x86) resp. 12 (x86_64) pointers in the per_process structure, which could be used for this purpose. This would only require applications which need this feature to be rebuilt with the next Cygwin version providing these pointers. More precisely, they have to be rebuild using crt0.o from the next Cygwin release, and they would have to run under the next Cygwin release. If you omit one step, you're back to the current behaviour. But we shouldn't waste those unused slots either, so the number of overridable functions should be kept small. In theory we have mallopt, mallinfo, posix_memalign, memalign, and valloc. I guess we can skip mallopt and mallinfo since they are pretty seldomly used in user-provided malloc implementations. Memalign is an old, deprecated function, so I wonder why it's used at all. GSlice should use posix_memalign instead. Yaakov, is there an option to use posix_memalign rather than memalign? I just checked the glib source, and it does use posix_memalign if it's available. I was quoting a 2007 discussion when I said it was memalign that GSlice wanted to use. Anyway, that would be three extra pointers in the per_process structure, for memalig, posic_memalign, and valloc, and we could get rid of the `if (!use_internal) set_errno(ENOSYS);' in those functions and rather call the user provided functions then. Does that make sense? Yes. Ken -- 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: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 2:26 PM, Corinna Vinschen wrote:
On Aug 13 13:09, Yaakov (Cygwin/X) wrote:
On 2013-08-13 09:13, Ken Brown wrote:
Yes. The fix was to add the following for the Cygwin build, very early
in main():
setenv ("G_SLICE", "always-malloc", 1);
I don't know why this no longer works. Maybe Glib now does its memory
management initialization before emacs's main() is entered.
Exactly; in glib-2.36, g_type_init has been moved to a ctor, which
is automatically called before main(); hence, this setenv is too
late now. Mozilla software is also affected by this, see:
https://bugzilla.gnome.org/show_bug.cgi?id=687763
https://bugzilla.mozilla.org/show_bug.cgi?id=833117
and many others. Firefox et al already use launcher scripts, so
adding one more line won't be a big deal for them.
Yaakov, is there any chance that you could patch Glib to do the
equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an
emacs issue. It would affect any GTK application that provides its own
malloc rather than using Cygwin's malloc. (But emacs is probably the
only such application in the distro.)
Given that the only programs which seem to be *practically* affected
by this is our Emacs, and Firefox/Thunderbird/etc. (which we don't
have yet), and using G_SLICE=always-malloc apparently affects
performance, I don't think that would be an appropriate solution.
For now, I think you'll have to add a wrapper script.
Can anybody of you explain to me what the actual underlying problem is?
I mean, why this error message:
***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
(alignment: 512): Function not implemented
What function is not implemented? Is that something we can fix,
perhaps in the Cygwin DLL?
It's memalign, or at least that's what it was in 2007. See
http://cygwin.com/ml/cygwin/2007-02/msg00678.html
Ken
--
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: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 10:13 AM, Ken Brown wrote:
On 8/13/2013 8:08 AM, Angelo Graziosi wrote:
Il 13/08/2013 11.52, Angelo Graziosi ha scritto:
Yaakov wrote:
The following packages (and their subpackages) have been updated for
both arches:
After this update my GTK builds of Emacs trunk do not work any more. For
example, the bootstrap of rev. 113816 I did yesterday and that worked
fine up to before this update, now fails so:
$ emacs -Q &
[1] 3044
***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
(alignment: 512): Function not implemented
[1]+ Aborted (core dumped) emacs -Q
So, after this update, I tried a new bootstrap (rev.113838) but id fails
in the same manner:
if test "no" = "yes"; then \
rm -f bootstrap-emacs.exe; \
ln temacs.exe bootstrap-emacs.exe; \
else \
`/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
test "X" = X || -zex emacs.exe; \
mv -f emacs.exe bootstrap-emacs.exe; \
fi
***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes
(alignment: 512): Function not implemented
/bin/sh: line 7: 896 Aborted (core dumped)
`/bin/pwd`/temacs --batch --load loadup bootstrap
Makefile:835: recipe for target `bootstrap-emacs.exe' failed
make[2]: *** [bootstrap-emacs.exe] Error 1
make[2]: uscita dalla directory "/work/emacs/Work/src"
Makefile:379: recipe for target `src' failed
make[1]: *** [src] Error 2
make[1]: uscita dalla directory "/work/emacs/Work"
Makefile:1040: recipe for target `bootstrap' failed
make: *** [bootstrap] Error 2
build-emacs.sh: Bootstrap failure...
Probably this issue affects also the Cygwin (GTK) package of Emacs..
It seems that the workaround is to start Emacs with
G_SLICE=always-malloc,
$ G_SLICE=always-malloc emacs -Q &
Ken, wasn't this issue fixed upstream some time ago?
Yes. The fix was to add the following for the Cygwin build, very early
in main():
setenv ("G_SLICE", "always-malloc", 1);
I don't know why this no longer works. Maybe Glib now does its memory
management initialization before emacs's main() is entered.
Yaakov, is there any chance that you could patch Glib to do the
equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an
emacs issue. It would affect any GTK application that provides its own
malloc rather than using Cygwin's malloc. (But emacs is probably the
only such application in the distro.)
An alternative to patching Glib would be to fix the problem directly in
Cygwin, but I don't know how hard that is and whether Corinna and cgf
are interested. The issue, as I understand it, is this: Cygwin allows
programs to supply their own malloc but not their own memalign. Glib
calls memalign, which becomes Cygwin's memalign, which returns ENOSYS
when Cygwin's malloc is not being used.
There was a long discussion about this on the Cygwin mailing list in
2007. The thread starts at
http://cygwin.com/ml/cygwin/2007-02/msg00469.html
and continues at
http://cygwin.com/ml/cygwin/2007-02/msg00503.html
and did not resolve the issue.
While we're waiting for a good solution, I could quickly repackage
emacs-X11 so that it supplies a wrapper script that sets
G_SLICE=always-malloc before calling emacs-X11. If people think that's
a good idea, I should be able to do it later today.
Ken
--
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: [ANNOUNCEMENT] Uploads for 12 August
On 8/13/2013 8:08 AM, Angelo Graziosi wrote:
Il 13/08/2013 11.52, Angelo Graziosi ha scritto:
Yaakov wrote:
The following packages (and their subpackages) have been updated for
both arches:
After this update my GTK builds of Emacs trunk do not work any more. For
example, the bootstrap of rev. 113816 I did yesterday and that worked
fine up to before this update, now fails so:
$ emacs -Q &
[1] 3044
***MEMORY-ERROR***: [3044]: GSlice: failed to allocate 504 bytes
(alignment: 512): Function not implemented
[1]+ Aborted (core dumped) emacs -Q
So, after this update, I tried a new bootstrap (rev.113838) but id fails
in the same manner:
if test "no" = "yes"; then \
rm -f bootstrap-emacs.exe; \
ln temacs.exe bootstrap-emacs.exe; \
else \
`/bin/pwd`/temacs --batch --load loadup bootstrap || exit 1; \
test "X" = X || -zex emacs.exe; \
mv -f emacs.exe bootstrap-emacs.exe; \
fi
***MEMORY-ERROR***: [896]: GSlice: failed to allocate 504 bytes
(alignment: 512): Function not implemented
/bin/sh: line 7: 896 Aborted (core dumped)
`/bin/pwd`/temacs --batch --load loadup bootstrap
Makefile:835: recipe for target `bootstrap-emacs.exe' failed
make[2]: *** [bootstrap-emacs.exe] Error 1
make[2]: uscita dalla directory "/work/emacs/Work/src"
Makefile:379: recipe for target `src' failed
make[1]: *** [src] Error 2
make[1]: uscita dalla directory "/work/emacs/Work"
Makefile:1040: recipe for target `bootstrap' failed
make: *** [bootstrap] Error 2
build-emacs.sh: Bootstrap failure...
Probably this issue affects also the Cygwin (GTK) package of Emacs..
It seems that the workaround is to start Emacs with
G_SLICE=always-malloc,
$ G_SLICE=always-malloc emacs -Q &
Ken, wasn't this issue fixed upstream some time ago?
Yes. The fix was to add the following for the Cygwin build, very early
in main():
setenv ("G_SLICE", "always-malloc", 1);
I don't know why this no longer works. Maybe Glib now does its memory
management initialization before emacs's main() is entered.
Yaakov, is there any chance that you could patch Glib to do the
equivalent of G_SLICE=always-malloc on Cygwin? This isn't really an
emacs issue. It would affect any GTK application that provides its own
malloc rather than using Cygwin's malloc. (But emacs is probably the
only such application in the distro.)
An alternative to patching Glib would be to fix the problem directly in
Cygwin, but I don't know how hard that is and whether Corinna and cgf
are interested. The issue, as I understand it, is this: Cygwin allows
programs to supply their own malloc but not their own memalign. Glib
calls memalign, which becomes Cygwin's memalign, which returns ENOSYS
when Cygwin's malloc is not being used.
There was a long discussion about this on the Cygwin mailing list in
2007. The thread starts at
http://cygwin.com/ml/cygwin/2007-02/msg00469.html
and continues at
http://cygwin.com/ml/cygwin/2007-02/msg00503.html
and did not resolve the issue.
Ken
--
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: Cygwin/x doesn't work on windows 8
On 7/4/2013 8:45 PM, Anton Malykh wrote: Hi all, I apologize if this bug is already known. I have two fresh windows 8 machines. Looks like cygwin/x doesn't work on either of them with similar symptoms. The installation went fine. "xwin" command seems to work as expected. But when I try to right click on X icon in tray -> Applications -> xterm (or emacs/xload) - nothing happens. In the terminal I'm getting: 0 [main] xwin 1880 child_info_fork::abort: C:\cygwin\bin\cygXdmcp-6.dll: Loaded to different address: parent(0x34) != child(0x2C) fork() to run command failed See http://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures . I attach my cygcheck and xwin log files. Your cygcheck output shows that you don't have emacs installed, so you won't be able to start it from the X icon. But that's not related to your fork failure. Ken -- 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: Paste from xterm to Emacs no longer works
On 4/3/2013 7:54 AM, Csaba Raduly wrote: Hi Fredrik, You need to give a bit more detail than "It doesn't work". http://www.chiark.greenend.org.uk/~sgtatham/bugs.html#respect Start here: Problem reports: http://cygwin.com/problems.html Right. In addition, the OP should give a recipe for reproducing the problem starting with `emacs -Q'. While waiting for this, I'll make a wild guess that his problem is related to the selection changes that started with emacs-24.1. Browse the NEWS file (`C-h n') and search for "Selection changes". Ken -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 2/10/2013 1:37 PM, Jon TURNEY wrote: On 10/02/2013 12:45, Ken Brown wrote: I'm also seeing a mouse problem. It involves the combination shift-leftbutton-rightbutton (intended to emulate shift-middlebutton) after I've started XWin with -emulate3buttons. I use a 2-button mouse with a scroll wheel that can be pressed to serve as a third button. But I find it hard to press the scroll wheel without turning it, so I prefer to use -emulate3buttons. The shift-left-right combination used to be seen by emacs as shift-middle, but now emacs doesn't seem to see it at all. Moreover, after I press it once, either in emacs or elsewhere, both emacs and xterm stop responding to some other mouse events. To reproduce (without emacs): 1. Start the X server with startxwin -- -emulate3buttons 2. Press shift-left-right in an xterm window, using a mouse of the type I described. 3. Move the mouse over the titlebar of the xterm window. The menu items don't get highlighted, and left-clicking on them has no effect. The problem disappears if I remove the -emulate3buttons option; but that's not a good solution for me since I actually want to emulate 3 buttons. Thanks for the reproduction steps. It seems I introduced a bug in the -emulate3buttons code with some changes in 1.13.1-1, which could cause the emulated middle mouse button click to not be released. I've applied fix to address this, so hopefully this works better now. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it fixes the issue for you? That fixes it. Thanks. Ken -- 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: FW: xorg-server 1.13.1-1: problems with xterm
On 2/8/2013 1:15 PM, Jon TURNEY wrote: On 06/02/2013 17:18, PRIKHODKO, GEORGE wrote: After upgrading xorg-server and xorg-server-common packages from 1.13.0-1 to 1.13.1-1 version, xterm stopped responding to mouse events. I can select a text in a xterm window, but I cannot paste in it using middle button; holding Ctrl button and pressing one of mouse buttons doesn't bring 'Main Options' or 'VT Fonts' menus. After rolling back to 1.13.0-1 version everything works as I expect. I have four computers WIndows XP, Vista, 7 and 8, and run XWin in multi-window mode: XWin -ac -clipboard -emulate3buttons -lesspointer -multiwindow All four computers show the same symptoms. It's really not necessary write 3 emails about this, and certainly doesn't get you a reply any faster. I can't reproduce this problem. Are you using a 3-button mouse? Does removing -emulate3buttons help? I'm also seeing a mouse problem. It involves the combination shift-leftbutton-rightbutton (intended to emulate shift-middlebutton) after I've started XWin with -emulate3buttons. I use a 2-button mouse with a scroll wheel that can be pressed to serve as a third button. But I find it hard to press the scroll wheel without turning it, so I prefer to use -emulate3buttons. The shift-left-right combination used to be seen by emacs as shift-middle, but now emacs doesn't seem to see it at all. Moreover, after I press it once, either in emacs or elsewhere, both emacs and xterm stop responding to some other mouse events. To reproduce (without emacs): 1. Start the X server with startxwin -- -emulate3buttons 2. Press shift-left-right in an xterm window, using a mouse of the type I described. 3. Move the mouse over the titlebar of the xterm window. The menu items don't get highlighted, and left-clicking on them has no effect. The problem disappears if I remove the -emulate3buttons option; but that's not a good solution for me since I actually want to emulate 3 buttons. Ken -- 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/
Implement ~/.xsession-errors?
I'm wondering whether it's feasible for the Cygwin X-server to redirect stderr to ~/.xsession-errors for programs started under the server, as is done on some Linux systems. This would be useful for two reasons. First, some programs emit warnings that can be ignored, and it would be nice if users could avoid seeing those every time they start the program. Second, and more importantly, standard error is often lost, for instance for programs started by ~/.startxwinrc. It could be useful for package maintainers to be able to ask users to send the contents of ~/.xsession-errors. Ken -- 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/
emacs, GSettings, and gtk3
I am now able to build emacs-X11 with GSettings support, using either gtk2 or gtk3; the problems discussed in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html have disappeared. Unfortunately, the resulting build produces some annoying Gtk warnings. I'm trying to decide whether the benefits of GSettings and gtk3 outweigh the annoyances. I'd like the opinions of emacs users and GNOME experts on this. Here are the details: 1. If emacs is built using gtk3 and the window geometry is specified on the command line or in ~/.Xdefaults, the following warning appears in the terminal from which emacs was started: Gtk-WARNING **: gtk_window_parse_geometry() called on a window with no visible children; the window should be set up before gtk_window_parse_geometry() is called. The warning can safely be ignored but is annoying. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11177 I don't know any good workaround, except perhaps to wrap emacs in a script, or use an alias, that redirects stderr to a file. (This would be similar to the Linux behavior, where I think stderr for programs started under X11 is typically redirected to ~/.xsession-errors.) 2. If emacs is built with GSettings support and is started without a D-Bus daemon running, the following warning is issued: GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. The warning can usually, but not always, be ignored. See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8855 In this case there is a simple workaround: Ensure, by a suitable line in ~/.startxwinrc or ~/.bashrc, that a D-Bus daemon is always running before emacs is started. Thanks in advance for any opinions/advice on how I should deal with these issues in the next emacs release. The simplest solution would be to continue to use gtk2 and to disable GSettings support, but I'm open to other suggestions. Ken Brown Cygwin's Emacs maintainer -- 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: GVim slow to respond
On 6/8/2012 12:51 PM, Brett DiFrischia wrote: Hiya, I am having similar problems with gvim as noted by K Stahl on Fri, 11 May 2012 12:33:16 -0400. gvim has become unusable. Based on the results of ldd and my typical update frequency, I believe one (or more) of the following files may be the culprit: 2012-04-30 01:53:40.00100 -0500 -rwxr-xr-x 1 me 265230 /usr/bin/cygpcre-1.dll 2012-04-30 21:29:10.00100 -0500 -rwxr-xr-x 1 me 96270 /usr/bin/cygatk-1.0-0.dll 2012-04-30 23:39:07.00100 -0500 -rwxr-xr-x 1 me 916494 /usr/bin/cygcairo-2.dll 2012-05-01 22:30:32.00100 -0500 -rwxr-xr-x 1 me 205326 /usr/bin/cyggdk_pixbuf-2.0-0.dll 2012-05-01 22:48:09.00100 -0500 -rwxr-xr-x 1 me 36366 /usr/bin/cygpangocairo-1.0-0.dll 2012-05-01 22:48:09.00100 -0500 -rwxr-xr-x 1 me 189966 /usr/bin/cygpangoft2-1.0-0.dll 2012-05-01 22:48:09.00100 -0500 -rwxr-xr-x 1 me 241166 /usr/bin/cygpango-1.0-0.dll 2012-05-02 03:21:49.00100 -0500 -rwxr-xr-x 1 me 566798 /usr/bin/cyggdk-x11-2.0-0.dll 2012-05-02 03:21:50.00100 -0500 -rwxr-xr-x 1 me 3835406 /usr/bin/cyggtk-x11-2.0-0.dll 2012-05-09 04:10:59.00100 -0500 -rwxr-xr-x 1 me 2288181 /usr/bin/cygwin1.dll 2012-05-12 23:15:18.00100 -0500 -rwxr-xr-x 1 me 72718 /usr/bin/cygz.dll 2012-05-15 00:29:23.00100 -0500 -rwxr-xr-x 1 me 11278 /usr/bin/cyggmodule-2.0-0.dll 2012-05-15 00:29:23.00100 -0500 -rwxr-xr-x 1 me 858126 /usr/bin/cygglib-2.0-0.dll 2012-05-15 00:29:23.00100 -0500 -rwxr-xr-x 1 me 1088526 /usr/bin/cyggio-2.0-0.dll 2012-05-15 00:29:24.00100 -0500 -rwxr-xr-x 1 me 264206 /usr/bin/cyggobject-2.0-0.dll I believe it was either the xorg-server update of 08 May 2012 13:09:54 +0100 or the Gnome update of Thu, 10 May 2012 01:23:40 -0500 simply due to the fact that vim without the GUI is still usable. The cause hasn't been found yet, but you can find a workaround in http://cygwin.com/ml/cygwin/2012-06/msg00043.html See also http://cygwin.com/ml/cygwin/2012-06/msg00057.html Ken -- 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/
X server crash with asymptote
To reproduce: 1. Install asymptote-2.15-1. 2. Start the X server (1.12.1-1), and run the following command in an xterm: $ asy -V /usr/share/doc/asymptote/examples/teapot.asy This should display a teapot in a separate window, but instead it crashes the X server. I've tested with cygwin-1.15 as well as the latest snapshot. The problem doesn't occur with version 1.12.0-5 of the X server. I'm running 64-bit Windows 7. I assume you'll be able to reproduce this, but I'll send further information (log, backtrace, cygcheck output) if you can't. Ken -- 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: EMACS broken after Patch Tuesday
On 5/16/2012 9:19 AM, McBroom, Robert C wrote: -Original Message- On 5/15/2012 4:41 PM, McBroom, Robert C wrote: Following the Microsoft updates on Windows 7 32bit system, EMACS will no longer function. CYGWIN had not been updated in a while as it was working for the tasks at hand. Updated to current image with the result-- rm3@mcbroomrc2 ~ $ emacs& rm3@mcbroomrc2 ~ $ 1 [main] bash 5280 fork: child -1 - forked process 5316 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 1026851 [main] bash 5280 fork: child -1 - forked process 3472 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 3038588 [main] bash 5280 fork: child -1 - forked process 1360 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 7048021 [main] bash 5280 fork: child -1 - forked process 704 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 15050612 [main] bash 5280 fork: child -1 - forked process 4408 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: Resource temporarily unavailable Tried rebaseall, reinstallation of emacs and xorg with no success. You're not using the emacs from the Cygwin distribution (which is /usr/bin/emacs). Where did /usr/local/bin/emacs come from? Ken - It is just a script to scale the geometry to my display. emacs . -geometry 100x73+504-55& Doesn't this script call itself recursively? Try /usr/bin/emacs . -geometry 100x73+504-55& Ken -- 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: EMACS broken after Patch Tuesday
On 5/15/2012 4:41 PM, McBroom, Robert C wrote: Following the Microsoft updates on Windows 7 32bit system, EMACS will no longer function. CYGWIN had not been updated in a while as it was working for the tasks at hand. Updated to current image with the result-- rm3@mcbroomrc2 ~ $ emacs& rm3@mcbroomrc2 ~ $ 1 [main] bash 5280 fork: child -1 - forked process 5316 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 1026851 [main] bash 5280 fork: child -1 - forked process 3472 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 3038588 [main] bash 5280 fork: child -1 - forked process 1360 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 7048021 [main] bash 5280 fork: child -1 - forked process 704 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: retry: Resource temporarily unavailable 15050612 [main] bash 5280 fork: child -1 - forked process 4408 died unexpectedly, retry 0, exit code -1073741571, errno 11 /usr/local/bin/emacs: fork: Resource temporarily unavailable Tried rebaseall, reinstallation of emacs and xorg with no success. You're not using the emacs from the Cygwin distribution (which is /usr/bin/emacs). Where did /usr/local/bin/emacs come from? Ken -- 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: dbus-launch --exit-with-session fails when run from .startxwinrc
On 4/25/2012 12:21 PM, Jon TURNEY wrote: On 24/04/2012 14:50, Ken Brown wrote: On 4/16/2012 9:50 AM, Ken Brown wrote: On 4/16/2012 9:44 AM, Ken Brown wrote: The following problem occurs on my 64-bit Windows 7 system but not on my XP system. I start the X server using the Start Menu shortcut [modified to add -emulate3buttons] and a .startxwinrc with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm Running ps in the resulting xterm window shows no dbus-launch or dbus-daemon process. But I can give the same dbus-launch command in the xterm window, and the processes start as expected. I'm attaching cygcheck output and the XWin log. My hope in reporting this is that the problem I'm seeing (and the difference between XP and Win7) is somehow related to the emacs problem I've been trying to solve: http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html Ken P.S. You'll see in the cygcheck output that I'm running a Cygwin snapshot; but nothing changes if I revert to cygwin-1.7.13-1. I forgot to say that if I remove "--exit-with-session" from the command line in my .startxwinrc, then a dbus-daemon process does start. I tried modifying the X server shortcut to read C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 2>&1' as suggested in a different thread, but that provides no information. The resulting startxwin.log is virtually identical (with minor differences) to XWin.0.log. In particular, there's no indication of what's happening when .startxwinrc is processed. There's no output because ~/.startxwinrc generates no output. For starters, it would really be helpful if someone could try to reproduce my problem on a 64-bit Windows 7 system. At the moment, I don't even know if there is a bug somewhere or simply a problem with my own system. Here's the recipe: 1. Create a .startxwinrc file with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm 2. Start the X server using the Start Menu shortcut. 3. In the resulting xterm window, give the "ps" command. If things are working right, the output from ps should show a dbus-launch process and a dbus-daemon process. These processes do appear on my XP system but not on my Windows 7 system. FWIW, it works on XP for me as well. I tried with the following ~/.startxwinrc: eval `dbus-launch --sh-syntax --exit-with-session | tee /dev/stderr` xterm ... which at least lets you see the pid of the dbus-daemon that is started. I'm not sure if --exit-with-session is correct with startxwin, since the startxwin process will not linger after it has started ~/.startxwinrc, and I don't know if stdin will remain open after it (and the process tree above it waiting for it) exits. I have this vague recollection that 'run' has to do different things on XP and W7, which might account for the different behaviour? Ah, that must be it. On XP, presumably because of the way 'run' behaves, the sh process that runs .startxwinrc hangs around, so the dbus processes keep running. If I run startxwin from a terminal instead of via the shortcut (i.e., without using 'run'), I get the same behavior on XP as on W7. Thanks. Ken -- 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: dbus-launch --exit-with-session fails when run from .startxwinrc
On 4/16/2012 9:50 AM, Ken Brown wrote: On 4/16/2012 9:44 AM, Ken Brown wrote: The following problem occurs on my 64-bit Windows 7 system but not on my XP system. I start the X server using the Start Menu shortcut [modified to add -emulate3buttons] and a .startxwinrc with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm Running ps in the resulting xterm window shows no dbus-launch or dbus-daemon process. But I can give the same dbus-launch command in the xterm window, and the processes start as expected. I'm attaching cygcheck output and the XWin log. My hope in reporting this is that the problem I'm seeing (and the difference between XP and Win7) is somehow related to the emacs problem I've been trying to solve: http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html Ken P.S. You'll see in the cygcheck output that I'm running a Cygwin snapshot; but nothing changes if I revert to cygwin-1.7.13-1. I forgot to say that if I remove "--exit-with-session" from the command line in my .startxwinrc, then a dbus-daemon process does start. I tried modifying the X server shortcut to read C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe >> /var/log/xwin/startxwin.log 2>&1' as suggested in a different thread, but that provides no information. The resulting startxwin.log is virtually identical (with minor differences) to XWin.0.log. In particular, there's no indication of what's happening when .startxwinrc is processed. For starters, it would really be helpful if someone could try to reproduce my problem on a 64-bit Windows 7 system. At the moment, I don't even know if there is a bug somewhere or simply a problem with my own system. Here's the recipe: 1. Create a .startxwinrc file with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm 2. Start the X server using the Start Menu shortcut. 3. In the resulting xterm window, give the "ps" command. If things are working right, the output from ps should show a dbus-launch process and a dbus-daemon process. These processes do appear on my XP system but not on my Windows 7 system. Ken -- 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: Issue with XWin under xlaunch
On 4/24/2012 7:54 AM, Jon TURNEY wrote: On 23/04/2012 16:04, Ken Brown wrote: I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Would it be possible for you to also add some code for diagnosing problems with processes started from .startxwinrc? I'm hoping it might help with the problem I reported in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html Hmm.. not sure code is really needed. You can see the output from startxwin by running it from a terminal, or capture it by changing the shortcut which runs it to something like the following (perhaps we should do that by default) C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 2>&1' That doesn't help, but I'll reply to my original thread to explain why. I shouldn't have interjected my question into this thread. Ken -- 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: Issue with XWin under xlaunch
On 4/23/2012 9:51 AM, Jon TURNEY wrote: > On 11/04/2012 11:23, Eliot Moss wrote: >> When I start XWin using xlaunch, trying to the start >> programs from the .XWinrc popup menu (right-click on >> the X icon, left-click on the program's entry in the >> menu), programs do not start. I get only those programs >> started by my script that I told xlaunch to run. >> >> I would like to use xlaunch, since it solves the issue >> I had with the startxwin taskbar icon being visible >> (when I claim it should not be, and it didn't use to >> be), but not being able to start additional programs >> makes this approach less useable. >> >> Looking at this from outside, it is hard to say whether >> the real issue is in xlaunch, in XWin, or the result of >> some misunderstanding between them. > > At the moment, the output from processes started from the notification area > icon doesn't go anywhere useful, which can make it hard to debug problems with > processes started this way. > > I've added some code to capture stdout and stderr from these subprocesses to > the X server log, and to more clearly diagnose problems which could occur > while fork/exec-ing them. Would it be possible for you to also add some code for diagnosing problems with processes started from .startxwinrc? I'm hoping it might help with the problem I reported in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html BTW, I tried the snapshot at ftp://cygwin.com/pub/cygwinx/XWin.20120423-git-638383315ef51e46.exe.bz2 and the resulting log has a lot of messages like this: winMultiWindowXMsgProcErrorHandler - ERROR: BadWindow (invalid Window parameter) winMultiWindowXMsgProcErrorHandler - ERROR: BadMatch (invalid parameter attributes) Is that to be expected, or does it indicate a real problem? Ken -- 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: dbus-launch --exit-with-session fails when run from .startxwinrc
On 4/16/2012 9:44 AM, Ken Brown wrote: The following problem occurs on my 64-bit Windows 7 system but not on my XP system. I start the X server using the Start Menu shortcut [modified to add -emulate3buttons] and a .startxwinrc with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm Running ps in the resulting xterm window shows no dbus-launch or dbus-daemon process. But I can give the same dbus-launch command in the xterm window, and the processes start as expected. I'm attaching cygcheck output and the XWin log. My hope in reporting this is that the problem I'm seeing (and the difference between XP and Win7) is somehow related to the emacs problem I've been trying to solve: http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html Ken P.S. You'll see in the cygcheck output that I'm running a Cygwin snapshot; but nothing changes if I revert to cygwin-1.7.13-1. I forgot to say that if I remove "--exit-with-session" from the command line in my .startxwinrc, then a dbus-daemon process does start. Ken -- 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: Problems with emacs built with gsettings support
I haven't made in progress in trying to debug this problem. I think I will probably have to build the next release of emacs without GSettings support. (This is a shame, but it's not a regression; emacs has never had the possibility of supporting GSettings prior to emacs-24.) If there are any emacs users out there who care about this, read on. First, here's a summary of what I know. Everything I say is independent of whether I build emacs with gtk2 or gtk3. * If emacs is built with GSettings support, it seems to work fine on Windows XP. * It also works fine on my 64-bit Windows 7 systems if I export GSETTINGS_BACKEND=memory * It fails on my Windows 7 systems otherwise. The failure consists of emacs crashing with a segmentation fault shortly after it starts. This could happen after a few minutes or a few hours, but it always happens. * I haven't found any indication that this is a BLODA problem, but I can't rule it out either. It would be very helpful if other people could try it on Windows 7. Here are the steps for testing, which are simpler than what I posted earlier in the thread: 1. Install my test build of emacs-X11-24.0.95-7 by running setup.exe -K http://sanibeltranquility.com/cygwin/kbrown.gpg and adding http://sanibeltranquility.com/cygwin to the list of mirrors. This was built with gtk3, so you'll have to let setup install a bunch of dependencies unless you already have libgtk3_0 installed. 2. Start the X server using the Start Menu shortcut, with no ~/.startxwinrc. 3. In the resulting xterm window: eval `dbus-launch --sh-syntax` emacs -Q & 4. Wait a few hours, if necessary, to see if emacs crashes. You can use it or just leave it alone (but don't use it for anything important). 5. Send a note to the list reporting success or failure, with details about your system. 6. If it fails, you can rerun setup.exe to restore your previous version of emacs. Or, if you'd like, you can install my build of emacs-X11-24.0.95-6, which was built without GSettings support. Thanks in advance to anyone who is willing to test. Ken -- 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: Problems with emacs built with gsettings support
On 4/7/2012 6:11 PM, Angelo Graziosi wrote: Il 06/04/2012 21.22, Angelo Graziosi ha scritto: Any way I will try to follow your recipe to reproduce the problem, but I am sure it is still there.. No, it isn't! I have run Emacs for more than 14 hours and I haven't see any problem. I have done that strictly following your recipe... I can confirm that it seems to work fine on Windows XP. But I have two Windows 7 computers on which it still consistently fails. I'm searching for BLODA, but in the meantime, it would be helpful if someone else could test it on Windows 7. I'd like to know if it's a general problem on Windows 7 or something specific to my systems. The recipe is in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00024.html Thanks. Ken -- 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: Problems with emacs built with gsettings support [was: Problems with emacs built against gtk3]
On 4/7/2012 6:11 PM, Angelo Graziosi wrote: Il 06/04/2012 21.22, Angelo Graziosi ha scritto: Any way I will try to follow your recipe to reproduce the problem, but I am sure it is still there.. No, it isn't! I have run Emacs for more than 14 hours and I haven't see any problem. I have done that strictly following your recipe... Hi Angelo, That's great news. Thank you very much for testing. Now I just have to figure out why it doesn't work on my system. Would you mind sending me your cygcheck output off-list so I can see how my setup differs from yours? I wonder if I need some GNOME-related package. Or it could be BLODA. What anti-virus software do you use (if any)? Thanks. Ken -- 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: Problems with emacs built with gsettings support [was: Problems with emacs built against gtk3]
On 4/4/2012 6:12 PM, Yaakov (Cygwin/X) wrote:
On 2012-04-04 09:15, Ken Brown wrote:
Another option is to use gtk3 but to put the GSETTINGS_BACKEND
workaround into the emacs startup code:
setenv ("GSETTINGS_BACKEND", "memory", 1);
I've been testing this, and it seems to work (but I won't be completely
confident until I've had emacs running for a day or so). Do you see any
downside?
This is intended solely for testing and debugging. Settings will not be
saved from one invocation to the next, so that's a pretty big downside.
OK, that was a bad idea. I'm going to try to debug this problem.
I was wrong when I said that the problem doesn't occur with gtk2. I
based that statement on earlier tests; but I did those tests several
months ago, when I started this thread, and I probably didn't have
dconf-service installed at the time. Now I can reproduce the problem
with both gtk2 and gtk3. But the problem doesn't occur if I build emacs
with the configure option --without-gsettings. I've changed the subject
line accordingly.
By the way, emacs (starting with emacs-24) will use both GSettings and
GConf if they're available. But there doesn't appear to be any problem
using GConf alone.
Here's my most recent debugging session. This is from a build using
gtk2 and GSettings (but not GConf):
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
[...]
Reading symbols from /home/kbrown/src/emacs/test/src/emacs...done.
(gdb) r -Q
Starting program: /home/kbrown/src/emacs/test/src/emacs -Q
[New Thread 12220.0x950]
[...]
[New Thread 12220.0x330c]
Program received signal SIGSEGV, Segmentation fault.
0x00289d7a in ?? ()
(gdb) bt full
#0 0x00289d7a in ?? ()
No symbol table info available.
#1 0x007bd264 in __morecore ()
No symbol table info available.
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x1 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
#2 0x0001 in ?? ()
warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)
wsock_started = true
wsadata = {wVersion = 514, wHighVersion = 514,
szDescription = "WinSock 2.0", '\000' ,
szSystemStatus = "Running", '\000' ,
iMaxSockets = 0, iMaxUdpDg = 0, lpVendorInfo = 0x0}
#3 0x00606175 in calloc (nmemb=4294867296, size=8) at gmalloc.c:1547
result = 0x0
#4 0x in ?? ()
No symbol table info available.
This looks very strange to me, especially the part about WinSock. Where
could that have come from?
Here are the steps for reproducing the problem:
1. Install the following packages and their dependencies:
gnutls-devel
libdbus1-devel
libdbus1_3
libgif-devel
libgtk2.0-devel
libgtk3-devel
libMagick-devel
libMagickCore5
librsvg2-devel
libSM-devel
libXpm-devel
[These might not all be necessary for reproducing the problem, but
they're used in my build or as runtime dependencies of my build.]
2. Build emacs with GSettings support but not GConf support:
wget ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-24.0.95.tar.gz
tar -xf emacs-24.0.95.tar.gz
cd emacs-24.0.95
./configure --without-gconf && make
[Note: By default, the build will use gtk2. The option
"--with-x-toolkit=gtk3" will make it use gtk3.]
3. Start the X server using the Start Menu shortcut, with no ~/.startxwinrc.
4. In the resulting xterm window:
eval `dbus-launch --sh-syntax`
cd emacs-24.0.95/src
./emacs -Q &
5. Ignore emacs; it will eventually crash. This could take one or more
hours, but it happens every time on my system. It happens much faster
if I don't disable GConf support.
It would be extremely helpful if someone could try to reproduce this.
At the very least, I'd like to rule out the possibility that it's caused
by BLODA on my system.
Ken
--
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: Problems with emacs built against gtk3
On 4/3/2012 11:55 PM, Yaakov (Cygwin/X) wrote:
On 2012-04-03 20:52, Ken Brown wrote:
There's no problem when emacs is built with gtk2. There's also no
problem with gtk3, provided I set GSETTINGS_BACKEND=memory.
I regularly run the entire GNOME desktop for hours (if not days) on end,
so I really don't think that this is a bug in dconf or gvfs.
I'll probably just have to stick with gtk2 for the next emacs release.
That's fine; gtk2 isn't going anywhere for a while.
Another option is to use gtk3 but to put the GSETTINGS_BACKEND
workaround into the emacs startup code:
setenv ("GSETTINGS_BACKEND", "memory", 1);
I've been testing this, and it seems to work (but I won't be completely
confident until I've had emacs running for a day or so). Do you see any
downside?
Ken
--
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: Problems with emacs built against gtk3
On 4/3/2012 6:30 PM, Yaakov (Cygwin/X) wrote: On 2012-04-03 16:11, Ken Brown wrote: Now that gvfs is available, I've built the latest emacs-24 pretest against gtk3 and removed the GSETTINGS_BACKEND=memory setting, but I still have the same problem. If I start emacs and then just walk away from it, after a while it will die with a segfault. (It may take an hour or more before this happens.) And with gtk2? There's no problem when emacs is built with gtk2. There's also no problem with gtk3, provided I set GSETTINGS_BACKEND=memory. I'll probably just have to stick with gtk2 for the next emacs release. Ken -- 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: X server crash when running texworks
On 4/2/2012 8:04 AM, Ken Brown wrote: On 3/31/2012 11:26 AM, Ken Brown wrote: On 3/31/2012 6:28 AM, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17Pro
Re: X server crash when running texworks
On 3/31/2012 11:26 AM, Ken Brown wrote: On 3/31/2012 6:28 AM, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtGu
Re: X server crash when running texworks
On 3/31/2012 6:28 AM, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtGui-
Re: X server crash when running texworks
On 3/29/2012 4:20 PM, Yaakov (Cygwin/X) wrote: On 2012-03-29 14:59, Ken Brown wrote: OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. fork() errors? Are there any messages on the console? Here's what I see in the xterm window from which I started texworks: $ QFileSystemWatcher: failed to add paths: /home/kbrown pdfTeX 3.1415926-2.3-1.40.12 (TeX Live 2011) kpathsea version 6.0.1 Copyright 2011 Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). There is NO warranty. Redistribution of this software is covered by the terms of both the pdfTeX copyright and the Lesser GNU General Public License. For more information about these matters, see the file named COPYING and the pdfTeX source. Primary author of pdfTeX: Peter Breitenlohner (eTeX)/Han The Thanh (pdfTeX). Compiled with libpng 1.4.8; using libpng 1.4.8 Compiled with zlib 1.2.5; using zlib 1.2.5 Compiled with poppler version 0.18.2 Everything looks normal except for the QFileSystemWatcher message. When I do `ps' at this point, it shows a defunct pdftex process. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). After I kill texworks, `ps' shows a dbus-daemon process and a dbus-launch process that weren't there before I started texworks, but maybe that's to be expected. texworks uses QtDBus, so it needs a DBus session bus. If one isn't present (which nowadays you need for just about anything), it will start its own instance. If you are using multiwindow with startxwin, I strongly recommend adding the following to the beginning of your ~/.startxwinrc: eval `dbus-launch --sh-syntax` I normally do this, but this time I had started the X server without my .startxwinrc for testing purposes. I've just restarted it in my normal way. I still get the texworks hang, but there are no longer extra dbus processes. So that 's not the issue. -- 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: X server crash when running texworks
On 3/29/2012 8:14 AM, Jon TURNEY wrote: On 28/03/2012 13:44, Ken Brown wrote: On 3/28/2012 8:28 AM, Ken Brown wrote: On 3/28/2012 7:16 AM, Jon TURNEY wrote: I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 Yes, that seems to fix it. I just started texworks and compiled 6 or 7 tex documents without a crash. I've never been able to do more than 1 or 2 before. Good. I spoke too soon. I closed texworks and was doing other things (not even involving X to my knowledge), and the X server just crashed. I'm attaching XWin.0.log. Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). After I kill texworks, `ps' shows a dbus-daemon process and a dbus-launch process that weren't there before I started texworks, but maybe that's to be expected. Ken -- 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: X server crash when running texworks
On 3/28/2012 7:16 AM, Jon TURNEY wrote: On 26/03/2012 21:32, Ken Brown wrote: On 3/26/2012 4:06 PM, Jon TURNEY wrote: On 26/03/2012 20:47, Ken Brown wrote: On 3/24/2012 3:47 PM, Ken Brown wrote: One further detail for anyone trying to reproduce this: I just tried it on a second computer, and my recipe didn't immediately produce the crash. But I simply started trying to use texworks (loading and compiling various tex documents), and the X server crashed within a few minutes. Thanks very much for the detailed report. On the off chance this is a known issue, would you mind downloading the X server symbols and getting a backtrace using the instruction on [1], before I try to reproduce it. OK, the backtrace is attached. Thanks very much. I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 Yes, that seems to fix it. I just started texworks and compiled 6 or 7 tex documents without a crash. I've never been able to do more than 1 or 2 before. Thanks! Ken -- 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: X server crash when running texworks
On 3/26/2012 4:06 PM, Jon TURNEY wrote:
On 26/03/2012 20:47, Ken Brown wrote:
On 3/24/2012 3:47 PM, Ken Brown wrote:
To reproduce:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing "texworks&" in an xterm window.
5. Click on the "Open" icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message "Caught signal
11 (segmentation fault)". Server aborting."
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.su
I'm attaching cygcheck output and XWin.0.log.
Ken
P.S. I'm currently using the test version of xorg-server (1.12.0-1), but
I can reproduce the crash with 1.11.4-5 also. Also, I'm currently
testing the latest Cygwin snapshot. I just tried reverting to 1.7.11,
and the X server still crashed, but not just from opening two files. I
had to open and compile several tex documents before it happened.
One further detail for anyone trying to reproduce this: I just tried it on a
second computer, and my recipe didn't immediately produce the crash. But I
simply started trying to use texworks (loading and compiling various tex
documents), and the X server crashed within a few minutes.
Thanks very much for the detailed report.
On the off chance this is a known issue, would you mind downloading the X
server symbols and getting a backtrace using the instruction on [1], before I
try to reproduce it.
OK, the backtrace is attached.
Ken
$ gdb --pid=5152
GNU gdb (GDB) 7.3.50.20111026-cvs (cygwin-special)
[...]
Reading symbols from /usr/bin/XWin.exe...Reading symbols from
/usr/lib/debug/usr/bin/XWin.dbg...
warning: section .gnu_debuglink not found in /usr/lib/debug/usr/bin/XWin.dbg
done.
done.
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6040.0x1ac]
0x004097c2 in NetWMToWinIconAlpha (icon=0xfed20010)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:295
295
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:
No such file or directory.
in
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c
(gdb) bt full
#0 0x004097c2 in NetWMToWinIconAlpha (icon=0xfed20010)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:295
hdc =
ii = {fIcon = 1, xHotspot = 0, yHotspot = 0, hbmMask = 0xf050f17,
hbmColor = 0x93051250}
bmh = {bV4Size = 108, bV4Width = 512, bV4Height = -512, bV4Planes = 1,
bV4BitCount = 32, bV4V4Compression = 3, bV4SizeImage = 0,
bV4XPelsPerMeter = 0, bV4YPelsPerMeter = 0, bV4ClrUsed = 0,
bV4ClrImportant = 0, bV4RedMask = 16711680, bV4GreenMask = 65280,
bV4BlueMask = 255, bV4AlphaMask = 4278190080, bV4CSType = 0,
bV4Endpoints = {ciexyzRed = {ciexyzX = 0, ciexyzY = 0, ciexyzZ = 0},
ciexyzGreen = {ciexyzX = 0, ciexyzY = 0, ciexyzZ = 0},
ciexyzBlue = {ciexyzX = 0, ciexyzY = 0, ciexyzZ = 0}},
bV4GammaRed = 0, bV4GammaGreen = 0, bV4GammaBlue = 0}
width =
height = 512
pixels = 0xfed20018
result = 0x2610b75
DIB_pixels = 0x4ff
#1 NetWMToWinIcon (bpp=, icon=0xfed20010)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:369
hasIconAlphaChannel = 1
versionChecked = 1 '\001'
#2 0x0040a085 in winXIconToHICON (pWin=0x805399d8, iconSize=32)
at
/opt/wip/cygport-git/xorg-server/xorg-server-1.12.0-1/src/xserver-cygwin-1.12.0-1/hw/xwin/winmultiwindowicons.c:449
mask =
image =
imageMask =
dst =
src =
iconPtr =
maskPtr =
planes = 1
bpp = 32
effBPP =
i =
biggest_size = 512
hDC =
ii = {fIcon = 1969585604, xHotspot = 196958, yHotspot = 283154527,
hbmMask = 0x0, hbmColor = 0x0}
hints = {flags = 1969585433, input = 11, initial_state = 11,
icon_pixmap = 0, icon_window = 4292791408, icon_x = 1969578512,
icon_y = -2142004644, icon_mask = 1024, window_group = 4292791464}
hIcon = 0x0
biggest_icon =
_XA_NET_WM_ICON = 361
generation = 1
icon =
icon_data =
size =
#3 0x0
Re: X server crash when running texworks
On 3/24/2012 3:47 PM, Ken Brown wrote:
To reproduce:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing "texworks&" in an xterm window.
5. Click on the "Open" icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message "Caught signal
11 (segmentation fault)". Server aborting."
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.su
I'm attaching cygcheck output and XWin.0.log.
Ken
P.S. I'm currently using the test version of xorg-server (1.12.0-1), but
I can reproduce the crash with 1.11.4-5 also. Also, I'm currently
testing the latest Cygwin snapshot. I just tried reverting to 1.7.11,
and the X server still crashed, but not just from opening two files. I
had to open and compile several tex documents before it happened.
One further detail for anyone trying to reproduce this: I just tried it
on a second computer, and my recipe didn't immediately produce the
crash. But I simply started trying to use texworks (loading and
compiling various tex documents), and the X server crashed within a few
minutes.
Ken
--
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: How to properly start xwin at windows seven startup?
On 2/2/2012 12:49 PM, David Karr wrote: I've had an old version of Cygwin running on a WinXP laptop for quite a while. I made it run "startxwin.bat" on startup. I'm now setting up the latest Cygwin on a Win7 laptop. The FAQ is saying to not use the "startxwin.bat" file (as it doesn't exist anymore), and use the exe file. However, it also says to not start it directly from Windows. It needs to be started from a login shell. What is the proper way to start the Xwin server at Windows startup? I didn't see this in the FAQ, and I didn't find any obvious answers in searches. http://x.cygwin.com/docs/ug/using.html#using-starting -- 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: Problems with emacs built against gtk3
On 12/9/2011 8:39 PM, nyc4...@aol.com wrote: Ken Brown writes: On 11/30/2011 6:54 AM, Yaakov (Cygwin/X) wrote: On Wed, 2011-11-30 at 11:17 +0100, Pavel Holejsovsky wrote: On 11/30/2011 4:51 AM, Yaakov (Cygwin/X) wrote: 2. The pango warning can already be observed with the current Cygwin emacs after the recent update of the GNOME libraries. To reproduce, install the emacs-X11 package and start emacs with the command `emacs&' in an xterm window. I cannot reproduce this. Does installing font-cantarell-otf help? Perhaps another font? I can reproduce it, in fact almost every gtk-enabled application spits that out. I tried stracing, and I think (but I'm not sure) that the warning appears after pango tries to load /usr/lib/pango/1.6.0/modules/pango-basic-fc.dll -> there is no /usr/lib/pango directory on my system, and it seems that no package in cygwin or ports repository provides it. That's the clue I needed. I switched pango to builtin modules over a year ago in Ports to help minimize fork() errors, but that didn't reach the distro until now. If I'm right, removing /etc/pango/pango.modules should fix it. That fixes it. Thanks. Unless I do: GSETTINGS_BACKEND=memory emacs& I get the following error: $ (emacs:4048): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. ** (emacs:4048): WARNING **: Abnormal program termination spawning command line `dbus-launch --autolaunch=614770a5ea44ec425e4c57144ed14d5c --binary-syntax --close-stderr': [1]+ Segmentation fault emacs I have no /etc/pango/pango.modules file Removing /etc/pango/pango.modules was to get rid of a pango warning that a lot of people were getting. Yaakov explained how to get rid of the error you're talking about here: http://cygwin.com/ml/cygwin-xfree/2011-11/msg00045.html Ken -- 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: Problems with emacs built against gtk3
On 12/4/2011 8:44 PM, Ken Brown wrote: On 12/4/2011 7:13 PM, Yaakov (Cygwin/X) wrote: On Fri, 2011-12-02 at 08:01 -0500, Ken Brown wrote: This doesn't do it. Emacs still dies after a short time. I don't know if that means that there's something else going on, but I'll retest it after you package gvfs. In the meantime, I'll continue with my workaround of setting GSETTINGS_BACKEND=memory. In case you (or anyone else) wants to experiment with this, you can get my build of the emacs-24 pretest by running setup.exe -K http://www.math.cornell.edu/~kbrown/kbrown.gpg and adding http://www.math.cornell.edu/~kbrown to the list of mirrors. WJFFM, but I'll get on that gvfs ITP right away. It looks like I also need to repackage pango1.0 to remove everyone's old pango.modules file. But despite your subject line, the binaries there are clearly gtk2 based. Was that intended? No, I made a mistake in my configure arguments. I put `--with-x=gtk3' instead of `--with-x-toolkit=gtk3', so emacs used the default gtk2. I'll rebuild it. I've rebuilt emacs and am now definitely using gtk3. I've also installed the latest Cygwin snapshot. I tried your suggested workaround again (export GIO_USE_VFS=local) and it still doesn't work for me, but the symptoms are different: emacs doesn't die, but it freezes as soon as I try to list a directory with the command `d'. [This runs `ls' in a subprocess.] I then went back to my GSETTINGS_BACKEND=memory workaround and noticed something new: If I run emacs in my normal way, with "emacs.geometry: 82x36+340+40" in .Xdefaults, I get the following error message: Gtk-WARNING **: gtk_window_parse_geometry() called on a window with no visible children; the window should be set up before gtk_window_parse_geometry() is called. But if I remove the geometry setting from .Xdefaults, emacs seems to work fine. It's probably not worth pursuing these new problems until gvfs is ready, but I mentioned them in case they suggest to you that something is going on aside from the missing gvfs. The gtk3 build of emacs is available in the same place as before if you want to try it. Ken -- 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: Problems with emacs built against gtk3
On 12/4/2011 7:13 PM, Yaakov (Cygwin/X) wrote: On Fri, 2011-12-02 at 08:01 -0500, Ken Brown wrote: This doesn't do it. Emacs still dies after a short time. I don't know if that means that there's something else going on, but I'll retest it after you package gvfs. In the meantime, I'll continue with my workaround of setting GSETTINGS_BACKEND=memory. In case you (or anyone else) wants to experiment with this, you can get my build of the emacs-24 pretest by running setup.exe -K http://www.math.cornell.edu/~kbrown/kbrown.gpg and adding http://www.math.cornell.edu/~kbrown to the list of mirrors. WJFFM, but I'll get on that gvfs ITP right away. It looks like I also need to repackage pango1.0 to remove everyone's old pango.modules file. But despite your subject line, the binaries there are clearly gtk2 based. Was that intended? No, I made a mistake in my configure arguments. I put `--with-x=gtk3' instead of `--with-x-toolkit=gtk3', so emacs used the default gtk2. I'll rebuild it. Ken -- 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: Emacs problems after dbus (?) update
On 12/3/2011 10:17 AM, Jim Reisert AD1C wrote: On Sat, Dec 3, 2011 at 4:42 AM, Ken Brown wrote: (emacs:3380): GLib-GObject-WARNING **: Two different plugins tried to register 'BasicEngineFc'. Try removing /etc/pango/pango.modules . See http://cygwin.com/ml/cygwin-xfree/2011-11/msg00047.html Ken, that did fix the problem. Why did this just start happening (after the last update), and what's the long-term fix? At least if it comes back, I know what to do. This is just a minor glitch, related to the fact that Yaakov is gradually updating some packages that were updated long ago in Ports. [It's minor because emacs actually worked fine, in spite of all the warnings]. I'm sure he will get this all sorted out. I don't use Gnome - is there a way to uninstall the whole package, including Pango? emacs-X11 is built using the gtk toolkit. This is the upstream default for emacs, and I don't want to do something special for Cygwin unless there's a good reason. So emacs-X11 requires libgtk, which requires libpango. Ken -- 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: Emacs problems after dbus (?) update
On 12/3/2011 1:22 AM, Jim Reisert AD1C wrote: I updated Cygwin today, I think there was a dbus update. Now emacs-x11 is complaining: lrwxrwxrwx 1 Jim Reisert None 23 Aug 17 23:03 /usr/bin/emacs -> /etc/alternatives/emacs lrwxrwxrwx 1 Jim Reisert None 22 Aug 17 23:03 /etc/alternatives/emacs -> /usr/bin/emacs-X11.exe JJR:~> emacs (emacs:3380): GLib-GObject-WARNING **: Two different plugins tried to register 'BasicEngineFc'. (emacs:3380): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed (emacs:3380): Pango-WARNING **: Failed to load Pango module '/usr/lib/pango/1.6.0/modules/pango-basic-fc.dll' for id 'BasicScriptEngineFc' (emacs:3380): GLib-GObject-WARNING **: Two different plugins tried to register 'BasicEngineFc'. (emacs:3380): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed Try removing /etc/pango/pango.modules . See http://cygwin.com/ml/cygwin-xfree/2011-11/msg00047.html Ken -- 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: Problems with emacs built against gtk3
On 12/2/2011 5:35 AM, Yaakov (Cygwin/X) wrote: On Thu, 2011-12-01 at 18:04 -0500, Ken Brown wrote: On 11/30/2011 9:09 AM, Ken Brown wrote: On 11/29/2011 10:51 PM, Yaakov (Cygwin/X) wrote: This appears to be the same bug. The solution is to launch a DBus session bus *before* starting emacs (or any other gtk3 programs for that matter), IOW: $ eval `dbus-launch --sh-syntax` $ emacs-X11& That gets rid of the warning, but emacs still dies after a few seconds (no error message, no stackdump), unless I uninstall dconf-service. I'll see if I can get more information by running emacs under gdb. I'd appreciate any suggestions you might have as to where I should look. I have some further information: The problem is related to the GSettings backend. If I uninstall dconf-service and start emacs, I get a warning that the GSettings `memory' backend will be used. Emacs then works fine. If I reinstall dconf-service but set GSETTINGS_BACKEND=memory before starting emacs, it again works fine. Does this provide any clue as to what the problem might be? Okay, I got it. dconf-service needs a GVfs implementation, but the default provider (from the gvfs package) is currently only available in Ports. That's what I get for trying to be minimalistic wrt the distro. Of course, my gvfs package requires Avahi[1], so it may be an interesting ITP; I'll try to do that next week, and hopefully this thread will help expedite the review nonetheless. In the meantime, try setting the GIO_USE_VFS environment variable to "local"[2], which will allow dconf-service to work despite the lack of gvfs. (Why this isn't done automatically as a fallback, I have no idea.) This doesn't do it. Emacs still dies after a short time. I don't know if that means that there's something else going on, but I'll retest it after you package gvfs. In the meantime, I'll continue with my workaround of setting GSETTINGS_BACKEND=memory. In case you (or anyone else) wants to experiment with this, you can get my build of the emacs-24 pretest by running setup.exe -K http://www.math.cornell.edu/~kbrown/kbrown.gpg and adding http://www.math.cornell.edu/~kbrown to the list of mirrors. Ken -- 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: Problems with emacs built against gtk3
On 11/30/2011 9:09 AM, Ken Brown wrote: On 11/29/2011 10:51 PM, Yaakov (Cygwin/X) wrote: On Sat, 2011-11-26 at 08:40 -0500, Ken Brown wrote: On 11/25/2011 7:38 PM, Ken Brown wrote: When I build emacs against gtk3, it is unusable. Here are the symptoms when the resulting emacs is started in an xterm window: $ ./emacs -Q& [1] 3344 (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. ** (emacs:3344): WARNING **: Abnormal program termination spawning command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 --binary-syntax --close-stderr': I think the pango warning is Cygwin specific, but the rest of it might not be. Similar symptoms were reported on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=654027 This appears to be the same bug. The solution is to launch a DBus session bus *before* starting emacs (or any other gtk3 programs for that matter), IOW: $ eval `dbus-launch --sh-syntax` $ emacs-X11& That gets rid of the warning, but emacs still dies after a few seconds (no error message, no stackdump), unless I uninstall dconf-service. I'll see if I can get more information by running emacs under gdb. I'd appreciate any suggestions you might have as to where I should look. I forgot to say in my first post that the emacs I'm testing is a pretest of the upcoming emacs-24.1. If I'm not able to figure out what's going on, maybe I'll make an experimental version available so that you can try to reproduce the problem. I have some further information: The problem is related to the GSettings backend. If I uninstall dconf-service and start emacs, I get a warning that the GSettings `memory' backend will be used. Emacs then works fine. If I reinstall dconf-service but set GSETTINGS_BACKEND=memory before starting emacs, it again works fine. Does this provide any clue as to what the problem might be? Ken -- 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: Problems with emacs built against gtk3
On 11/29/2011 10:51 PM, Yaakov (Cygwin/X) wrote: On Sat, 2011-11-26 at 08:40 -0500, Ken Brown wrote: On 11/25/2011 7:38 PM, Ken Brown wrote: When I build emacs against gtk3, it is unusable. Here are the symptoms when the resulting emacs is started in an xterm window: $ ./emacs -Q& [1] 3344 (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. ** (emacs:3344): WARNING **: Abnormal program termination spawning command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 --binary-syntax --close-stderr': I think the pango warning is Cygwin specific, but the rest of it might not be. Similar symptoms were reported on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=654027 This appears to be the same bug. The solution is to launch a DBus session bus *before* starting emacs (or any other gtk3 programs for that matter), IOW: $ eval `dbus-launch --sh-syntax` $ emacs-X11& That gets rid of the warning, but emacs still dies after a few seconds (no error message, no stackdump), unless I uninstall dconf-service. I'll see if I can get more information by running emacs under gdb. I'd appreciate any suggestions you might have as to where I should look. I forgot to say in my first post that the emacs I'm testing is a pretest of the upcoming emacs-24.1. If I'm not able to figure out what's going on, maybe I'll make an experimental version available so that you can try to reproduce the problem. Ken -- 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: Problems with emacs built against gtk3
On 11/30/2011 6:54 AM, Yaakov (Cygwin/X) wrote: On Wed, 2011-11-30 at 11:17 +0100, Pavel Holejsovsky wrote: On 11/30/2011 4:51 AM, Yaakov (Cygwin/X) wrote: 2. The pango warning can already be observed with the current Cygwin emacs after the recent update of the GNOME libraries. To reproduce, install the emacs-X11 package and start emacs with the command `emacs&' in an xterm window. I cannot reproduce this. Does installing font-cantarell-otf help? Perhaps another font? I can reproduce it, in fact almost every gtk-enabled application spits that out. I tried stracing, and I think (but I'm not sure) that the warning appears after pango tries to load /usr/lib/pango/1.6.0/modules/pango-basic-fc.dll -> there is no /usr/lib/pango directory on my system, and it seems that no package in cygwin or ports repository provides it. That's the clue I needed. I switched pango to builtin modules over a year ago in Ports to help minimize fork() errors, but that didn't reach the distro until now. If I'm right, removing /etc/pango/pango.modules should fix it. That fixes it. Thanks. Ken -- 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: Problems with emacs built against gtk3
On 11/25/2011 7:38 PM, Ken Brown wrote: When I build emacs against gtk3, it is unusable. Here are the symptoms when the resulting emacs is started in an xterm window: $ ./emacs -Q& [1] 3344 (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. ** (emacs:3344): WARNING **: Abnormal program termination spawning command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 --binary-syntax --close-stderr': (emacs:3344): Pango-WARNING **: No such file or directory A few seconds later, emacs dies (the window disappears and the process is gone, with no error messages), and two dbus processes remain: $ ps | grep dbus 5188 1 3344 5188 7 1002 19:07:31 /usr/bin/dbus-launch 6452 1 6452 6452 ? 1002 19:07:31 /usr/bin/dbus-daemon If I start emacs again without killing the dbus processes, I don't get the first two warnings but I still get the third. Again, emacs dies after a few seconds. I think the pango warning is Cygwin specific, but the rest of it might not be. Similar symptoms were reported on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=654027 But there are some differences, so I thought I should report it here just in case part of the problem is Cygwin specific. My cygcheck output is attached but probably not relevant. Further info: 1. I don't think gtk3 is the culprit here after all. I uninstalled libgtk3_0 and libgtk3-devel and rebuilt emacs, but the problem persisted. It was only after uninstalling dconf-service (a dependency of libgtk3_0) that things went back to normal [except for the pango warning]. 2. The pango warning can already be observed with the current Cygwin emacs after the recent update of the GNOME libraries. To reproduce, install the emacs-X11 package and start emacs with the command `emacs &' in an xterm window. Ken -- 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: Cygwin xterm and emacs-X11 broken in Windows 7
[Removing the cygwin list from the CC.} On 10/26/2011 4:08 PM, Zdzislaw Meglicki wrote: [...] Perhaps related: in emacs-X11 entering the shell mode (M-x shell) kills the shell. I just get a prompt, then "exit" and a message Process shell finished This does *not* happen in emacs-nox, neither does this happen in xemacs. It works fine for me, so my best guess is that this is related to your other X problems. But you might try a recent Cygwin snapshot, on the off chance that that helps. There have been several changes that have an impact on processes running under emacs. Ken -- 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: Tried to fix "Doing vfork: resource temporarily unavailable" error with Emacs, now can't start X server
On 4/17/2011 6:30 PM, David M. Karr wrote: Cygwin 1.7.8 (and 1.7.9), Win7SP1. I was having issues with my Emacs startup occasionally failing with "Doing vfork: resource temporarily unavailable". I found a link that alleged to have the solution to this (http://blog.cottee.org/2008/05/cygwin-emacs-problems.html). The advice about libncurses on that page is obsolete. It applied to old versions of emacs. The suggestion of running rebaseall is good but... I followed these steps, although when I looked at "libncurses7", I saw it was set to "Skip", and that I had versions 8, 9, and 10. So, I set those to reinstall and continued the update. It also updated some other things, including updating me from Cygwin 1.7.8 to 1.7.9. you should try rebaseall now. Ken -- 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: Resizing problem
On 7/16/2010 12:10 AM, Olwe Melwasul wrote: On Thu, Jul 15, 2010 at 9:20 PM, Ken Brown wrote: I should have added that you should see /usr/share/doc/Cygwin/emacs.README for more information about that script and the shortcut it creates. Ken make-emacs-shortcut was in /bin. There was nothing in the .../README about it, though. README talked about a source code compile and install of Emacs. /bin and /usr/bin are the same (via mount) in Cygwin. If they appear different, then you're looking at them with non-Cygwin tools. And the README for emacs-23.2-1 does talk about make-emacs-shortcut. Under "Usage notes" it says: 2. The script /usr/bin/make-emacs-shortcut can be used to create a shortcut for starting emacs. As shipped, this shortcut starts emacs under X if an X server is running and in a mintty window otherwise. Edit it as desired. And a little further down it says: In addition, you will need cygutils in order to run the make-emacs-shortcut script described above, and you will need mintty and run2 to use the shortcut it creates. Ken -- 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: Resizing problem
On 7/15/2010 10:03 PM, Ken Brown wrote: On 7/15/2010 9:26 PM, Olwe Melwasul wrote: On Thu, Jul 15, 2010 at 4:20 PM, Ken Brown wrote: On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with ">emacs&" at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do "M-x shell" to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what "ls" or "which diff" or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken I started the X-server with the menu shortcut (which has the execute string you listed) and ... after ... a full minute it delivers a stand-alone xterm. I then click on the Emacs-X11, and after a long It sounds like you're using the Emacs-X11 start menu shortcut that's created by the X-start-menu-icons package. Don't use it. It doesn't set up the environment properly before starting emacs. To get a useful shortcut, you can use the script /usr/bin/make-emacs-shortcut that comes with the emacs package. I should have added that you should see /usr/share/doc/Cygwin/emacs.README for more information about that script and the shortcut it creates. Ken -- 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: Resizing problem
On 7/15/2010 9:26 PM, Olwe Melwasul wrote: On Thu, Jul 15, 2010 at 4:20 PM, Ken Brown wrote: On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with ">emacs&" at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do "M-x shell" to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what "ls" or "which diff" or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken I started the X-server with the menu shortcut (which has the execute string you listed) and ... after ... a full minute it delivers a stand-alone xterm. I then click on the Emacs-X11, and after a long It sounds like you're using the Emacs-X11 start menu shortcut that's created by the X-start-menu-icons package. Don't use it. It doesn't set up the environment properly before starting emacs. To get a useful shortcut, you can use the script /usr/bin/make-emacs-shortcut that comes with the emacs package. wait, it comes up. I do an M-x shell -- and get a "sh-3.2$" prompt. I try some commands, and it only seems to know a few. "cd" does get me to "/home/Olwe" which tells me it must have something to do with cygwin, but it knows no other GNU/cygwin other than perhaps "pwd". Next, I kill it and start Emacs-X11 in the xterm "emacs&". It comes up fine. I do M-x shell -- and get the identical prompt I got in xterm, namely, o...@olwe-pc $ I type commands and they work -- it sees the GNU/cygwin apps fine -- but it leaves odd characters after it returns, e.g. $ which diff /usr/bin/diff ^[]0;~^G This is ugly but harmless. It's an escape sequence that's part of the shell prompt, which is controlled by the PS1 environment variable. (In a normal shell, as opposed to one in emacs, you don't see it directly; I think it affects the color of the current directory, displayed as part of the prompt.) The last string is not random, it has some method to its madness. For example $ ls dbus-4xiZFwCMPa dbus-U6vB5c6MSd dbus-hdtwMyVbXA dbus-yXQ8LOSIN3 ]0;/tmp Actually, I copied the above output and lost the ^[ and the ^G, but they show up on the emacs shell output. Next, I kill emacs-X11 stand-alone and start emacs -nw in the xterm. Same funky characters. I try other consoles -- same funky characters. Again, the windowed mode doesn't have these problems, just the issues with minimized apps disappearing beyond the bottom of Openbox. If I could just get rid of the funky xterm characters, I'd call it a day Read about the PS1 environment variable in the bash manual (or google). Ken -- 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: Resizing problem
On 7/15/2010 3:51 PM, Olwe Melwasul wrote: Yes, I am using the emacs-X11 and yes, I started it (after starting the X server to get multiwindowed mode) with ">emacs&" at the cygwin command. Emacs-X11 comes up fine, looking good. Then I do "M-x shell" to get a shell environment inside of Emacs. But what comes up is not bash. I'm not sure what it is, but it sees no cygwin apps: It doesn't know what "ls" or "which diff" or any other GNU/cygwin stuff is. I assume it is the DOS shell. Oddly, if I start emacs-X11 inside the windowed mode (startx) and do emacs shell mode, it does see bash and the rest of the GNU/cygwin apps. [Please don't top-post.] I think the problem is that your PATH isn't set correctly inside emacs. How are you starting the X server? If you use the start menu shortcut (with target C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe) you shouldn't have that problem. Notice that it uses 'bash -l' precisely so that the environment, including PATH, is set up in the normal way. Ken -- 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: Resizing problem
On 7/15/2010 1:02 PM, Olwe Melwasul wrote: [...] Actually, I don't need the startx version, I could very well use the startxwin multi-windows version IF I could get Emacs in shell mode to do cygwin bash. Starting the X server and then Emacs multi-windows style gets a shell mode that apparently doesn't see cygwin. I'm guessing it's using the DOS command. I can't comment on the first part of your post, but I'm Cygwin's emacs maintainer and can try to help you get emacs running. If you want to run emacs under X, install the emacs-X11 package and then type 'emacs&' in an xterm window. If something doesn't work the way you expect, please give a precise recipe for reproducing the problem. I don't know what you mean by "a shell mode that apparently doesn't see cygwin". Ken -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 6/30/2010 1:40 PM, Jon TURNEY wrote: On 02/05/2010 21:52, 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. Thanks for the clear reproduction steps. And thanks to the other reporters of this problem :-) This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, 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? That seems to have fixed it. I've run it for several hours without any problems. Thanks. Ken -- 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 6/17/2010 4:20 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 has already been reported by many people. Until it gets fixed, you can work around it by reverting to xorg-server-1.7.6-2. Ken -- 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: [ANNOUNCEMENT] Updated: {xfig/xfig-lib}-3.2.5b-1
On 5/27/2010 6:07 PM, Angelo Graziosi wrote: Dr. Volker Zell wrote: > Angelo Graziosi writes: If I read correctly, if Fig* files exist in '/etc/X11/app-defaults', they are not replaced with new. That's correct. If somebody has changed the system defaults I don't want overide these. Hmm... I have not changed the system defaults: the Fig* files were put there (/etc/X11/app-defaults) by previous installation of XFig (3.2.4), which was the first I did for Cygwin-1.7. So, if now they are not overwritten and XFig complains about them, it looks a little strange. It's actually a preremove problem, not a postinstall problem. It looks like the previous xfig package was missing its preremove script, which would have removed the old Fig* files if they were unchanged from the defaults. The new xfig does have such a script, so this shouldn't be a problem in the future (assuming you manually copy the default files and don't change them). Ken -- 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: Slow response to keypresses in xorg-server-1.8.0-1
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. Ken -- 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: Font change in Gnu emacs/X11 following upgrade
On 4/29/2010 3:16 PM, Marc Girod wrote: Ken Brown-6 wrote: [This should have gone to the cygwin-xfree list. I've set the reply-to accordingly.] ... This is a result of the change in the default server DPI announced in http://cygwin.com/ml/cygwin-xfree-announce/2010-04/msg0.html As the announcement states, you may want to set Xft.dpi in your ~/.Xdefaults. Setting it to 75 will restore the previous font and frame sizes in emacs under X11. I repost, since nabble didn't obey the reply-to. Sounds simple and clear, but I do it, and get the same result...? 2009> ll ~/.Xdefaults -rw-r--r-- 1 emagiro EEI-ATusers 12 2010-04-29 19:18 /home/emagiro/.Xdefaults 2009> cat ~/.Xdefaults Xft.dpi: 75 I tried a smaller value (50), but no effect. I'm sorry, I had forgotten that I've been using a GTK+ build of emacs, which I'm testing in preparation for the upcoming release of emacs 23.2. My advice works for that build, but not for the current emacs-X11 package, which was built with Xaw. What if you just use a smaller font, for instance by putting the following in your ~/.Xdefaults: Emacs.font: Bitstream Vera Sans Mono-9 Ken -- 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: Font change in Gnu emacs/X11 following upgrade
[This should have gone to the cygwin-xfree list. I've set the reply-to accordingly.] On 4/29/2010 1:55 PM, Marc Girod wrote: Hello, I just upgraded for the first time for a few months. Starting my Gnu emacs under X11, I notice that my font (and frames) is larger than previously, by a factor ~1.5. I did record the following last October, and it stayed the same now: ~> cygcheck -c | egrep 'bitstream.*vera' font-bitstream-vera-ttf1.10-1 OK ~> xlsfonts | egrep -- '-bitstream-bitstream vera sans mono.*-iso.*-1$' -bitstream-bitstream vera sans mono-bold-o-normal--0-0-0-0-m-0-iso10646-1 -bitstream-bitstream vera sans mono-bold-o-normal--0-0-0-0-m-0-iso8859-1 -bitstream-bitstream vera sans mono-bold-r-normal--0-0-0-0-m-0-iso10646-1 -bitstream-bitstream vera sans mono-bold-r-normal--0-0-0-0-m-0-iso8859-1 -bitstream-bitstream vera sans mono-medium-o-normal--0-0-0-0-m-0-iso10646-1 -bitstream-bitstream vera sans mono-medium-o-normal--0-0-0-0-m-0-iso8859-1 -bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso10646-1 -bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso8859-1 With list-fontsets in the *Help* buffer: Fontset: -*-*-*-*-*-*-*-*-*-*-*-*-fontset-default Fontset: -*-fixed-medium-r-normal-*-16-*-*-*-*-*-fontset-standard Fontset: -bitstream-Bitstream Vera Sans Mono-normal-normal-normal-*-12-*-*-*-m-0-fontset-startup The X server greets me with a new identity: Vendor: The Cygwin/X Project Release: 1.8.0.0 (1080) Build Date: 2010-04-02 I join my cygcheck output. Any explanation and quick fix? Thanks, Marc http://old.nabble.com/file/p28403800/cygcheck.100429 cygcheck.100429 This is a result of the change in the default server DPI announced in http://cygwin.com/ml/cygwin-xfree-announce/2010-04/msg0.html As the announcement states, you may want to set Xft.dpi in your ~/.Xdefaults. Setting it to 75 will restore the previous font and frame sizes in emacs under X11. Ken -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On 4/14/2010 5:24 AM, Markus Hoenicka wrote: Dan Tsafrir was heard to say: I wasn't able to strace emacs, but I am able to strace xclock (brining it up, which when strace-ing takes several long minutes on my netbook, and then immediately killing it). Neither was I. I always get this error (the error number is variable though): strace: error creating process emacs, (error 2) That's because /usr/bin/emacs is a symlink. Try straceing emacs-X11. Ken -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
On 4/12/2010 7:52 PM, Dan Tsafrir wrote: On Tue, Apr 6, 2010 at 00:39, Jon TURNEY wrote: I've conducted a few repeated measurements and it looks as though setting LANG to be en_US somewhat reduces the start time of emacs-x11: instead of ~30 seconds with LANG=C.UTF-8, it take ~27 seconds LANG=en_US. While this is ~10% less, waiting 27 seconds for emacs to open still seems unreasonable. Any other ideas? Hmm You don't have any emacs fonts being set via ~/.Xdefaults or ~/.Xresources? Actually, I do. However, following the suggestion of Ken Brown http://www.mail-archive.com/cyg...@cygwin.com/msg107126.html I've invoked emacs with -Q (and also, just to make sure, removed my ~/.Xdefaults). It did not change anything: emacs still takes ~30 seconds to open. It still might be font related. You mentioned earlier in the thread that you installed all available font packages. Do you have a very large ~/.fontconfig directory as a result? Maybe emacs has to process this every time it starts up. (I'm not sure.) What if you delete this directory and do a minimal Cygwin install without so many fonts? I think the first time you start emacs it may call fc-cache to populate ~/.fontconfig, but after that it might start faster. Ken -- 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: Keyboard and start options problems
On 4/7/2010 1:31 PM, Denis Beauchemin wrote: I also have a problem with my start icon that doesn't seem to pick up my custom parameters. The command is: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -xkblayout ca -xkbvariant fr -emulate3buttons The layout is always US and the 3 button emulation doesn't work either. You need to quote the part after -c, and you're also missing a '--' (see the startxwin documentation). Try C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe -- -xkblayout ca -xkbvariant fr -emulate3buttons' Ken -- 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: problems starting xterm
On 3/19/2010 11:40 AM, Markus Hoenicka wrote: Markus Hoenicka mumbled: As this method to start xterm seems to work, do I have to start the X server some other way than I do now? I just use the Win start menu entry Cygwin-X->XWin Server. I can answer that one myself. Running startxwin from mintty works without a hitch. This is no big deal for me, but this still leaves me wondering why one of the officially recommended ways to start X (as per the docs, see http://x.cygwin.com/docs/ug/using.html#using-starting) fails on my system. Does your CYGWIN environment variable contain tty? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-startxwin-no-windows -- 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: Problems Starting Xterm using the System Tray Icon for XWin Server
On 2/18/2010 7:13 AM, Craig Moore wrote: When I open a new xterm window using the XWin Server icon in the system tray: (right click on icon)->Applications->xterm it opens xterm, but the command prompt is not formatted correctly and the window title is 'xterm' instaed of the current directory. The command prompt looks like: bash-3.2$ and should be cr...@laptop ~ $ How do I configure the XWin Server so that it opens xterm correctly? This happens because xterm doesn't start a login shell, and PS1 gets unset. One way around this is to set PS1 in your ~/.bashrc file. For example: PS1='\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' Also, is there a way I can add a shortcut on my desktop to open a new terminal window without having to type 'xterm' in the existing terminal window or the system tray icon? I use a shortcut with target C:\cygwin\bin\run.exe /usr/bin/xterm -ls -display 127.0.0.1:0.0 Ken -- 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 start xterm from Cygwin/X icon in system tray
On 12/31/2009 10:53 AM, john at asyn dot org wrote: On Thu, 31 Dec 2009, Jim Reisert AD1C wrote: Jim Reisert AD1C wrote: I am unable to start an xterm from the Cygwin/X icon in the system tray (right-click, select xterm). Both setups have the same line in .XWinrc: "xterm" EXEC "xterm" As a work-around, I created a shortcut on my desktop to start an xterm: D:\Cygwin\bin\run.exe /usr/bin/xterm -display localhost:0 That works perfectly, [...] I tried this explicitly: "xterm" EXEC "xterm -display localhost:0" That didn't make a difference. One other piece of data: I modifed ~/.XWinrc and then clicked "Reload .xwinrc" from the menu in the system tray. This KILLED the X server! > > I had this problem. It was happening because PATH was not being set. > The problem went away when I used /startxwin.bat instead of > /bin/startxwin.exe. If PATH is not being set, then you're probably not running startxwin.exe from a login shell. See http://cygwin.com/ml/cygwin-xfree/2009-12/msg00117.html Ken -- 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/
Should xterm require xbitmaps?
After putting "XTerm*scrollBar: true" into my .Xdefaults, I started getting a new xterm warning: Warning: Cannot convert string "vlines2" to type Pixmap The cause is the following line in /etc/X11/app-defaults/ XTerm-color: *VT100.scrollbar.thumb: vlines2 and the vlines2 pixmap is in the xbitmaps package. Should xterm require xbitmaps? Ken -- 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: GSlice problem with emacs Gtk+ build
On 12/7/2009 2:13 PM, Yaakov (Cygwin/X) wrote:
On 07/12/2009 10:06, Ken Brown wrote:
There's a known workaround, which is to set G_SLICE=always-malloc before
starting emacs. As emacs maintainer, I've been reluctant to provide the
Gtk+ version of emacs, because I don't want to answer hundreds of emails
telling people about the workaround. I could supply a wrapper script
that sets G_SLICE, but I'm still afraid that would cause a lot of
confusion; I suspect many people are in the habit of calling
emacs-X11.exe directly. I have therefore configured the emacs-X11
package to use Xaw instead of Gtk+. But Gtk+ is really much nicer, and I
would like to be able to provide an emacs-X11 that uses it.
What about adding to the beginning of main():
#ifdef __CYGWIN__
setenv("G_SLICE", "always-malloc", 1);
#endif
Thanks, Yaakov! I was looking for more complicated solutions and never
thought of the easy one. That fixes it.
Ken
--
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/
GSlice problem with emacs Gtk+ build
There's been a longstanding problem with emacs if it is configured to use Gtk+ in Cygwin. The relevant threads begin here: http://cygwin.com/ml/cygwin/2006-07/threads.html#00823 http://cygwin.com/ml/cygwin/2007-02/threads.html#00469 http://cygwin.com/ml/cygwin/2007-02/threads.html#00503 Briefly, the problem is the following (quoted from the emacs etc/PROBLEMS file): "Emacs supplies its own malloc, but glib (part of Gtk+) calls memalign and on Cygwin, that becomes the Cygwin supplied memalign. As malloc is not the Cygwin malloc, the Cygwin memalign always returns ENOSYS." The symptom is that emacs crashes with an error message like the following: ***MEMORY-ERROR***: [2428]: GSlice: failed to allocate 120 bytes (alignment: 128): Function not implemented Fatal error (6)Aborted (core dumped) There's a known workaround, which is to set G_SLICE=always-malloc before starting emacs. As emacs maintainer, I've been reluctant to provide the Gtk+ version of emacs, because I don't want to answer hundreds of emails telling people about the workaround. I could supply a wrapper script that sets G_SLICE, but I'm still afraid that would cause a lot of confusion; I suspect many people are in the habit of calling emacs-X11.exe directly. I have therefore configured the emacs-X11 package to use Xaw instead of Gtk+. But Gtk+ is really much nicer, and I would like to be able to provide an emacs-X11 that uses it. At the time this was first discussed, Cygwin did not have an X maintainer. Now that we have Jon and Yaakov actively providing Cygwin/X support, I wonder if it would be possible to revisit the issue and try to fix the problem. For example, might it be as simple as patching the Cygwin port of glib to achieve the same effect as setting G_SLICE=always-malloc? Ken -- 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: 1.7 - what's the right way to start X?
On 12/4/2009 11:12 AM, Fredrik Staxeng wrote: I have seen this problem before, and the solution was to run rebaseall, which broke emacs, and then reinstall libncurses to fix emacs. Is this the way to do it? Will it still break emacs? I haven't seen any reports of emacs problems in 1.7 after rebasing. Ken Brown Cygwin's emacs maintainer -- 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: X11R7.5 and C.UTF-8
On 11/28/2009 8:34 AM, Andy Koppe wrote: 2009/11/28 Ken Brown: On 10/28/2009 6:07 PM, Andy Koppe wrote: 2009/10/28 Ken Brown: Maybe my terminology is wrong. But if you start mintty with no .minttyrc and with LANG unset, mintty will set LANG=C.UTF-8. Yep. That's primarily for emacs' benefit, which parses the locale env variables itself instead of using setlocale(LC_CTYPE, ""), thereby missing out on Cygwin's default locale. Andy, I've sent a report about this to the emacs-devel list (http://lists.gnu.org/archive/html/emacs-devel/2009-11/threads.html#01216). But I don't have a good understanding of locale issues. Could you take a look and see if what I said is accurate or if more should be said? Thanks Ken, I think you've got that all correct, including pointing the finger at mule-cmds.el as the suspect. I'll keep an eye on that thread. One more thing that might be worth mentioning is 'nl_langinfo(CODESET)' for enquiring about the character encoding. (It's actually being used in a couple of places in the emacs sources already, in fns.c and w32proc.c, but I don't know what significance those files have.) w32proc.c doesn't get compiled in the Cygwin build, but fns.c does. The call to nl_langinfo(CODESET) is in the definition of the locale-info function, which provides a way for emacs to determine the CODESET. I've passed this on to the emacs-devel list. Thanks for the help. Ken -- 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: X11R7.5 and C.UTF-8
On 10/28/2009 6:07 PM, Andy Koppe wrote: 2009/10/28 Ken Brown: Maybe my terminology is wrong. But if you start mintty with no .minttyrc and with LANG unset, mintty will set LANG=C.UTF-8. Yep. That's primarily for emacs' benefit, which parses the locale env variables itself instead of using setlocale(LC_CTYPE, ""), thereby missing out on Cygwin's default locale. Andy, I've sent a report about this to the emacs-devel list (http://lists.gnu.org/archive/html/emacs-devel/2009-11/threads.html#01216). But I don't have a good understanding of locale issues. Could you take a look and see if what I said is accurate or if more should be said? Thanks. Ken -- 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: checkX problems
On 11/26/2009 2:30 AM, Lothar Brendel wrote: Errh, yes. Hence, to make Cygwin/X+xterm run out of the box (using the start menu shortcut), you have to install the CJK fonts. One more noob-question, sorry: Which font-package does provide "the CJK fonts"? I tried several ones but up to now in vain. There are three packages: font-isas-misc, font-jis-misc, and font-daewoo-misc. -- 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: Problem with new xinit - console window doesn't open (but bash starts)
On 11/25/2009 9:57 AM, Charles Wilson wrote: Jon TURNEY wrote: This is typical of the current issue we have where 'run xterm' blocks when xterm tries to output 'Warning: Missing charsets in String to FontSet conversion' Any one of: - installing the CJK fonts - having 'tty' in the CYGWIN environment variable - having the LANG environment set to a non-UTF-8 locale should work around this problem Note that the environment variable will have to be set via the system applet in the Windows control panel, as only that controls the environment for the startxwin.bat started from the start menu... There's another option. In startxwin.bat, you could use run2.exe instead of run. Instead of: %RUN% bash -l -c "XWin -multiwindow -clipboard -silent-dup-error" Use %RUNTWO% /usr/bin/XWin.xml where XWin.xml is something like the following (untested): http://www.w3.org/2001/XMLSchema-instance"; xsi:noNamespaceSchemaLocation="run2.xsd"> -l -c "XWin -multiwindow -clipboard -silent-dup-error" You can also just use the DOS "set" command right in startxwin.bat. In the case of CYGWIN, the syntax would be SET CYGWIN=%CYGWIN% tty Ken -- 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: checkX problems
On 11/25/2009 8:18 AM, Charles Wilson wrote: Lothar Brendel wrote: * After again inserting a sleep between checkXing and starting the xterm, the latter is marginally successful: The process is shown as running but no xterm is showing up :-( That's an xterm/XWin issue. And it's been discussed in several recent threads. A summary of workarounds can be found in http://cygwin.com/ml/cygwin-xfree/2009-11/msg00174.html Ken -- 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: checkX problems
On 11/20/2009 2:47 PM, Gertjan van Noord wrote: On Fri, Nov 20, 2009 at 02:43:11PM -0500, Ken Brown wrote: On 11/20/2009 12:14 PM, Charles Wilson wrote: I've integrated Lothar's patch into run2/checkX (along with some other internal changes), and published a test release. Please try run-0.3.1-1 and let me know if it fixes your problems with checkX. I still have the instability that I reported as problem #2 in http://cygwin.com/ml/cygwin-xfree/2009-10/msg00143.html but I wasn't expecting you to fix that. As I said later in the thread, I suspect BLODA. But the new behavior of the timeout option (my problem #1) works fine, with one caveat: If I start the X server with startxwin.bat, it immediately exits and claims that a server is already running. This was also reported earlier today by Jim Reisert: http://cygwin.com/ml/cygwin-xfree/2009-11/msg00158.html Could it be that checkX is tricking XWin into thinking that a different X server is running? (I have no idea how XWin decides whether an X server is running, so this may or may not be plausible.) Strangely, the problem doesn't occur if I use startxwin.sh instead of startxwin.bat. has it something to do with the -wait option to checkX that is present in the startxwin.bat? I had to remove that option, since it broke the start of the X server. And I now note it is not in the bash version. If you remove -wait but still start checkX with run, then you might as well not use checkX at all. (run will return immediately, leaving checkX running in the background.) Ken -- 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: checkX problems
On 11/20/2009 12:14 PM, Charles Wilson wrote: I've integrated Lothar's patch into run2/checkX (along with some other internal changes), and published a test release. Please try run-0.3.1-1 and let me know if it fixes your problems with checkX. I still have the instability that I reported as problem #2 in http://cygwin.com/ml/cygwin-xfree/2009-10/msg00143.html but I wasn't expecting you to fix that. As I said later in the thread, I suspect BLODA. But the new behavior of the timeout option (my problem #1) works fine, with one caveat: If I start the X server with startxwin.bat, it immediately exits and claims that a server is already running. This was also reported earlier today by Jim Reisert: http://cygwin.com/ml/cygwin-xfree/2009-11/msg00158.html Could it be that checkX is tricking XWin into thinking that a different X server is running? (I have no idea how XWin decides whether an X server is running, so this may or may not be plausible.) Strangely, the problem doesn't occur if I use startxwin.sh instead of startxwin.bat. Thanks to Lothar and you for the timeout patch. Ken -- 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: Problem with new xinit - console window doesn't open (but bash starts)
On 11/19/2009 11:07 PM, Jim Reisert AD1C wrote: More info: If I run startxwin.bat from a CMD.exe command line, the bash console xterm opens just fine. I only have problems starting it from the shortcut. I do see some interesting things in the log file, however: [...] Warning: Missing charsets in String to FontSet conversion Try installing the font-isas-misc, font-jis-misc, and font-daewoo-misc packages. See http://cygwin.com/ml/cygwin-xfree/2009-11/msg00111.html http://cygwin.com/ml/cygwin-xfree/2009-11/msg00117.html Ken -- 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: 'run xterm' fails to open a window
On 11/12/2009 10:14 PM, Ken Brown wrote: Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion [...] It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Never mind. I found the answer in a different thread: http://cygwin.com/ml/cygwin-xfree/2009-11/msg00085.html The workaround is to install the font-isas-misc, font-jis-misc, and font-daewoo-misc packages. Ken -- 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: 'run xterm' fails to open a window
On 11/12/2009 3:17 PM, Jon TURNEY wrote: On 10/11/2009 23:44, Mike Ayers wrote: On Behalf Of jean-luc malet Sent: Monday, November 09, 2009 2:50 AM no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... To find out why this is, run gvim from an xterm: [SNIP] m-ayers-lap> gvim (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD m-ayers-lap> (gvim:1092): Pango-WARNING **: Error loading GPOS table 0x6EAD [/SNIP] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mike>C:\cygwin\bin\run.exe -p /usr/bin sh -c "gvim>/dev/null 2>&1" C:\mike> [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion When I start xterm via run, this message apparently has nowhere to go and the xterm process is blocked. Mike's workaround (with 'gvim' replaced by 'xterm') solves the problem, as he said. Is this a bug in run? It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Ken -- 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: checkX problems
On 11/12/2009 4:31 PM, Jon TURNEY wrote: On 30/10/2009 13:48, Ken Brown wrote: 2. If I start the X server by using the default startxwin.bat or startxwin.sh (both of which call checkX), the server is very unstable and crashes within a few minutes. This happens consistently, and it never happens if I comment out the line calling checkX. I think I was able to reproduce this problem (it is not how I normally start the X server) However, now I come back to look at this in detail, the problem no longer seems to exist. Are you still able to demonstrate it? Yes, it's still reproducible on one machine (the one for which I sent cygcheck output in my original post), but the problem doesn't occur on a second machine that I sometimes use. And I don't think anyone else has reported this problem. So I guess it must be BLODA or some other peculiarity of the one system. Ken -- 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/
checkX problems
I'm having trouble with checkX. I haven't seen other people complain about this, so I assume it's something about my system, but I can't figure out what. There are two symptoms: 1. If I run checkX with a timeout, the timeout seems to be ignored. For example, with the X server *not* running: $ checkX -d 127.0.0.1:0.0 -t 100 --debug checkX.exe DEBUG: displayname : '127.0.0.1:0.0' checkX.exe DEBUG: opt_location: 0 checkX.exe DEBUG: opt_loglevel: 7 checkX.exe DEBUG: opt_nogui : 0 checkX.exe DEBUG: opt_notty : 0 checkX.exe DEBUG: opt_timeout : 100.00 checkX.exe DEBUG: (adjust_path) path is : /usr/local/texlive/2009/bin/i386-cygwin:/usr/local/bin:/usr/bin:/c/Program Files/ThinkPad/Utilities:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/Intel/Wireless/Bin/:/c/Program Files/IBM ThinkVantage/Client Security Solution:/c/Program Files/ThinkPad/ConnectUtilities:/c/Program Files/QuickTime/QTSystem/:/c/Program Files/Common Files/Lenovo:/usr/lib/lapack:/usr/X11R6/bin:/usr/bin checkX.exe DEBUG: (find_X11_lib) DLL is /usr/bin/cygX11-6.dll checkX.exe DEBUG: (dlopen_X11_lib) /usr/bin/cygX11-6.dll dlopen'ed successfully. checkX.exe DEBUG: (load_X11_symbols) symbol XOpenDisplay loaded ok checkX.exe DEBUG: (load_X11_symbols) symbol XCloseDisplay loaded ok checkX.exe DEBUG: (try_with_timeout) Using delay of 100 secs, 0 nanosecs (100.00) checkX.exe DEBUG: (try_with_timeout) xserver search was unsuccessful checkX.exe Info: could not open X display '127.0.0.1:0.0' checkX.exe DEBUG: returning with status 1 checkX.exe Info: Exiting with status 1 The problem is that it returns within a second, in spite of the timeout. Or am I misunderstanding what the timeout is supposed to do? 2. If I start the X server by using the default startxwin.bat or startxwin.sh (both of which call checkX), the server is very unstable and crashes within a few minutes. This happens consistently, and it never happens if I comment out the line calling checkX. I tried strace'ing checkX, but I don't know what to look for in the output. (I'll send it if it would be useful, but I don't want to spam the list otherwise.) I'm attaching cygcheck output. Ken Cygwin Configuration Diagnostics Current System Time: Fri Oct 30 14:28:07 2009 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: D:\cygwin-1.7\usr\local\texlive\2009\bin\i386-cygwin D:\cygwin-1.7\usr\local\bin D:\cygwin-1.7\bin C:\Program Files\ThinkPad\Utilities C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Intel\Wireless\Bin\ C:\Program Files\IBM ThinkVantage\Client Security Solution C:\Program Files\ThinkPad\ConnectUtilities C:\Program Files\QuickTime\QTSystem\ C:\Program Files\Common Files\Lenovo D:\cygwin-1.7\lib\lapack Output from D:\cygwin-1.7\bin\id.exe (nontsec) UID: 1007(kbrown-admin) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) 544(Administrators) 545(Users) 513(None) Output from D:\cygwin-1.7\bin\id.exe (ntsec) UID: 1007(kbrown-admin) GID: 513(None) 0(root) 544(Administrators) 545(Users) 513(None) 544(Administrators) 545(Users) 513(None) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'kbrown-admin' PWD = '/home/kbrown-admin' HOME = '/home/kbrown-admin' HOMEPATH = '\Documents and Settings\kbrown-admin' MANPATH = '/usr/local/texlive/2009/texmf/doc/man:/usr/local/share/man:usr/local/man:/usr/share/man:/usr/man:/usr/ssl/man' APPDATA = 'C:\Documents and Settings\kbrown-admin\Application Data' HOSTNAME = 'markov' RR = 'C:\Program Files\IBM ThinkVantage\Rescue and Recovery' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 14 Stepping 8, GenuineIntel' WINDIR = 'C:\WINDOWS' TVTPYDIR = 'C:\Program Files\IBM ThinkVantage\Common\Python24' TVT = 'C:\Program Files\Lenovo' OLDPWD = '/usr/bin' USERDOMAIN = 'MARKOV' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' !:: = '::\' TEMP = '/c/DOCUME~1/KBROWN~1/LOCALS~1/Temp' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' G_SLICE = 'always-malloc' QTJAVA = 'C:\Program Files\Java\jre1.6.0_02\lib\ext\QTJava.zip' USERNAME = 'kbrown-admin' PROCESSOR_LEVEL = '6' TPCCommon = 'C:\PROGRA~1\THINKV~2\PrdCtr' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\kbrown-admin' TZ = 'America/New_York' PS1 = '\[\e]0;\w\a\]\n\[\e[32m\...@\h \[\e[33m\]\w\[\e[0m\]\n\$ ' LOGONSERVER = '\\MARKOV' HISTIGNORE = '[ ]*:&:bg:fg:exit' PROCESSOR_ARCHITECTURE = 'x86' HISTCONTROL = 'ignoredups' SHLVL = '1' SMA = 'C:\Program Files\ThinkVantage\SMA\' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/c/DOCUME~1/KBROWN~1/LOCALS~1/Temp' SYSTEMROOT = 'C:\WINDOWS' IBMSHARE = 'C:\IBMSHARE' PRINTER = 'HP LaserJet 2100 PCL6' CVS_RSH = '/bin/
Re: X11R7.5 and C.UTF-8
On 10/29/2009 9:42 AM, Jon TURNEY wrote: On 29/10/2009 00:07, Andy Koppe wrote: 2009/10/28 Jon TURNEY: On 28/10/2009 14:22, Ken Brown wrote: X11R7.5 doesn't like the (default) locale C.UTF-8. If I start the server with 'LANG=C.UTF-8 /usr/bin/startxwin.bat', the server exits immediately, and the log has complaints about the locale. If I instead use 'LANG=en_US.UTF-8', there's no problem. I've attached both logs and cygcheck output. Thanks for the bug report. I'm afraid I'm not immediately able to reproduce this, though, using the command you give. You might have LC_ALL or LC_CTYPE set, which would override LANG. Or perhaps startxwin.bat overrides things somewhere along the way? To avoid all that, you could try invoking Xwin directly with LC_ALL set, which is top dog among locale variables. LC_ALL=C.UTF-8 xwin -multiwindow& It fails with en.UTF-8 too (which also is a legal Cygwin locale), but it works with en_US.UTF-8. Nope, I don't have LC_ALL or LC_CTYPE set This is pretty curious, since all XSupportsLocale() should be doing effectively is checking if setlocale (LC_ALL, NULL) returns a name it understands. Perhaps you can try the attached small test program. $ LANG=C.UTF-8 ./Xlocale.exe Setting locale from LANG succeeded Locale is C.UTF-8 XSupportsLocale returned false $ LANG=en_US.UTF-8 ./Xlocale.exe Setting locale from LANG succeeded Locale is en_US.UTF-8 XSupportsLocale returned true $ unset LANG $ ./Xlocale.exe Setting locale from LANG succeeded Locale is C XSupportsLocale returned true $ uname -a CYGWIN_NT-5.1 markov 1.7.0(0.214/5/3) 2009-10-03 14:33 i686 Cygwin Ken -- 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: X11R7.5 and C.UTF-8
On 10/28/2009 5:23 PM, Thomas Dickey wrote:
On Wed, 28 Oct 2009, Ken Brown wrote:
X11R7.5 doesn't like the (default) locale C.UTF-8. If I start the server
technically speaking, there's "no such locale" as C.UTF-8,
so I'd not expect portable code to accept it ("C" and "UTF-8" are
mutually exclusive).
Maybe my terminology is wrong. But if you start mintty with no
.minttyrc and with LANG unset, mintty will set LANG=C.UTF-8. Trying to
then start the X server via startxwin.bat or startxwin.sh leads to the
error I reported. The error did not occur in X11R7.4.
There's been a lot of discussion in the various cygwin lists leading to
the decision that C.UTF-8 should be the default.
Ken
--
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: startxwin.bat and checkX
On 10/16/2009 10:39 AM, Ken Brown wrote: I don't think the line %RUN% checkX -d %DISPLAY% -t 12 in startxwin.bat accomplishes anything, because run.exe returns immediately, and checkX runs in the background. From 'man run': run [ -p path ] command [ -wait ] arguments [...] Issuing -wait as first program argument will make run wait for program completition, otherwise it returns immediately. [Chuck: Note the typo in "completition".] So I think startxwin.bat should use %RUN% checkX -wait -d %DISPLAY% -t 12 Even better, why bother with run.exe at all? Why not just use %CYGWIN_ROOT%\bin\checkX -d %DISPLAY% -t 12 Ken -- 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/
startxwin.bat and checkX
I don't think the line %RUN% checkX -d %DISPLAY% -t 12 in startxwin.bat accomplishes anything, because run.exe returns immediately, and checkX runs in the background. From 'man run': run [ -p path ] command [ -wait ] arguments [...] Issuing -wait as first program argument will make run wait for program completition, otherwise it returns immediately. [Chuck: Note the typo in "completition".] So I think startxwin.bat should use %RUN% checkX -wait -d %DISPLAY% -t 12 I've tested this on my system, and xterm always starts. If I omit '-wait', xterm sometimes doesn't start. Ken -- 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: [ANNOUNCEMENT] [1.7] Updated: xorg-server-1.6.4-1
On 10/9/2009 9:56 AM, Jon TURNEY wrote: On 08/10/2009 22:47, Ken Brown wrote: On 10/8/2009 5:25 PM, Jon TURNEY wrote: But looking at PS1 to determine if you have a login shell in your ancestry doesn't work, as PS1 gets unset by non-interactive bash shells. (This is something which I have learnt today :-) So attempting to set PS1 in /etc/profile and inherit it everywhere isn't going to work. OK, thanks for the explanation. I still think you should consider using 'xterm -ls' in system.XWinrc, because I think most users are going to want to see their usual prompt when they start an xterm. I agree that users should get their usual prompt in an Xterm. This is not a problem limited to X, though: You can demonstrate it just by doing 'bash -c bash' I believe a solution would be to move the PS1 setting code from /etc/profile to /etc/bash.bashrc, causing it to be set for all interactive shells. This doesn't quite work, at least with the default bash initialization files. The problem is that /etc/bash.bashrc is invoked by ~/.bash_profile, which is only run in login shells. But setting PS1 in ~/.bashrc seems to work. Alternatively, one could move the code that invokes /etc/bash.bashrc from ~/.bash_profile to ~/.bashrc. Ken -- 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/
