X still crashing, but interesting log messages... different config vals needed?

[Linda Walsh]

Jon TURNEY wrote:

> On 11/02/2012 04:19, Linda Walsh wrote:
>> Still crashes in all the places it did 2 months ago, and more,  but
>> gives more interesting messages in log file (/var/log/xwin/XWin.0.log
> 
> I assume this refers to the problem reported in [1], crashing when running
> yast2 on SuSE 11.4.  I don't know anything about any other crashes you might
> have been experiencing.
> 
> I haven't done anything specific to try to fix this, because I can't reproduce
> the problem and I don't have a useful backtrace.
> 
> It would be of great help if you could follow the instructions at [2] to
> download the debug symbols and obtain a backtrace of the crash.

----
	I did that last time, then got another email from another admin saying
to try some other version instead of that one because the instructions were wrong.

	At that point, I gave up to go use Xming which didn't have the problem,
and was hoping someone else would run into it, since with cygwin, I have had it
set on autostart, and it usually crashes within 15-20 minuts -- make kernel, or 
almost any qt based util,... then I just start Xming -- which was stable until
this last cygwin update...which doesn't make sense, as I didn't think there was
any code overlap

(main thing is I can no longer click on 'X' in a window and have it close, I 
have to go through the program's menus in each program to close it...very
annoying.


> 
>> Was wondering if I should be giving any different options that might
>> help it behave better?
> 
>> Log from last run below --
>>
>> Welcome to the XWin X Server
>> Vendor: The Cygwin/X Project
>> Release: 1.11.4.0
>> OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
>> Package: version 1.11.4-3 built 2012-02-05
>>
>> XWin was started with the following command line:
>>
>> /usr/bin/XWin -dpi 101 -multiwindow -clipboard -nowinkill -wm
> 
>> [ 14334.463] SocketUNIXAccept: accept() failed 
> 
> This log looks normal apart from this line.
> 
> I don't think this is a new warning, and wasn't in the previous log you
> posted, so it's hard to see how this could be directly related to the problem.
> 
> On the other hand, I'm a bit surprised that it works at all after that error.
> 
> Nevertheless, since UNIX sockets don't seem to be working correctly for you,
> you might like to try adding '-nolisten unix' to see if that makes any difference.
> 
> On 11/02/2012 03:53, Linda Walsh wrote:
>> Re: oh forget the cygcheck...
>> (attached)..
> 
> cygwin = '() {  return 0
> }'
> 
> While I doubt that is is relevant, that's either a bug in cygcheck or a rather
> strange setting for the CYGWIN env var

---
'cygwin' shown' there is lower case...
it does make a difference in the environment (case that is()... it's
a function in my startup where I detect if I am on cygwin, then define
a func that returns shell true (0), else on linux would return 1...
then other parts in my startup script can use that

cygwin && . cygwin/xxx

or
cygwin || unixthing...


> 
> [1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00012.html
> [2] http://x.cygwin.com/devel/backtrace.html
> 




--
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/