Xfree studder/pause and then segmentation fault
3 days ago I downloaded the latest setup from the cygwin website and installed the xfree components. My setup is a Dell latitude CPX with a Xircom cardbus network card running Windows 98SE. I am connecting to a linux box via XDMCP (I have connected to a Mandrake and YellowDog box with the same issues). After connecting and logging in everything works fine for 15-30min. Then the mouse starts to pause every few min as do the screen updates. This lasts for about 1/2min and then it crashes out to the CYGWIN dos box. The box states Segmentation Fault (Core Dump). At this point windows is now exhibiting the same pausing every few seconds that I had when in my Xfree session. Once I exit out of the CYGWIN dos box everything returns to normal. I can then restart my Xfree session and everything will repeat itself. Is this a bug anyone has experienced? Thanks, Duane Stites Cygwin Win95/NT Configuration Diagnostics Current System Time: Sun Jul 14 01:00:41 2002 Windows 98 SE Ver 4.10 Build Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\cygwin\bin c:\NOVELL\CLIENT32 c:\WINDOWS c:\WINDOWS c:\WINDOWS\COMMAND SysDir: C:\WINDOWS\SYSTEM WinDir: C:\WINDOWS HOME = `C:\cygwin\home\ds6676' MAKE_MODE = `unix' PWD = `/home/ds6676' USER = `ds6676' BLASTER = `A240 I5 D1 T4' CMDLINE = `bash --login -i' COMSPEC = `C:\WINDOWS\COMMAND.COM' HOMEDRIVE = `C:' HOMEPATH = `\cygwin\home\ds6676' INOCULAN = `C:\PROGRA~1\CHEYENNE\ANTIVI~1' NWLANGUAGE = `ENGLISH' OLDPWD = `/usr/bin' PROMPT = `$p$g' PS1 = `\[\033]0;\w\007 \033[32m\]\u@\h \[\033[33m\w\033[0m\] $ ' SHLVL = `1' TEMP = `c:\windows\TEMP' TERM = `cygwin' TMP = `c:\windows\TEMP' TZ = `MST7' WINBOOTDIR = `C:\WINDOWS' WINDIR = `C:\WINDOWS' _ = `/usr/bin/cygcheck.exe' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\Software\Cygnus Solutions HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2 (default) = `/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/ (default) = `C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = `C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = `C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/X11R6/lib/X11/fonts (default) = `C:\cygwin\usr\X11R6\lib\X11\fonts' flags = 0x000a HKEY_LOCAL_MACHINE\Software\Cygnus Solutions\Cygwin\Program Options a: fd N/AN/A c: hd FAT32 5707Mb 99% CPUN d: cd N/AN/A C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts system binmode . /cygdrive userbinmode,cygdrive Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Not Found: cpp (good!) Found: C:\cygwin\bin\find.exe Found: c:\WINDOWS\COMMAND\find.exe Warning: C:\cygwin\bin\find.exe hides c:\WINDOWS\COMMAND\find.exe Not Found: gcc Not Found: gdb Not Found: ld Found: C:\cygwin\bin\ls.exe Not Found: make Found: C:\cygwin\bin\sh.exe 19k 2002/02/20 C:\cygwin\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0 cyggdbm.dll v0.0 ts=2002/2/19 20:05 929k 2002/06/24 C:\cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0 cygiconv-2.dll v0.0 ts=2002/6/24 11:24 21k 2001/06/20 C:\cygwin\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0 cygintl.dll v0.0 ts=2001/6/20 10:09 22k 2001/12/13 C:\cygwin\bin\cygintl-1.dll - os=4.0 img=1.0 sys=4.0 cygintl-1.dll v0.0 ts=2001/12/13 2:28 23k 2002/06/24 C:\cygwin\bin\cygintl-2.dll - os=4.0 img=1.0 sys=4.0 cygintl-2.dll v0.0 ts=2002/6/23 21:54 45k 2001/04/25 C:\cygwin\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0 cygform5.dll v0.0 ts=2001/4/24 22:28 26k 2001/04/25 C:\cygwin\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0 cygmenu5.dll v0.0 ts=2001/4/24 22:27 156k 2001/04/25 C:\cygwin\bin\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0 cygncurses++5.dll v0.0 ts=2001/4/24 22:29 226k 2001/04/25 C:\cygwin\bin\cygncurses5.dll - os=4.0 img=1.0 sys=4.0 cygncurses5.dll v0.0 ts=2001/4/24 22:17 15k 2001/04/25 C:\cygwin\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0 cygpanel5.dll v0.0 ts=2001/4/24 22:27 35k 2002/01/09
Re: [ITP] glib-1.2.10 gtk+-1.2.10
Lapo Luchini wrote: What to say? Its only thanks to Steven O'Brien's patches that those packages contains DLLs. See http://homepage.ntlworld.com/steven.obrien2/ I'm currently doing -2 version of them, relibtoolizing them instead of using Steven patches. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
RE: Incorrect version in packages names
The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. Yes, this is it. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. Thanks for this hint. Ralf
RE: Incorrect version in packages names
The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. What about kde-x. Must it be named kde_x ? Ralf
RE: Incorrect version in packages names
What about kde-x. Must it be named kde_x ? Couln't those fixes be included in the base xfree package? Having a package that overwrites a file from another package gives problems if you deinstall the latter: you lose the file from the first... Unfortunally for some reasons no, because 1. this patches relates to cygipc based shm support, which isn't a cygwin packages and should not be used in a cygwin package (the xfree packages). There were some threads relating to this topic in the past on cygwin/cygwin apps. At the time the shm support will be a stable part of the cygwin dll, xfree could be recompiled with shm support. 2. some patches are currently not part of the official xfree release yet (for example xft patches and ice delay patch, see release notes below) Release 1.3 libXft: - added qt3 symbols to Xftlib libICE: - removed 5 seconds delay in libICE if file attributes don't match Release 1.2 - renamed package to kde-x Xwin.exe: - added MIT-SHM extension Ralf
Re: Incorrect version in packages names
Ralf Habacker wrote: The naming was probably inherited from linux, where it is possible to have both kde (1) and kde (2) and kde (3) all installed on the same machine. Therefore, each needs different basename. If the kde-cygwin folks want to maintain that package-name distinction, then they should just use kdelibs_2 instead of kdelibs-2 as their basename. Then upset and setup will be happy -- and end users will be able to install both kdelibs_2 and kdelibs_3. What about kde-x. Must it be named kde_x ? No, kde-x is fine. The problem is, the parser can't tell if the grouping after a '-' is part of the package name or package version, when the grouping begins with a numeral. kde-2 -- confusinng kde-x -- not confusing --Chuck
Re: New xlauncher (was: Re: Success with Java prog in XFree)
--- Rasjid Wilcox [EMAIL PROTECTED] wrote: On Mon, 15 Jul 2002 12:08 am, Ralf Habacker wrote: This is a great idea. I was thinking of using a language/toolkit that I could compile on my Linux box, as it it my main development machine. Delphi isn't too bad, as it (sort of) works under wine. The only problem was the compiled code didn't run under wine very well. It would be cool to be able to use it under linux/unix (hadn't thought of XNest though). What about qt ? It is available for windows and for unix/linux. Just been to the TrollTech website. The windows version of Qt is not fully GPL compatible. See http://www.trolltech.com/developer/download/qt-win-noncomm.html. Based on my interpretation of this discussion, I would say that that would rule out any xlauncher made with Qt for Windows from being distributed by setup.exe. The site also states that it requires MS Visual Studio v6, although my guess is that it could be used with gcc, but would probably take more work. OTOH, wxWindows (http://www.wxwindows.org) is fully GPL compatible. And for those of us that are not C or C++ experts, there is wxPython (http://www.wxpython.org) with an open-source IDE (http://boa-constructor.sourceforge.net/) which is suprisingly useable despite the version number (0.1) - although I'd suggest the CVS version. Rasjid. The last time I checked, building wxWindows import libs was a PITA because their configure script has literally 100+ flags. Why can't they just have --enable-max like apache where it builds everthing that is supported by your platform. Cheers, Nicholas __ Do You Yahoo!? Yahoo! Autos - Get free new car price quotes http://autos.yahoo.com
RE: [ITP] glib-1.2.10 gtk+-1.2.10
Lapo, Okay, I'll wait for the -2 pacakges. Could you put links to the setup.hint files in your email as well? That makes it a lot easier to upload the packages. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Lapo Luchini Sent: Sunday, July 14, 2002 7:29 AM To: Mailing List: CygWin-XFree Subject: Re: [ITP] glib-1.2.10 gtk+-1.2.10 Lapo Luchini wrote: What to say? Its only thanks to Steven O'Brien's patches that those packages contains DLLs. See http://homepage.ntlworld.com/steven.obrien2/ I'm currently doing -2 version of them, relibtoolizing them instead of using Steven patches. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796)
RE: Bug in startxwin.bat after installing with setup.exe in win98SE
Wow. I sure am glad that I was out of town, throwing a party, and replacing the power steering pump in my Jeep this weekend while you guys slugged this one out. The end result is that I have a couple of scripts to look at and evaluate. Right now I am still trying to get that scrollbars patch release, so the scripts will have to wait until 4.2.0-12 is released. Once again, wow. Harold
Re: New xlauncher (was: Re: Success with Java prog in XFree)
- Original Message - From: Tim Thomson [EMAIL PROTECTED] To: Rasjid Wilcox [EMAIL PROTECTED] Cc: cygwin-xfree Mailing List [EMAIL PROTECTED] I have been playing with wxWindows with C++. Why not just code to the Win32 API? It's not that hard, not for a trivial launcher. wxWindows is a pretty big dependency to have, and the reason your programs are so big is most likely due to static linking instead of using the shared library... Rob
RE: New xlauncher (was: Re: Success with Java prog in XFree)
On Mon, 2002-07-15 at 16:33, Harold Hunt wrote: For future reference, the xlauncher-style program is on my list of things to do. I want it done in straight C or C++ interfacing the GDI manually. I don't want dependencies on cumbersome libraries, and I don't want any non-free compiler languages involved. This xlauncher will remain on my to-do list until it is written to the above specs, regardless of whether or not someone comes up with a really slick xlauncher that depends on super-duper-library-foo. I don't care about super-duper-library-foo, I just want to be able to spend a small amount of time in order to contribute to a program with an arguably small scope. So wxWindows is also out? I was hoping for a cross platform xlauncher, as it would also be useful under a linux/*nix system using Xnest. I don't know a way to get cross platform support easily without using a library of some kind, and wxWindows seems to be the best, it's been around for ten years, and has a _lot_ of functionality. I understand your concern at depending on libraries, and I guess compiling a static binary won't satisfy your needs? The only other way I can see to do this is to do a complete rewrite of the program per OS, to utilise each systems native framework. There would be very little portable code between each version. Writing it as an X app once rootless mode works could be an option, as we would only have to write for an X framework, and not for Win32. This sounds like overkill to me though. Cheers, Tim.
Re: New xlauncher (was: Re: Success with Java prog in XFree)
- Original Message - From: Tim Thomson [EMAIL PROTECTED] To: cygx [EMAIL PROTECTED] Sent: Monday, July 15, 2002 3:39 PM Subject: RE: New xlauncher (was: Re: Success with Java prog in XFree) On Mon, 2002-07-15 at 16:33, Harold Hunt wrote: For future reference, the xlauncher-style program is on my list of things to do. I want it done in straight C or C++ interfacing the GDI manually. I don't want dependencies on cumbersome libraries, and I don't want any non-free compiler languages involved. This xlauncher will remain on my to-do list until it is written to the above specs, regardless of whether or not someone comes up with a really slick xlauncher that depends on super-duper-library-foo. I don't care about super-duper-library-foo, I just want to be able to spend a small amount of time in order to contribute to a program with an arguably small scope. So wxWindows is also out? I was hoping for a cross platform xlauncher, as it would also be useful under a linux/*nix system using Xnest. I don't know what Harold will say - although I can guess :}. What we do over in cygwin-apps when someone offers to provide maintain foo, that depends on library bar which is not in the distribution, is to say Maintain bar - making it a .dll if appropriate, packaging it and so forth. THEN, and only then, offer foo as a package. In short, I don't see any particular problem with wxWindows per se, as long as you make it easy for other folk to build and link and run against it natively. This would involve at a minimum a shared library and a -devel package with a static build and the headers. Rob
