Cygwin 1.7.6-1 , Windows 7: STATUS_ACCESS_VIOLATION
Hi, I have installed Cygwin 1.7.6-1 on "Windows 7" running on a virtual machine (VMware Workstation 6.5.4). I am using TCSH instead of BASH and I have configured an X11 GUI which I use since 2004 with Cygwin 1.5.x (since about a year with X11R7) on Windows XP without problems. When I use this environment with Cygwin 1.7.6, I have the following problems. I have seen in the mailing list that other persons have similar problems, but I have not found a solution. Perhaps I have some additional information which can track the problem. Sometimes I get only one xterm-window or the background color of the root window will only be painted in the upper part or not all. Most times I get no xterm-window, when I left-click in the root window of the window manager "fvwm2" and choose "xterm". In these cases I get for example the following error messages in the original console window from Cygwin. 8 [main] fvwm 3168 exception::handle: Exception: STATUS_ACCESS_VIOLATION 101981 [main] fvwm 3168 open_stackdumpfile: Dumping stack trace to fvwm.exe.stackdump 8 [main] xterm 468 exception::handle: Exception: STATUS_ACCESS_VIOLATION 1591 [main] xterm 468 open_stackdumpfile: Dumping stack trace to xterm.exe.stackdump I close and restart Cygwin in these cases until I get the expected user interface with two "xterm windows". The problem remains even if I disable "Windows Firewall". Sometimes Cygwin repaints only the upper part of the graphical user interface when I close Cygwin to an icon and reopen the icon. When I move with the mouse cursor over the unpainted parts (contents of "xterm windows" or the background of the "root window") the area under the mouse pointer will be repainted (like a brush). Sometimes all missing parts are automatically repainted when I execute a command. The access violation is not restricted to "xterm". tyr x 135 cat fvwm_1.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610200B7 eax=00C3F870 ebx=6123DC54 ecx=7514783F edx=003E4118 esi= edi=0022FA14 ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\fvwm.exe, pid 2356, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args End of stack trace tyr x 136 diff fvwm_1.exe.stackdump fvwm_2.exe.stackdump 2,3c2,3 < eax=00C3F870 ebx=6123DC54 ecx=7514783F edx=003E4118 esi= edi=0022FA14 < ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\fvwm.exe, pid 2356, thread main --- > eax=00C347C0 ebx=6123DE2C ecx=7574783F edx=00264118 esi= edi=0022FA14 > ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\fvwm.exe, pid 2312, thread > main tyr x 137 cat xterm_1.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610200B7 eax=00B900F8 ebx=6123E374 ecx=75B9783F edx=003E4118 esi= edi=0022FA14 ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 2104, thread main cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args End of stack trace tyr x 138 diff xterm_1.exe.stackdump xterm_2.exe.stackdump 2,3c2,3 < eax=00B900F8 ebx=6123E374 ecx=75B9783F edx=003E4118 esi= edi=0022FA14 < ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 2104, thread main --- > eax=00AD00F8 ebx=6123E694 ecx=7574783F edx=003D4118 esi= edi=0022FA14 > ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 4000, thread > main tyr x 139 diff xterm_1.exe.stackdump xterm_3.exe.stackdump 2,3c2,3 < eax=00B900F8 ebx=6123E374 ecx=75B9783F edx=003E4118 esi= edi=0022FA14 < ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 2104, thread main --- > eax=00D100F8 ebx=6123E50C ecx=7574783F edx=002D4118 esi= edi=0022FA14 > ebp=61020800 esp=0022C7E4 program=C:\cygwin\bin\xterm.exe, pid 2788, thread > main tyr x 140 tyr x 141 cat id.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610BFE94 eax= ebx=18EC ecx=0010 edx=67F054B2 esi=67F0B000 edi=0001 ebp=18EBFD9C esp=18EBFD74 program=C:\cygwin\bin\id.exe, pid 3944, thread unknown (0xE5C) cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: Frame Function Args 18EBFD9C 610BFE94 (67F0B000, 67F05550, 18EBFE1C, 6102001A) 18EBFDAC 67F010D9 (61161D98, 6123A424, 6123A424, 610205E0) 18EBFE1C 6102001A (67F0, , 0001, 005C23A0) 18EBFE3C 76EEAFC4 (67F08920, 67F0, , 0001) 18EBFEE0 76EF38DA (, 0002, , 18EBFF88) 18EBFEF4 76EF384D (, 7666D513, 0002, C4B334DF) 18EBFF88 7666D358 (0002, 18EBFFD4, 76EEB495, 0002) 18EBFF94 76611194 (0002, 6E0A380C, , ) 18EBFFD4 76EEB495 (7666D35E, 0002, , ) 12 [unknown (0xE5C)] id 3944 exception::handle: Error while dumping state (probably corrupted stack) tyr x 142 cat tcsh.exe.stackdump Exception: STATUS_ACCESS_VIOLATION at eip=610BFE94 eax= ebx=008A ecx=0010 edx=67F054B2 esi=67F0B000 edi=0001 ebp=0089FD9C esp=0089FD74 pro
Re: was "missing fonts?" in cyg...@cygwin.com
> Siegmar Gross wrote: > >> I have upgraded Cygwin to X11R7.4. In the past I could read my e-mail > >> via "ssh" and "dtmail" from a Solaris machine with a nice font. Now I > > I assume there are some warnings emitted by dtmail when it starts indicating > that it can't use the font it wants to use? I would be interested to know > exactly what it says. Yes, I get the following output on the Solaris machine. tyr fd1026 69 /usr/dt/bin/ttsession -c dtmail libSDtMail: Warning: Xt Warning: Missing charsets in String to FontSet conversion libSDtMail: Warning: Xt Warning: Cannot convert string "-dt-interface user-medium-r-normal-s*-*-*-*-*-*-*-*-*" to type FontSet tyr fd1026 70 I got the same output when I connected to Solaris from my older Cygwin installation with X11R6 (but with a small font in the dtmail window). It is necessary to start "dtmail" in this way due to a bug in Solaris or dtmail (I've forgotten which one was responsible), if you want to start "dtmail" via a ssh connection. I don't see any warnings in the window of my local Cygwin machine and I don't know if there is another place where I have to look for warnings from the X11 system. > I have some difficulty in working out what purpose (if any) the encodings.dir > file in the various font directories serves, but you might try updating the > encodings.dir file in all the font directories, not just in the encodings > directory, rather than rearranging the font path. When I remember right this was done automatically when I rebuilt the fonts.dir in /usr/share/fonts/75dpi/. Unfortunately I can't verify this because the Cygwin machine is at home and I'm in my office now. Kind regards Siegmar -- 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/
conflicting header files VendorSP.h and VendorP.h
Hi, I reported the following problem already to cyg...@cygwin.com. Perhaps that was the wrong list because the header files are in directory /usr/X11R6/include/... (the files have been moved to a new directory with X11R7, but haven't changed). I have installed lam-7.1.4 and xmpi-2.2.3b8 on Cygwin-1.5.25. Everything worked without problems for gcc-3.4.4. I've had smaller problems with gcc-4.3.2 which I could solve as far as they were related to lam-mpi/xmpi. eiger lam-7.1.4 24 gcc-4 -v Using built-in specs. Target: i686-pc-cygwin Configured with: ... Thread model: single gcc version 4.3.2 20080827 (alpha-testing) 1 (GCC) Unfortunately I couldn't solve a problem with conflicting header files in the cygwin environment for xmpi. ./configure --prefix=/usr/local/lam-7.1.4-gcc-4 \ --enable-shared --with-cxx=mpic++ \ CFLAGS="" CXXFLAGS="" FFLAGS="" FCFLAGS="" \ LDFLAGS="" CXXLDFLAGS="" \ CPPFLAGS="" C_INCL_PATH="" C_INCLUDE_PATH="" CPLUS_INCLUDE_PATH="" \ OBJC_INCLUDE_PATH="" LAMHOME="" \ |& tee log.configure.$SYSTEM_ENV.$MACHINE_ENV ... make |& tee log.make.$SYSTEM_ENV.$MACHINE_ENV ... if mpic++ -DHAVE_CONFIG_H -I. -I. -I. -I../../src -I/usr/X11R6/include -O -MT xmpi_misc.o -MD -MP -MF ".deps/xmpi_misc.Tpo" \ -c -o xmpi_misc.o `test -f 'xmpi_misc.cc' || echo './'`xmpi_misc.cc; \ then mv -f ".deps/xmpi_misc.Tpo" ".deps/xmpi_misc.Po"; \ else rm -f ".deps/xmpi_misc.Tpo"; exit 1; \ fi In file included from /usr/X11R6/include/Xm/XmP.h:1646, from /usr/X11R6/include/Xm/PrimitiveP.h:29, from /usr/X11R6/include/Xm/SashP.h:29, from xmpi_misc.cc:29: /usr/X11R6/include/X11/VendorP.h:87: error: previous declaration of 'VendorShellClassRec vendorShellClassRec' with 'C++' linkage /usr/X11R6/include/Xm/VendorSP.h:58: error: conflicts with new declaration with 'C' linkage mpic++: No such file or directory make[3]: *** [xmpi_misc.o] Error 1 I temporarily put the conflicting line in file "/usr/X11R6/include/Xm/VendorSP.h" into a comment and could finish the installation. Perhaps somebody knows how to fix the problem in the cygwin distribution. Thank you very much for a fix in one of the next distributions in advance. Siegmar -- 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/
was "missing fonts?" in cyg...@cygwin.com
Hi, I asked the following question in "cyg...@cygwin.com": > I have upgraded Cygwin to X11R7.4. In the past I could read my e-mail > via "ssh" and "dtmail" from a Solaris machine with a nice font. Now I > get a font which is about twice the size of the old one so that I get > too few lines in my dtmail-window and therefore have to scroll a lot. > I have already installed all available fonts from my mirror site > without solving this problem. I don't know which fonts are not available > in X11R7 which were available in X11R6. Does anybody know which font I > need and where I can download the missing font for X11R7? I got a helpful reply from David Burgess and somebody told me that I asked in the wrong list so that I send my "solution" to the appropriate list. > My workaround to this problem is to copy all fonts > from the solaris machine in /usr/openwin/lib/X11/fonts to a > cygwin user's directory (say /home/user/owfonts), then use > > xset +fp '/home/user/owfonts/75dpi' I installed the fonts from an older Cygwin distribution and used "xset +fp /home/Admin/fonts/75dpi" to prepend the old fonts to the font path. This solved my problem. Now I wanted to find out what was different. Therefore I compared /usr/share/fonts/75dpi and /usr/X11R6/lib/X11/fonts/75dpi from X11R7 and X11R6 (I had to "gunzip" the files first). Only the files "encodings.dir" were different. The old file contained an additional line ansi-1251 /usr/share/fonts/encodings/ansi-1251.enc.gz. Therefore I copied the file ansi-1251.enc.gz from X11R6 to /usr/share/fonts/encodings/ and rebuilt fonts.dir. Unfortunately I had the same problem once more. With "xset +fp /usr/share/fonts/75dpi/" I could solve my problem so that it probably depended on the font path. "xset -q" on the new machine displays Font Path: built-ins,/usr/share/fonts/misc/,/usr/share/fonts/TTF/, /usr/share/fonts/OTF,/usr/share/fonts/Type1/,/usr/share/fonts/100dpi/, /usr/share/fonts/75dpi/ and on the old machine Font Path: /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/TTF/, /usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/, /usr/X11R6/lib/X11/fonts/100dpi/ When I change the order of the font directories with "xset -fp /usr/share/fonts/100dpi/" and "xset fp+ /usr/share/fonts/100dpi/", I once more have a solution for my problem. Is there a reason why the order of the directories changed? Is it possible to switch the order of the directories back to the order of X11R6 in the distribution? Kind regards Siegmar -- 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 Release: 6.8.1.0-1
> > Unrecognized line in config file (ignored) > > JNROFFLANG=ja_JP.UTF-8 /usr/bin/groff -Tnippon -mandocj > > Unrecognized line in config file (ignored) > > KNROFF/usr/bin/groff -Tkorean -mandoc > > Unrecognized line in config file (ignored) > > JNEQN /usr/bin/eqn -Tnippon > > Unrecognized line in config file (ignored) > > KNEQN/usr/bin/eqn -Tkorean If you put a comment sign in front of these four lines in /usr/share/misc/man.conf "man" behaves as before. At least it worked for me because I don't have korean and japanese man pages. Siegmar
Re: xemacs: segmentation fault after
> And XEmacs is really crashing for you even if you don't use this 9 > packages ? Is there any hint in the *Message-Log* Buffer which lisp file > is getting loaded before you press c-x c-c ? No, it doesn't crash when I move the mentioned directories to a subdirectory but it crashes when any (just one is enough) of these packages is stored in the lisp directory. I started xemacs without a file so every time the cus-face package had been loaded. I don't know where it comes from because I couldn't find a package with that name. Do you have an idea what could be wrong? When I look e.g. at the files in "crisp" they are from 2003 and earlier so they haven't been touched in the last update but nevertheless they let xemacs crash. Siegmar
Re: xemacs: segmentation fault after
> Just try and move /usr/share/xemacs to /usr/share/xemacs.broken and see > what happens when you start xemacs. If it's not crashing, just include > one package after the other and start xemacs again. I had to remove the following nine packages: eiger xemacs 165 pwd /usr/share/xemacs eiger xemacs 166 ls -l */lisp/ mule-packages/lisp/: total 0 drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:28 edict drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:28 egg-its drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:28 skk xemacs-packages/lisp/: total 0 drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:29 c-support drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:29 calc drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:29 calendar drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:29 cc-mode drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:29 cookie drwxr-xr-x+ 2 AdminBenutzer0 Sep 17 09:29 crisp eiger xemacs 167 eiger xemacs 168 xemacs Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list eiger xemacs 169 When I add one of them to the parent lisp directory xemacs crashes with segmentation fault when I type . The warnings still appear after typing . I would like to have c-support and cc-mode. Any ideas what's wrong with the above packages? Siegmar
Re: xemacs: segmentation fault after
> Please provide the contents of the following buffer before you hit > : > > Click on View -> Show Message Log If I start xemacs without a file the buffer contains Loading cus-face... Loading cus-face...done If I type I get the described output and the segmentation fault. If I start xemacs with a new file x.c the buffer contains Loading cus-face... Loading cus-face...done Loading efs-cu... Loading efs-cu...done (New file) Loading cc-mode... Loading cc-mode...done Same behaviour as above. Kind regards Siegmar
xemacs: segmentation fault after
Hi, today I've upgraded Cygwin to the latest version. I can still use xemacs but I get a segmentation fault when I exit xemacs. xemacs worked fine with older versions of Cygwin (I think my last upgrade was in June) so that the error possibly has nothing to do with xemacs itself but with Cygwin or X11. I use my notebook among others to read e-mail on Solaris (dtmail). Before I upgraded everything was fine. Now I have in the upper dtmail-window (Sender, Subject, Time, ...) just rectangles while I still have normal characters in the text window for the selected mail. That too shows in my opinion that something is wrong with the new X11 environment. "cygcheck -c" displays "OK" for all packages. I've looked up the mailing lists and searched on the web but didn't find anything to solve the problem. I've installed Cygwin on Windows XP (NTFS, c:\cygwin). XP is up-to-date without SP2. I get the following output when I type (everything inluding the first two warnings appears at that time): eiger Admin 1 xemacs Warning: XtRemoveGrab asked to remove a widget not on the list Warning: XtRemoveGrab asked to remove a widget not on the list Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Your version of XEmacs was distributed with a PROBLEMS file that may describe your crash, and with luck a workaround. Please check it first, but do report the crash anyway. Please report this bug by invoking M-x report-emacs-bug, or by selecting `Send Bug Report' from the Help menu. If necessary, send ordinary email to [EMAIL PROTECTED]'. *MAKE SURE* to include the XEmacs configuration from M-x describe-installation, or equivalently the file Installation in the top of the build tree. *Please* try *hard* to obtain a C stack backtrace; without it, we are unlikely to be able to analyze the problem. Locate the core file produced as a result of this crash (often called `core' or `core.', and located in the directory in which you started XEmacs or your home directory), and type gdb /usr/bin/xemacs core then type `where' at the debugger prompt. No GDB on your system? You may have DBX, or XDB, or SDB. (Ask your system administrator if you need help.) If no core file was produced, enable them (often with `ulimit -c unlimited' in case of future recurrance of the crash. Lisp backtrace follows: kill-emacs() # bind (arg) save-buffers-kill-emacs(nil) # bind (command-debug-status) call-interactively(save-buffers-kill-emacs) # (condition-case ... . error) # (catch top-level ...) Segmentation fault eiger Admin 2 Hopefully somebody knows a solution. Please let me know if you need more information. Thank you very much for your help in advance. Kind regards Siegmar
