Xwin stackdump while logging into RH8 with KDE as window manager

Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]

  Hi,

I have spent the last couple of days trying to sort this out and I am 
stumped.

I have a new machine that I am trying to get XFree up and running on. I 
already have XFree working just fine on 3 other workstations; these have 
been running fine for the past year and I have kept them updated with 
the latest release of cygwin/xfree every month or so. All of the 
machines are running win2k sp3, cygwin 1.3.22(0.78/3/2) and xfree 4.3.9.  

When I started putting this together the server was Red Hat Linux 8. 
Today I upgraded it to RH 9.0 but my problems persist.  I have the XDMCP 
running on the server and calling startx on the new workstation brings 
up the window server and the login box. If I login using KDE as the 
display manager XWin dumps core when KDE is about half way through it's 
initialization sequence. If I select Gnome as the display manager 
everything works fine. My guess is that this has something to do with 
the video setup on the new box, but I can not say what or where.

I have since discovered that if I remove my ~/.kde directory the login 
succeeds, but of course I loose two years of fine tuning my desktop.

Oh, and by the way, yes I have thoroughly checked the disk that I only 
have one copy of cygwin1.dll ;-)

Is there anything else I can send that will help diagnose this? Anything 
else I might try doing?

Tia,
- joel

[-- Attachment #2: startX --]
[-- Type: application/x-java-applet, Size: 262 bytes --]

[-- Attachment #3: XWin.exe.stackdump --]
[-- Type: text/plain, Size: 793 bytes --]

Exception: STATUS_ACCESS_VIOLATION at eip=004D4E7D
eax=00000000 ebx=00000000 ecx=00000015 edx=103E3D38 esi=103E5C60 edi=00000000
ebp=0022FE78 esp=0022FB90 program=C:\opt\cygwin\usr\X11R6\bin\XWin.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022FE78  004D4E7D  (10703058, 00000088, 00000011, 004002D4)
0022FEA8  00408062  (00000002, 00000000, 615F32C8, 00000001)
0022FEF0  0040179A  (0000000B, 615F32C8, 10100328, 0022E728)
0022FF40  61007408  (610D1F58, FFFFFFFE, 0000005C, 610D1E7C)
0022FF90  610076ED  (00000000, 00000000, 00000000, 00000000)
0022FFB0  0073E7C2  (00401490, 037F0009, 0022FFF0, 77E9CA90)
0022FFC0  0040103C  (0022E728, 0022F7C8, 7FFDF000, 0022E850)
0022FFF0  77E9CA90  (00401000, 00000000, 000000C8, 00000100)
End of stack trace

[-- Attachment #4: XWin.log --]
[-- Type: text/plain, Size: 2122 bytes --]

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1024 h 768
winInitializeDefaultScreens - Returning
ddxProcessArgument - screen - Found ``W D'' arg
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0000001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winSetEngine - Using user's preference: 4
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
winCreateBoundingWindowWindowed - User w: 1024 h: 768
winCreateBoundingWindowWindowed - Current w: 1024 h: 768
winAdjustForAutoHide - Original WorkArea: 0 0 740 1024
winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024
winCreateBoundingWindowWindowed - WindowClient w 1018 h 715 r 1018 l 0 b 715 t 0
winCreateBoundingWindowWindowed -  Returning
winCreatePrimarySurfaceShadowDDNL - Creating primary surface
winCreatePrimarySurfaceShadowDDNL - Created primary surface
winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
winAllocateFBShadowDDNL - lPitch: 4072
winAllocateFBShadowDDNL - Created shadow pitch: 4072
winAllocateFBShadowDDNL - Created shadow stride: 1018
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
(==) Using preset keyboard for "English (United Kingdom)" (00000809), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)"
winPointerWarpCursor - Discarding first warp: 509 357
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

 > machines are running win2k sp3, cygwin 1.3.22(0.78/3/2) and xfree 4.3.9.

Joel,

There is no such thing as Cygwin/XFree86 4.3.9.

There are Server Test Series releases:
http://xfree86.cygwin.com/devel/shadow/changelog.html

There are also setup.exe installed release of the XFree86-xserv-4.3.0-* 
package that correspond to a particular Server Test Series release (see 
the change log above to find the relation).

Did you install with setup.exe (highly, extremely recommended) or have 
you replaced your XWin.exe with a Server Test Series at some point?  If 
you have not used setup.exe lately to update your installation, I can 
only require that you do so and grab the latest XFree86-*-4.3.0-* 
packages to get yourself up to date.  Without an up to date installation 
I cannot rule out the fact that your bug may already have been fixed.

Please attach your startxwin.sh file for examination.

Harold

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Andrew Markebo]

Maybe throw an eye at the log in /tmp also? 

[...]

|
| Please attach your startxwin.sh file for examination.

  /Andy

-- 
 The Devil is so clever that he makes you think he doesn't exist.

	    Please note, new email, @telia.com -> @comhem.se

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]



Andrew Markebo wrote:

>Maybe throw an eye at the log in /tmp also? 
>
Hmm...thought I did.  Is it not XWin.log?

>[...]
>
>|
>| Please attach your startxwin.sh file for examination.
>
Okay I have but note that I do not use it. I start up the server with 
the attached startX command.

- joel

[-- Attachment #2: startX --]
[-- Type: application/x-java-applet, Size: 262 bytes --]

[-- Attachment #3: XWin.exe.stackdump --]
[-- Type: text/plain, Size: 787 bytes --]

Exception: STATUS_ACCESS_VIOLATION at eip=004D4F9D
eax=00000000 ebx=00000000 ecx=00000015 edx=103E3D48 esi=103E5C70 edi=00000000
ebp=0022FE78 esp=0022FB90 program=C:\root\usr\X11R6\bin\XWin.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022FE78  004D4F9D  (10708F30, 00000033, 00000000, 0000003A)
0022FEA8  00408062  (00000002, 00000000, 61622BAC, 00000001)
0022FEF0  0040179A  (00000005, 61622BAC, 10100330, 0022FF24)
0022FF40  61004D8A  (610D0EE8, FFFFFFFE, 000003A8, 610D0E0C)
0022FF90  6100507D  (00000000, 00000000, FFFFFFFF, 80430D04)
0022FFB0  0073E8E2  (00401490, 037F0009, 0022FFF0, 7C4E87F5)
0022FFC0  0040103C  (00000000, 00000000, 7FFDF000, 00000020)
0022FFF0  7C4E87F5  (00401000, 00000000, 000000C8, 00000100)
End of stack trace

[-- Attachment #4: XWin.log --]
[-- Type: text/plain, Size: 2181 bytes --]

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1024 h 768
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0000001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
winCreateBoundingWindowWindowed - User w: 1024 h: 768
winCreateBoundingWindowWindowed - Current w: 1024 h: 768
winAdjustForAutoHide - Original WorkArea: 0 0 740 1024
winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024
winCreateBoundingWindowWindowed - WindowClient w 1018 h 715 r 1018 l 0 b 715 t 0
winCreateBoundingWindowWindowed -  Returning
winCreatePrimarySurfaceShadowDDNL - Creating primary surface
winCreatePrimarySurfaceShadowDDNL - Created primary surface
winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
winAllocateFBShadowDDNL - lPitch: 4072
winAllocateFBShadowDDNL - Created shadow pitch: 4072
winAllocateFBShadowDDNL - Created shadow stride: 1018
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
(==) winConfigKeyboard - Layout: "00000809" 
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)"
winPointerWarpCursor - Discarding first warp: 509 357
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned
AUDIT: Thu Sep  4 10:29:06 2003: 1624 XWin: client 3 rejected from IP 217.34.189.205 port 4577

[-- Attachment #5: startxwin.sh --]
[-- Type: text/plain, Size: 4674 bytes --]

#! /bin/sh
export DISPLAY=127.0.0.1:0.0
PATH=/usr/X11R6/bin:$PATH

# Cleanup from last run.
rm -rf /tmp/.X11-unix


# Notice that the window manager and the xterm will wait for
# the server to finish starting before trying to connect; the
# error "Cannot Open Display: 127.0.0.1:0.0" is not due to the
# clients attempting to connect before the server has started, rather
# that error is due to a bug in some versions of cygwin1.dll.  Upgrade
# to the latest cygwin1.dll if you get the "Cannot Open Display" error.
# See the Cygwin/XFree86 FAQ for more information:
# http://xfree86.cygwin.com/docs/faq/
#
# The error "Fatal server error: could not open default font 'fixed'" is
# caused by using a DOS mode mount for the mount that the Cygwin/XFree86
# fonts are accessed through.  See the Cygwin/XFree86 FAQ for more 
# information:
# http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof


# Brief descriptions of XWin-specific options:
#
# -screen scr_num [width height]
#      Enable screen scr_num and optionally specify a width and
#      height for that screen.
#      Most importantly, any parameters specified before the first -screen
#      parameter apply to all screens.  Any options after the first -screen
#      parameter apply only to the screen that precedes the parameter.
#      Example:
#          XWin -fullscreen -screen 0 -screen 1 -depth 8 -screen 2
#      All screens will be fullscreen, but screen 2 will be depth 8, while
#      screens 0 and 1 will be the default depth (whatever depth Windows
#      is currently running at).
# -multiwindow
#      Start an integrated Windows-based window manager.  Not to be used
#      with -rootless nor -fullscreen.
# -rootless
#      Use a transparent root window with an external window manager
#      (such as twm).  Not to be used with -multiwindow nor
#      with -fullscreen.
# -fullscreen
#      Use a window as large as possible on the primary monitor.
# -multiplemonitors
#      Create a root window that covers all monitors on a
#      system with multiple monitors.
# -clipboard
#      Enable the integrated version of xwinclip.  Do not use in
#      conjunction with the xwinclip program.
# -depth bits_per_pixel
#      Specify the screen depth to run at (in bits per pixel) using a
#      DirectDraw-based engine in conjunction with the -fullscreen
#      option, ignored if the -fullscreen option is not specified.
#      By default, you will be using a DirectDraw based engine on any
#      system that supports it.
# -unixkill
#      Trap Ctrl+Alt+Backspace as a server shutdown key combination.
# -nounixkill
#      Disable Ctrl+Alt+Backspace as a server shutdown key combination (default).
#      Example:
#          XWin -unixkill -screen 0 -screen 1 -screen 2 -nounixkill
#      Screens 0 and 1 will allow Ctrl+Alt+Backspace, but screen 2 will not.
# -winkill
#      Trap Alt+F4 as a server shutdown key combination (default).
# -nowinkill
#      Disable Alt+F4 as a server shutdown key combination.
# -scrollbars
#      Enable resizing of the server display window.  Do not use in conjunction
#      with -multiwindow nor with -rootless.
# -nodecoration
#      Draw the server root window without a title bar or border.
#      Do not use with -mutliwindow nor with -rootless.
# -lesspointer
#      Hide the Windows mouse cursor anytime it is over any part of the
#      window, even if Cygwin/XFree86 is not the window with the focus.
# -refresh rate_in_Hz
#      Specify a refresh rate to use when used with the -fullscreen option.
# -trayicon
#      Enable the tray icon (default).
# -notrayicon
#      Disable the tray icon.
#      Example:
#          XWin -notrayicon -screen 0 -screen 1 -screen 2 -trayicon
#      Screens 0 and 1 will not have tray icons, but screen 2 will.
# -emulate3buttons [timeout]
#      Emulate 3 button mouse with an optional timeout in milliseconds.
# -xf86config
#      Specify an XF86Config-style configuration file.
# -keyboard
#      Specify a keyboard device from the configuration file.


#
# Startup the programs
# 


# Startup the X Server with the integrated Windows-based window manager.

XWin -multiwindow &


# Startup an xterm, using bash as the shell.

xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash &


#
# Startup the twm window manager.
# WARNING: Do not use an external window manager in conjunction with
# the ``-multiwindow'' command-line parameter for XWin.  Doing so
# would start two window managers, which is never supposed to happen.
#

# twm &  


# Set a background color.  Only needed when not using -multwindow for XWin.

# xsetroot -solid aquamarine4


# Return from sh.
exit

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

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.

2) Use "-engine 1".  This uses the GDI engine instead of DirectDraw. 
GDI may not be affected in the same way as DirectDraw.

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.

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

Thanks for testing,

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

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

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

Re: 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
>>>>>>>> |
>>>>>>>> |
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
> 
> 

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Andrew Markebo]

Hi!

Many thoughts.. hmm not nothing like KDE loads something that wants
features that only can be found on linux, not on the cygwin xfree?

         /Andy

-- 
 The eye of the linker rests on the libs!

	    Please note, new email, @telia.com -> @comhem.se

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

Harold L Hunt II wrote:

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

Fine, let me know when it is ready to go.

Thnaks,
Joel

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

Joel,

I just posted a Test97 DEBUG release to:

http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test97-DEBUG.exe.bz2


You seem pretty knowledgeable, so I assume that you know what to do in 
order to locate the place that XWin.exe is bombing.

One caveat --- if you run this under gdb, be aware that two exceptions 
are thrown during intialization... these are caught by handlers in 
cygwin1.dll, so you can just "continue" when you see these two 
exceptions.  Anything after that should indicate an actual problem.

Thanks so much for testing,

Harold

Joel Rosi-Schwartz wrote:

> Harold L Hunt II wrote:
> 
>> 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. 
> 
> 
> Fine, let me know when it is ready to go.
> 
> Thnaks,
> Joel
> 

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]

Harold,

I  have attached the output from the gdb run and, even thought they have 
not changed much, the stack trace and log. Please not that I have not 
downloaded source, so all you have is the file and line number where the 
violation takes place. I my having the source here can help with this 
please let me know.

Thanks,
Joel

Harold L Hunt II wrote:

> Joel,
>
> I just posted a Test97 DEBUG release to:
>
> http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test97-DEBUG.exe.bz2
>
>
> You seem pretty knowledgeable, so I assume that you know what to do in 
> order to locate the place that XWin.exe is bombing.
>
> One caveat --- if you run this under gdb, be aware that two exceptions 
> are thrown during intialization... these are caught by handlers in 
> cygwin1.dll, so you can just "continue" when you see these two 
> exceptions.  Anything after that should indicate an actual problem.
>
> Thanks so much for testing,
>
> Harold
>
> Joel Rosi-Schwartz wrote:
>
>> Harold L Hunt II wrote:
>>
>>> 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. 
>>
>>
>>
>> Fine, let me know when it is ready to go.
>>
>> Thnaks,
>> Joel
>>
>
>


[-- Attachment #2: gdb.out --]
[-- Type: text/plain, Size: 351 bytes --]

(gdb) run  -query athena -from polyhymnia
Starting program: /usr/X11R6/bin/XWin.exe -query athena -from polyhymnia
---Type <return> to continue, or q <return> to quit---

Program received signal SIGSEGV, Segmentation fault.
0x0050b588 in ProcXkbGetKbdByName (client=0x10709ff8) at xkb.c:6022
6022    xkb.c: No such file or directory.
        in xkb.c

[-- Attachment #3: XWin.exe.stackdump --]
[-- Type: text/plain, Size: 847 bytes --]

Exception: STATUS_ACCESS_VIOLATION at eip=0050B588
eax=00000054 ebx=10707808 ecx=00000015 edx=00000000 esi=103E6658 edi=00000000
ebp=0022FE58 esp=0022FB20 program=c:\root\usr\X11R6\bin\XWin.exe
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022FE58  0050B588  (1064E6A0, 00000001, 00000064, 00000010)
0022FE78  0050DE79  (1064E6A0, 00000033, 00000000, 0000003A)
0022FEA8  00409CBB  (00000002, 00000000, 61622B84, 00000001)
0022FEF0  00401988  (00000007, 61622B84, 10100330, 0022FF24)
0022FF40  61004D8A  (610D0EE8, FFFFFFFE, 000003A8, 610D0E0C)
0022FF90  6100507D  (00000000, 00000000, FFFFFFFF, 80430D04)
0022FFB0  0082A282  (00401438, 037F0009, 0022FFF0, 7C4E87F5)
0022FFC0  0040103C  (00000000, 00000000, 7FFDF000, 00000020)
0022FFF0  7C4E87F5  (00401000, 00000000, 000000C8, 00000100)
End of stack trace

[-- Attachment #4: XWin.log --]
[-- Type: text/plain, Size: 2101 bytes --]

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1024 h 768
winInitializeDefaultScreens - Returning
OsVendorInit - Creating bogus screen 0
(EE) Unable to locate/open config file
InitOutput - Error reading config file
winDetectSupportedEngines - Windows NT/2000/XP
winDetectSupportedEngines - DirectDraw installed
winDetectSupportedEngines - Allowing PrimaryDD
winDetectSupportedEngines - DirectDraw4 installed
winDetectSupportedEngines - Returning, supported engines 0000001f
InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
winCreateBoundingWindowWindowed - User w: 1024 h: 768
winCreateBoundingWindowWindowed - Current w: 1024 h: 768
winAdjustForAutoHide - Original WorkArea: 0 0 740 1024
winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024
winCreateBoundingWindowWindowed - WindowClient w 1018 h 715 r 1018 l 0 b 715 t 0
winCreateBoundingWindowWindowed -  Returning
winCreatePrimarySurfaceShadowDDNL - Creating primary surface
winCreatePrimarySurfaceShadowDDNL - Created primary surface
winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
winAllocateFBShadowDDNL - lPitch: 4072
winAllocateFBShadowDDNL - Created shadow pitch: 4072
winAllocateFBShadowDDNL - Created shadow stride: 1018
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
winFinishScreenInitFB - returning
winScreenInit - returning
InitOutput - Returning.
(==) winConfigKeyboard - Layout: "00000809" 
(==) Using preset keyboard for "English (United Kingdom)" (00000809), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)"
winPointerWarpCursor - Discarding first warp: 509 357
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

Joel,

Alexander Gottwald --- Take a look at the location of this crash:

Program received signal SIGSEGV, Segmentation fault.
0x0050b588 in ProcXkbGetKbdByName (client=0x10709ff8) at xkb.c:6022

Does this indicate any problems to you?

The line reference does two pointer dereferences:

*xkb->ctrls = *old_xkb->ctrls;


That is interesting... are you using an XF86Config file?  Or, do you 
have your keyboard in Windows set to something other than the default 
layout (the answer is probably no if you don't know what this is)?  What 
about the keyboard in your KDE setup.


Harold

Joel Rosi-Schwartz wrote:
> Harold,
> 
> I  have attached the output from the gdb run and, even thought they have 
> not changed much, the stack trace and log. Please not that I have not 
> downloaded source, so all you have is the file and line number where the 
> violation takes place. I my having the source here can help with this 
> please let me know.
> 
> Thanks,
> Joel
> 
> Harold L Hunt II wrote:
> 
>> Joel,
>>
>> I just posted a Test97 DEBUG release to:
>>
>> http://www.msu.edu/~huntharo/xwin/shadow/XWin-Test97-DEBUG.exe.bz2
>>
>>
>> You seem pretty knowledgeable, so I assume that you know what to do in 
>> order to locate the place that XWin.exe is bombing.
>>
>> One caveat --- if you run this under gdb, be aware that two exceptions 
>> are thrown during intialization... these are caught by handlers in 
>> cygwin1.dll, so you can just "continue" when you see these two 
>> exceptions.  Anything after that should indicate an actual problem.
>>
>> Thanks so much for testing,
>>
>> Harold
>>
>> Joel Rosi-Schwartz wrote:
>>
>>> Harold L Hunt II wrote:
>>>
>>>> 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. 
>>>
>>>
>>>
>>>
>>> Fine, let me know when it is ready to go.
>>>
>>> Thnaks,
>>> Joel
>>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> (gdb) run  -query athena -from polyhymnia
> Starting program: /usr/X11R6/bin/XWin.exe -query athena -from polyhymnia
> ---Type <return> to continue, or q <return> to quit---
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0050b588 in ProcXkbGetKbdByName (client=0x10709ff8) at xkb.c:6022
> 6022    xkb.c: No such file or directory.
>         in xkb.c
> 
> 
> ------------------------------------------------------------------------
> 
> Exception: STATUS_ACCESS_VIOLATION at eip=0050B588
> eax=00000054 ebx=10707808 ecx=00000015 edx=00000000 esi=103E6658 edi=00000000
> ebp=0022FE58 esp=0022FB20 program=c:\root\usr\X11R6\bin\XWin.exe
> cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
> Stack trace:
> Frame     Function  Args
> 0022FE58  0050B588  (1064E6A0, 00000001, 00000064, 00000010)
> 0022FE78  0050DE79  (1064E6A0, 00000033, 00000000, 0000003A)
> 0022FEA8  00409CBB  (00000002, 00000000, 61622B84, 00000001)
> 0022FEF0  00401988  (00000007, 61622B84, 10100330, 0022FF24)
> 0022FF40  61004D8A  (610D0EE8, FFFFFFFE, 000003A8, 610D0E0C)
> 0022FF90  6100507D  (00000000, 00000000, FFFFFFFF, 80430D04)
> 0022FFB0  0082A282  (00401438, 037F0009, 0022FFF0, 7C4E87F5)
> 0022FFC0  0040103C  (00000000, 00000000, 7FFDF000, 00000020)
> 0022FFF0  7C4E87F5  (00401000, 00000000, 000000C8, 00000100)
> End of stack trace
> 
> 
> ------------------------------------------------------------------------
> 
> ddxProcessArgument - Initializing default screens
> winInitializeDefaultScreens - w 1024 h 768
> winInitializeDefaultScreens - Returning
> OsVendorInit - Creating bogus screen 0
> (EE) Unable to locate/open config file
> InitOutput - Error reading config file
> winDetectSupportedEngines - Windows NT/2000/XP
> winDetectSupportedEngines - DirectDraw installed
> winDetectSupportedEngines - Allowing PrimaryDD
> winDetectSupportedEngines - DirectDraw4 installed
> winDetectSupportedEngines - Returning, supported engines 0000001f
> InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1
> winSetEngine - Using Shadow DirectDraw NonLocking
> winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel
> winCreateBoundingWindowWindowed - User w: 1024 h: 768
> winCreateBoundingWindowWindowed - Current w: 1024 h: 768
> winAdjustForAutoHide - Original WorkArea: 0 0 740 1024
> winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024
> winCreateBoundingWindowWindowed - WindowClient w 1018 h 715 r 1018 l 0 b 715 t 0
> winCreateBoundingWindowWindowed -  Returning
> winCreatePrimarySurfaceShadowDDNL - Creating primary surface
> winCreatePrimarySurfaceShadowDDNL - Created primary surface
> winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface
> winAllocateFBShadowDDNL - lPitch: 4072
> winAllocateFBShadowDDNL - Created shadow pitch: 4072
> winAllocateFBShadowDDNL - Created shadow stride: 1018
> winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
> winInitVisualsShadowDDNL - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
> winCreateDefColormap - Deferring to fbCreateDefColormap ()
> winFinishScreenInitFB - returning
> winScreenInit - returning
> InitOutput - Returning.
> (==) winConfigKeyboard - Layout: "00000809" 
> (==) Using preset keyboard for "English (United Kingdom)" (00000809), type "4"
> (EE) No primary keyboard configured
> (==) Using compiletime defaults for keyboard
> Rules = "xfree86" Model = "pc105" Layout = "gb" Variant = "(null)" Options = "(null)"
> winPointerWarpCursor - Discarding first warp: 509 357
> winBlockHandler - Releasing pmServerStarted
> winBlockHandler - pthread_mutex_unlock () returned

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Alexander Gottwald]

Harold L Hunt II wrote:

> Program received signal SIGSEGV, Segmentation fault.
> 0x0050b588 in ProcXkbGetKbdByName (client=0x10709ff8) at xkb.c:6022
>
> Does this indicate any problems to you?

I was hunting the problem with textmode /tmp and xkb today. The fix I've
submitted long ago never got into the xfree cvs, so the problem is still
there. I'll check it into xoncygwin cvs after a few tests. Maybe this will
fix this segfault too.

I think the functions reading the keymap fail at a bogus newline and return
an improper filled structure with some pointers set to NULL or random data.

bye
    ago

NP: Lacrimosa - Fassade-3. Satz
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Alexander Gottwald]

Alexander Gottwald wrote:

> I think the functions reading the keymap fail at a bogus newline and return
> an improper filled structure with some pointers set to NULL or random data.

To verify if this is the problem, please check the output of mount
if an entry for /tmp exists and if this entry (or the entry for /)
has a marking (binmode) or (textmode). If it's marked textmode,
please run

mount -buf "$(cygpath -m /tmp)" "/tmp"

and check if XWin still segfaults.

NP: Lacrimosa - No blind eyes can see
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Alexander Gottwald]

Alexander Gottwald wrote:

> I was hunting the problem with textmode /tmp and xkb today. The fix I've
> submitted long ago never got into the xfree cvs, so the problem is still
> there. I'll check it into xoncygwin cvs after a few tests.

The change for the server is submitted. I'm not sure if xkbcomp is already
patched in the last 4.3 release.

Harold, can you please check if the attached patch is applied to your
buildtree? (file is xc/programs/xkbcomp/xkbcomp.c)

bye
    ago

NP: Lacrimosa - Schakal
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Alexander Gottwald]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 143 bytes --]

Missing attachment :)

NP: Lacrimosa - Schakal
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

[-- Attachment #2: Type: TEXT/plain, Size: 1282 bytes --]

Index: xkbcomp.c
===================================================================
RCS file: /cvs/xc/programs/xkbcomp/xkbcomp.c,v
retrieving revision 3.19
diff -u -u -r3.19 xkbcomp.c
--- xkbcomp.c	27 May 2003 22:27:07 -0000	3.19
+++ xkbcomp.c	7 Sep 2003 18:56:18 -0000
@@ -871,16 +871,30 @@
 		 * -- Branden Robinson
 		 */
 		int outputFileFd;
+        int binMode = 0;
+        const char *openMode = "w";
 		unlink(outputFile);
+#ifdef O_BINARY
+        switch (outputFormat) {
+            case WANT_XKM_FILE:
+                binMode = O_BINARY;
+                openMode = "wb";
+                break;
+            default:
+                binMode = 0;
+                break;
+        }
+#endif
 		outputFileFd= open(outputFile, O_WRONLY|O_CREAT|O_EXCL,
-			    S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
+			    S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH|binMode);
 		if (outputFileFd<0) {
 		    ERROR1("Cannot open \"%s\" to write keyboard description\n",
 								outputFile);
 		    ACTION("Exiting\n");
 		    exit(1);
 		}
-		out= fdopen(outputFileFd, "w");
+        
+		out= fdopen(outputFileFd, openMode);
 		/* end BR */
 		if (out==NULL) {
 		    ERROR1("Cannot open \"%s\" to write keyboard description\n",

two small problems with kde-cygwin

[Gene C. Ruzicka]

i recently installed kde 3.1.1 on my w2k pc. overall,
it works well aside from somewhat sluggish response --
i guess it's time to upgrade to a faster processor.

two small software-related problems:

1.  when i request for help from the toolbar icon, each item
     in the contents panel of the help window is
     repeated; i.e., the first few items read: 
              Welcome to KDE
              Welcome to KDE
              KDE user's manual
              KDE user's manual
              Application Manuals
              Application Manuals
                       etc.


2.  when i invoke the "maximal Desktop,"
     an xterm window doesn't work properly
     when invoked using "xterm &" from
     a Konsole window; specifically, no text
     gets displayed in the xterm, either when typed
     from the keyboard or output from the OS. all
     i see in the xterm is the cursor (without prompt),
     which responds appropriately to line feeds.  

    strangely, this probem does NOT occur when
    i emply the "minimal Desktop;"  in other words,
    an xterm invoked from a Konsole window works
    fine. is buying more memory the "cure?"

gene

Re: two small problems with kde-cygwin

[Alexander Gottwald]

Gene C. Ruzicka wrote:

> i recently installed kde 3.1.1 on my w2k pc. overall,
> it works well aside from somewhat sluggish response --
> i guess it's time to upgrade to a faster processor.
>
> two small software-related problems:

Your questions are very closely bound to KDE. The kde-cygwin@kde.org
mailinglist is the correct place for your questions.

This reply will be cc'ed to this list.

>
> 1.  when i request for help from the toolbar icon, each item
>      in the contents panel of the help window is
>      repeated; i.e., the first few items read:
>               Welcome to KDE
>               Welcome to KDE
>               KDE user's manual
>               KDE user's manual
>               Application Manuals
>               Application Manuals
>                        etc.
>
>
> 2.  when i invoke the "maximal Desktop,"
>      an xterm window doesn't work properly
>      when invoked using "xterm &" from
>      a Konsole window; specifically, no text
>      gets displayed in the xterm, either when typed
>      from the keyboard or output from the OS. all
>      i see in the xterm is the cursor (without prompt),
>      which responds appropriately to line feeds.
>
>     strangely, this probem does NOT occur when
>     i emply the "minimal Desktop;"  in other words,
>     an xterm invoked from a Konsole window works
>     fine. is buying more memory the "cure?"
>
> gene
>

NP: Lacrimosa - Copycat
-- 
 Alexander.Gottwald@informatik.tu-chemnitz.de
 http://www.gotti.org           ICQ: 126018723

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

On Sunday 07 September 2003 19:59, Alexander Gottwald wrote:
> Alexander Gottwald wrote:
> > I was hunting the problem with textmode /tmp and xkb today. The fix I've
> > submitted long ago never got into the xfree cvs, so the problem is still
> > there. I'll check it into xoncygwin cvs after a few tests.
>
> The change for the server is submitted. I'm not sure if xkbcomp is already
> patched in the last 4.3 release.
>
> Harold, can you please check if the attached patch is applied to your
> buildtree? (file is xc/programs/xkbcomp/xkbcomp.c)

Hit the nail on the head! Works like a charm now. Sorry I always keep 
everything mounted in binmode, but when I built the new machines that slipped 
through the cracks.

Many thanks to you, Harold and the xfree team.  Great product and great 
support.

ciao,
joel

> bye
>     ago
>
> NP: Lacrimosa - Schakal

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Joel Rosi-Schwartz]

On Sunday 07 September 2003 03:11, Harold L Hunt II wrote:
> Joel,
>
[snip/snip]

> That is interesting... are you using an XF86Config file?  Or, do you
> have your keyboard in Windows set to something other than the default
> layout (the answer is probably no if you don't know what this is)?  What
> about the keyboard in your KDE setup.

I am not sure about the XF86Config file, if I was where would it be sitting.

As for the keyboards, yes we use UK keyboards. Up until a few months ago I had 
to run <xmodmap /usr/share/xmodmap/xmodmap.uk> to reset the key bindings. 
This problem disappeared at some point a few months back but reapeared with 
the new release. The fix of changing the mount types to binmode also re-fixed 
this problem.

I am really very curious as to what all of the interactions are, but I rather 
afraid you guys would have to write a small book to explain it all. Perhaps 
better to simply leave it with a hearty thank you and be happy that you are 
on top of it all ;-)

- joel

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Alexander Gottwald]

On Mon, 8 Sep 2003, Joel Rosi-Schwartz wrote:

> I am really very curious as to what all of the interactions are, but I rather 
> afraid you guys would have to write a small book to explain it all. 

The book is already written :) But who would like to search the archive for all
the chapters? 

bye
	ago
-- 
 Alexander.Gottwald@s1999.tu-chemnitz.de 
 http://www.gotti.org           ICQ: 126018723

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

Alexander,

I have submitted this to XFree86 to get it in before the XFree86 4.4.0 
feature deadline in about two weeks:

http://bugs.xfree86.org/show_bug.cgi?id=768

Harold

Alexander Gottwald wrote:

> Missing attachment :)
> 
> NP: Lacrimosa - Schakal
> 
> 
> ------------------------------------------------------------------------
> 
> Index: xkbcomp.c
> ===================================================================
> RCS file: /cvs/xc/programs/xkbcomp/xkbcomp.c,v
> retrieving revision 3.19
> diff -u -u -r3.19 xkbcomp.c
> --- xkbcomp.c	27 May 2003 22:27:07 -0000	3.19
> +++ xkbcomp.c	7 Sep 2003 18:56:18 -0000
> @@ -871,16 +871,30 @@
>  		 * -- Branden Robinson
>  		 */
>  		int outputFileFd;
> +        int binMode = 0;
> +        const char *openMode = "w";
>  		unlink(outputFile);
> +#ifdef O_BINARY
> +        switch (outputFormat) {
> +            case WANT_XKM_FILE:
> +                binMode = O_BINARY;
> +                openMode = "wb";
> +                break;
> +            default:
> +                binMode = 0;
> +                break;
> +        }
> +#endif
>  		outputFileFd= open(outputFile, O_WRONLY|O_CREAT|O_EXCL,
> -			    S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
> +			    S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH|binMode);
>  		if (outputFileFd<0) {
>  		    ERROR1("Cannot open \"%s\" to write keyboard description\n",
>  								outputFile);
>  		    ACTION("Exiting\n");
>  		    exit(1);
>  		}
> -		out= fdopen(outputFileFd, "w");
> +        
> +		out= fdopen(outputFileFd, openMode);
>  		/* end BR */
>  		if (out==NULL) {
>  		    ERROR1("Cannot open \"%s\" to write keyboard description\n",

Re: Xwin stackdump while logging into RH8 with KDE as window manager

[Harold L Hunt II]

Alexander,

Egbert Eich has scheduled your patch to xkbcomp to be committed to CVS HEAD.

Harold

Harold L Hunt II wrote:

> Alexander,
> 
> I have submitted this to XFree86 to get it in before the XFree86 4.4.0 
> feature deadline in about two weeks:
> 
> http://bugs.xfree86.org/show_bug.cgi?id=768
> 
> Harold
> 
> Alexander Gottwald wrote:
> 
>> Missing attachment :)
>>
>> NP: Lacrimosa - Schakal
>>
>>
>> ------------------------------------------------------------------------
>>
>> Index: xkbcomp.c
>> ===================================================================
>> RCS file: /cvs/xc/programs/xkbcomp/xkbcomp.c,v
>> retrieving revision 3.19
>> diff -u -u -r3.19 xkbcomp.c
>> --- xkbcomp.c    27 May 2003 22:27:07 -0000    3.19
>> +++ xkbcomp.c    7 Sep 2003 18:56:18 -0000
>> @@ -871,16 +871,30 @@
>>           * -- Branden Robinson
>>           */
>>          int outputFileFd;
>> +        int binMode = 0;
>> +        const char *openMode = "w";
>>          unlink(outputFile);
>> +#ifdef O_BINARY
>> +        switch (outputFormat) {
>> +            case WANT_XKM_FILE:
>> +                binMode = O_BINARY;
>> +                openMode = "wb";
>> +                break;
>> +            default:
>> +                binMode = 0;
>> +                break;
>> +        }
>> +#endif
>>          outputFileFd= open(outputFile, O_WRONLY|O_CREAT|O_EXCL,
>> -                S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
>> +                
>> S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH|binMode);
>>          if (outputFileFd<0) {
>>              ERROR1("Cannot open \"%s\" to write keyboard description\n",
>>                                  outputFile);
>>              ACTION("Exiting\n");
>>              exit(1);
>>          }
>> -        out= fdopen(outputFileFd, "w");
>> +        +        out= fdopen(outputFileFd, openMode);
>>          /* end BR */
>>          if (out==NULL) {
>>              ERROR1("Cannot open \"%s\" to write keyboard description\n",
> 
>