Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

Joel,

The next step is to have you run a debug build of XWin.exe.  We should 
be able to locate the offending line of code, so long as it is a problem 
internal to XWin.exe and not in an external library (it almost never 
is).  I am creating a debug build of XWin.exe for you to try now.  I 
really should have done this a long time ago... we have a few types of 
random crashes now that need to be fixed.

Harold

Joel Rosi-Schwartz wrote:

> Harold,
> 
> Harold L Hunt II wrote:
> 
>> Joel,
>>
>> Okay, I have a couple more easy things to try that might have an effect:
>>
>> 1) Use "-fullscreen" to run in a full screen window... you may be 
>> seeing the results of some sort of image scaling problem.  Running in 
>> full screen gives you a standard aspect ratio screen, so it might 
>> aleviate the problem. 
> 
> 
> nope
> 
>> 2) Use "-engine 1".  This uses the GDI engine instead of DirectDraw. 
>> GDI may not be affected in the same way as DirectDraw. 
> 
> 
> nope
> 
>>
>> 3) Use "-clipupdates 10".  This will group together all updates to the 
>> Cygwin/XFree86 window that have more than 10 regions in them.  This 
>> may prevent your problem from causing a crash. 
> 
> 
> nope :-(
> 
>>
>> 4) Don't use the "2>/dev/null" in your startx script anymore.  At best 
>> it is not needed since we are not a console app... at worst it is 
>> redirecting a file handle that is not expected and may be causing 
>> problems.  In fact, please try using startxdmcp.bat... it has much 
>> fewer side effects that any other method of starting the server and 
>> will rule out a few questions in my mind. 
> 
> 
> I took out the /dev/null and your point is well taken.  Then I tried 
> startxdmcp.bat but unfortunately the behaviour remains the same.
> 
>> I understand what your problem is.  I also know that sometimes strange 
>> things happen that I do not expect and trying a few things that don't 
>> make sense often ends up fixing the problem and alerting me to 
>> something that I didn't know what happening. 
> 
> 
> I figured that you did and I understand that you are being meticulous 
> with eliminating possible causes, but sometimes it pays to double check 
> when no certain.
> 
>> Thanks for testing, 
> 
> 
> Well actually it is I who am thankful. It is really appreciated how well 
> you support this list and my problem in particular. Thanks.
> 
> What's next :-)
> 
> - joel
> 
>>
>> Harold
>>
>> Joel Rosi-Schwartz wrote:
>>
>>> Harold,
>>>
>>> I tried both and the behaviour prevails.
>>>
>>> Just to make sure we are on the same page, I would like to reiterate 
>>> that the problem only occurs when I log into pre-existing kde 
>>> configurations. If I log in under a clean kde environment all is 
>>> fine. It appears to be something that I configured in the kde 
>>> desktop. I am suspicious that somewhere along the line I have set the 
>>> screen resolution from within kde, but for life of me I can not find 
>>> such an option on the kde desktop tools. I have tried giving the 
>>> startX command the -screen option, but that does not seem to alter 
>>> any noticeable behaviour.
>>>
>>> - joel
>>>
>>> Harold L Hunt II wrote:
>>>
>>>> Joel,
>>>>
>>>> Okay, on the off chance that something strange is happening, please 
>>>> try changing the "-from `hostname`" to "-from %my_ip_address%".  
>>>> Also, try leaving off the -from altogether if you only have one 
>>>> network interface in your computer.
>>>>
>>>> Harold
>>>>
>>>> Joel Rosi-Schwartz wrote:
>>>>
>>>>> Harold,
>>>>>
>>>>> Gave it a shot but it still core dumps. Thanks for the idea though.
>>>>>
>>>>> - joel
>>>>>
>>>>> Harold L Hunt II wrote:
>>>>>
>>>>>> Joel,
>>>>>>
>>>>>> We had some problems a long while back with 24 and 32 bit color 
>>>>>> and KDE.  Try dropping your Windows color depth to 16 bits per 
>>>>>> pixel and report your results.
>>>>>>
>>>>>> Thanks for testing,
>>>>>>
>>>>>> Harold
>>>>>>
>>>>>> Joel Rosi-Schwartz wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andrew Markebo wrote:
>>>>>>>
>>>>>>>> What happens if you pick away the export DISPLAY? 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No effect, it behaves the same either way. The thing is that it 
>>>>>>> all works fine if the kde environment of the user logging in is 
>>>>>>> virgin. Something in the KDE environment that has been configured 
>>>>>>> at some point in the past is now causing a core dump on the new 
>>>>>>> machines.  Our old machines continue to function normally.  The 
>>>>>>> ultimate solution is to simply remove our existing .kde 
>>>>>>> directories and reconfigure our desktops from scratch. That is 
>>>>>>> real boring work but in the end may be the simplest solution.
>>>>>>>
>>>>>>> - joel
>>>>>>>
>>>>>>>>     /Andy
>>>>>>>>
>>>>>>>> / Joel Rosi-Schwartz <Joel.Rosi-Schwartz@Etish.org> wrote:
>>>>>>>> | I do not understand why, but both times that I attached my 
>>>>>>>> startX file
>>>>>>>> | it seems be unreadable. Here are the contents:
>>>>>>>> |
>>>>>>>> | export PATH="/usr/X11R6/bin:$PATH"
>>>>>>>> | export DISPLAY=127.0.0.1:0.0
>>>>>>>> |
>>>>>>>> | cd c:/tmp
>>>>>>>> | nohup /usr/X11R6/bin/XWin -query athena -from `hostname` 
>>>>>>>> 2>/dev/null&
>>>>>>>> |
>>>>>>>> | # I have also tried the following
>>>>>>>> | # /usr/X11R6/bin/XWin -screen 0 1024 768 -engine 4 -query 
>>>>>>>> athena -from
>>>>>>>> | `hostname`
>>>>>>>> |
>>>>>>>> | - joel
>>>>>>>> |
>>>>>>>> |
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
>