XFree86-xserv-4.3.0-34 crash

XFree86-xserv-4.3.0-34 crash

[Øyvind Harboe]

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

This crash seems to be very similar to what I've seen in previous releases. I have the
impression that it happens most often when I select a message in Evolution.

XWin.log attached. 

Suggestions?

Øyvind


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

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1600 h 1200
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
winScreenInit - dwWidth: 1600 dwHeight: 1200
winSetEngine - Multi Window => ShadowGDI
winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel
winCreateBoundingWindowWindowed - User w: 1600 h: 1200
winCreateBoundingWindowWindowed - Current w: 1600 h: 1200
winGetWorkArea - Original WorkArea: 0 0 1166 1600
winGetWorkArea - Virtual screen is 2880 x 1200
winGetWorkArea - Virtual screen origin is 0, 0
winGetWorkArea - Primary screen is 1600 x 1200
winGetWorkArea - Adjusted WorkArea for multiple monitors: 0 0 1166 2880
winAdjustForAutoHide - Original WorkArea: 0 0 1166 2880
winAdjustForAutoHide - Adjusted WorkArea: 0 0 1166 2880
winCreateBoundingWindowWindowed - WindowClient w 2880 h 1166 r 2880 l 0 b 1166 t 0
winCreateBoundingWindowWindowed -  Returning
winAllocateFBShadowGDI - Creating DIB with width: 2880 height: 1200 depth: 32
winAllocateFBShadowGDI - Dibsection width: 2880 height: 1200 depth: 32 size image: 13824000
winAllocateFBShadowGDI - Created shadow stride: 2880
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
winCreateDefColormap - Deferring to fbCreateDefColormap ()
null screen fn ReparentWindow
null screen fn RestackWindow
winFinishScreenInitFB - Calling winInitWM.
InitQueue - Calling pthread_mutex_init
InitQueue - pthread_mutex_init returned
InitQueue - Calling pthread_cond_init
InitQueue - pthread_cond_init returned
winInitWM - Returning.
winFinishScreenInitFB - returning
winScreenInit - returning
winInitMultiWindowWM - Hello
winInitMultiWindowWM - Calling pthread_mutex_lock ()
winMultiWindowXMsgProc - Hello
winMultiWindowXMsgProc - Calling pthread_mutex_lock ()
InitOutput - Returning.
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
(--) Setting autorepeat to delay=500, rate=31
(--) winConfigKeyboard - Layout: "00000414" (00000414) 
(--) Using preset keyboard for "Norwegian" (414), type "4"
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc105" Layout = "no" Variant = "(null)" Options = "(null)"
winPointerWarpCursor - Discarding first warp: 1440 600
winBlockHandler - Releasing pmServerStarted
winBlockHandler - pthread_mutex_unlock () returned
winInitMultiWindowWM - pthread_mutex_lock () returned.
winInitMultiWindowWM - Calling setlocale ()
winInitMultiWindowWM - setlocale () returned
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0
winProcEstablishConnection - Hello
winInitClipboard ()
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winClipboardProc - XInitThreads () returned.
winClipboardProc - DISPLAY=127.0.0.1:0.0
winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display.
winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display.
winClipboardProc - XOpenDisplay () returned and successfully opened the display.
winClipboardWindowProc - WM_CREATE
winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning.
winClipboardWindowProc - WM_DRAWCLIPBOARD - We own the clipboard, returning.
winProcSetSelectionOwner - We currently own the clipboard, releasing ownership.
winClipboardWindowProc - WM_DRAWCLIPBOARD - Clipboard is unowned.
winClipboardWindowProc - WM_DRAWCLIPBOARD - We own the clipboard, returning.
winClipboardWindowProc - WM_DRAWCLIPBOARD - We own the clipboard, returning.
winProcSetSelectionOwner - We currently own the clipboard, releasing ownership.
winClipboardWindowProc - WM_DRAWCLIPBOARD - Clipboard is unowned.

Re: XFree86-xserv-4.3.0-34 crash

[Harold L Hunt II]

Øyvind,

Øyvind Harboe wrote:

> This crash seems to be very similar to what I've seen in previous releases. I have the
> impression that it happens most often when I select a message in Evolution.

I believe that the crash is happening because there are no checks to 
make sure that the clipboards are only synchronized when supported 
formats (text and Unicode text) are being copied to the clipboard.

In other words, if you try to copy an image in X11 we will grab 
ownership of the Win32 clipboard and advertise that we have text ready 
to paste on the Win32 clipboard.  We will also grab ownership of the 
PRIMARY and CLIPBOARD selections in X11 when you copy an image in Win32 
and we will attempt to request the clipboard data in CF_TEXT or 
CF_UNICODETEXT formats when that data is pasted in X11; obviously, this 
does not work.

I do not believe that there were ever any reals checks to prevent this 
from happening before... or maybe it just worked out that checks were 
not needed as a side effect of how the previous system worked.

In any case, I am writing up a list of things that need to be done to 
ensure that we only synchronize the Win32 and X11 clipboards when 
supported formats (text and Unicode text) are being advertised on either 
clipboard.  In all other cases we need to keep the Win32 and X11 
clipboards independent of each other so that they don't try to transfer 
unsupported formats between each other.

This will probably be posted as XFree86-xserv-4.3.0-35 later today or in 
a few days.

Thanks for testing,

Harold