RE: Updated: XFree86-xserv-4.3.0-33

RE: Updated: XFree86-xserv-4.3.0-33

[Andrew Braverman]

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

I seem to be the one not to have any luck lately.  I tried running this
package and get a standard windows "XWin-33.exe has encountered a problem
and needs to close.  We are sorry for the inconvenience." message.  There
was no useful stackdump.  After going through my batch file, I found that if
I put a "sleep 2" before the "xhost +hostname" command that I have in the
file, XWin does not crash.  If I use "sleep 1", it sometimes crashes.  With
no sleep, it crashes.  I have attached an XWin.log from one of the attempts
with no sleep.

- Andy

> -----Original Message-----
> From: cygwin-xfree-announce-owner@cygwin.com
> [mailto:cygwin-xfree-announce-owner@cygwin.com]On Behalf Of Harold L
> Hunt II
> Sent: Thursday, January 08, 2004 2:32 AM
> To: cygxannounce
> Subject: Updated: XFree86-xserv-4.3.0-33
>
>
> Announcement
> ============
>
> The XFree86-xserv-4.3.0-33 'test' package has been updated in
> the Cygwin
> distribution.
>
>
> Links
> =====
>
> Server source, direct link:
> http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040107-2
315.tar.bz2
> (137 KiB)
>
> xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-32
> source code:
> http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-32-t
> o-4.3.0-33.diff
> (113 KiB)
>
>
> Changes
> =======
>
> 1) General - If you use the diff above, note that the Imakefile was
> missing from previous tarballs, so this diff includes the whole
> Imakefile.  I have updated my source packaging script so that this
> does not happen again.  Also, the source code in this release has
> already been committed to the xorg repository on freedesktop.org's
> CVS.  (Harold L Hunt II)
>
> 2) winauth.c - New File - Move winGenerateAuthorization into this new
> file.  This function generates a cookie to be used by the clipboard
> client for authorization when using Xdmcp.  (Harold L Hunt II)
>
> 3) winglobals.c - New File - Start moving global variables into this
> file.  (Harold L Hunt II)
>
> 4) winclipboardwrappers.c - New File - Move all clipboard wrappers of
> ProcVector and InitialVector funtions into this file.
> (Harold L Hunt II)
>
> 5) winprocarg.c - New File - Move winInitializeDefaultScreens and
> ddxProcessArgument from InitOutput.c into this file.  The same will be
> done eventually for other functions in InitOutput.c.  (Harold L Hunt
> II)
>
> 6) win.h, General - Get started on removing "extern" declarations
> from win.h by including explicit references to extern symbols in the
> source files that use those symbols.  The long term goal is to start
> breaking up the monolithic win.h header file.  (Harold L Hunt II)
>
> 7) Xserver/dix/dispatch.c/Dispatch() - Add hook to OsVendorReset
> function that can be optionally defined in the DDX layer when
> DDXOSRESET is defined.  (Harold L Hunt II)
>
> 8) InitOutput.c/OsVendorReset() - New Function - Send a message to
> the clipboard client telling it to shutdown, then wait for the
> clipboard client thread to exit before proceeding.  This allows us to
> cleanly shutdown the clipboard client.  Incidentally, I noticed that
> the previous code would spawn *additional* clipboard client threads
> when the X Server was reset; this was happening because we trapped IO
> errors and attempted to reconnect when they happened.  There was no
> code that told a clipboard client thread to exit when the server was
> being reset so that it could be replaced by a new clipboard client
> thread (which was happening correctly).  This should lead to greater
> stability across X Server resets, though I did discover that this
> version and previous versions where shutting down after two or three
> resets without any error message being logged nor exception being
> thrown.  That problem will be looked into later.  (Harold L Hunt
> II)
>
> 9) winclipboardinit.c, winclipboardthread.c, winclipboardxevents.c,
> winclipboardwndproc.c - Fix problems getting killed by Xdmcp code and
> remote XDM/KDM/GDM client on startup.  Fix problems not being
> authorized to connect when using Xdmcp by calling XSetAuthorization
> and passing it our cookie that was created earlier; this removes the
> need to save the cookie to a .Xauthority file.  Watch the CLIPBOARD
> selection in addition to the PRIMARY selection and track which was
> changed within X last so that we know which one we should paste within
> Win32.  Fix crashes when the server resets (as explained above, it
> still exits after one or two resets, for an unknown reason).  The
> improved clipboard code should now be good to go.  (Harold L Hunt
> II)
>
> 10) winmultiwindowwm.c - Clean up the startup of the two multi-window
> threads.  Create separate error and IO error handlers for the XMsgProc
> thread since it was using the same IO error handler as another thread
> and would try to longjmp into the other thread if it received an IO
> error, which was likely causing some crashes.  The multi-window code
> needs additional work to confirm that it properly shuts down and exits
> both threads; something similar to the clipboard shutdown message in
> OsVendorReset will be needed.  (Harold L Hunt II)
>
> 11) winclipboardxevents.c - Find and fix a last minute bug that caused
> Unicode clipboard translations to be broken.  (Kensuke Matsuzaki,
> Harold L Hunt II)
>
> --
> Harold Hunt
>
> To update your installation, click on the "Install Cygwin now" link on
> the http://cygwin.com/ web page.  This downloads setup.exe to your
> system.  Once you've downloaded setup.exe, run it and select "XFree86"
> and then click on the appropriate field until the above announced
> version number appears if it is not displayed already.
>
> If your mirror doesn't yet have the latest version of this
> package after
> 24 hours, you can either continue to wait for that site to be
> updated or
> you can try to find another mirror.
>
> Please send questions or comments to the Cygwin/X mailing list at:
> cygwin-xfree@cygwin.com
>
> If you want to subscribe go to:
> http://cygwin.com/ml/cygwin-xfree/
>
> I would appreciate if you would use this mailing list rather than
> emailing me directly.  This includes ideas and comments about
> the setup
> utility or Cygwin/X in general.
>
> If you want to make a point or ask a question the Cygwin/X mailing
> list is the appropriate place.
>

[-- Attachment #2: XWin.log --]
[-- Type: application/octet-stream, Size: 3453 bytes --]

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1280 h 1024
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
winScreenInit - dwWidth: 1280 dwHeight: 1024
winSetEngine - Multi Window => ShadowGDI
winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel
winCreateBoundingWindowWindowed - User w: 1280 h: 1024
winCreateBoundingWindowWindowed - Current w: 1280 h: 1024
winAdjustForAutoHide - Original WorkArea: 0 0 990 1280
winAdjustForAutoHide - Adjusted WorkArea: 0 0 990 1280
winCreateBoundingWindowWindowed - WindowClient w 1280 h 990 r 1280 l 0 b 990 t 0
winCreateBoundingWindowWindowed -  Returning
winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 990 depth: 16
winAllocateFBShadowGDI - Dibsection width: 1280 height: 990 depth: 16 size image: 2534400
winAllocateFBShadowGDI - Created shadow stride: 1280
winFinishScreenInitFB - Masks: 0000f800 000007e0 0000001f
winInitVisualsShadowGDI - Masks 0000f800 000007e0 0000001f BPRGB 6 d 16 bpp 16
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 ()
LoadPreferences: Done parsing the configuration file...
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: "00000409" (00000409) 
(EE) No primary keyboard configured
(==) Using compiletime defaults for keyboard
Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)"
winPointerWarpCursor - Discarding first warp: 640 495
winBlockHandler - Releasing pmServerStarted
winInitMultiWindowWM - pthread_mutex_lock () returned.
winInitMultiWindowWM - Calling setlocale ()
winBlockHandler - pthread_mutex_unlock () returned
winProcEstablishConnection - Hello
winInitClipboard ()
winProcEstablishConnection - winInitClipboard returned.
winClipboardProc - Hello
DetectUnicodeSupport - Windows NT/2000/XP
winClipboardProc - Calling setlocale ()
OsVendorReset - Hello
winInitMultiWindowWM - setlocale () returned
winMultiWindowXMsgProc - pthread_mutex_lock () returned.
winMultiWindowXMsgProc - pthread_mutex_unlock () returned.
winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0
winInitMultiWindowWM - pthread_mutex_unlock () returned.
winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0

Re: Updated: XFree86-xserv-4.3.0-33

[Harold L Hunt II]

Andrew Braverman wrote:

> I seem to be the one not to have any luck lately.  I tried running this
> package and get a standard windows "XWin-33.exe has encountered a problem
> and needs to close.  We are sorry for the inconvenience." message.  There
> was no useful stackdump.  After going through my batch file, I found that if
> I put a "sleep 2" before the "xhost +hostname" command that I have in the
> file, XWin does not crash.  If I use "sleep 1", it sometimes crashes.  With
> no sleep, it crashes.  I have attached an XWin.log from one of the attempts
> with no sleep.
> 
> - Andy

Andy,

You should not need the 'xhost +hostname' unless hostname is a remote host.

Have you tried without the -clipboard parameter to confirm whether the 
problem persists in that case?

Harold

RE: Updated: XFree86-xserv-4.3.0-33

[Andrew Braverman]

I had not checked, but I just did.  If I remove the -clipboard and the
sleep, all is well.  As another data point, a longer sleep is needed if the
files are run on windows login (which is not surprising).

On a different note, I have noticed that the X clipboard will transfer to
windows as long as the data is highlighted.  Once the data is unhighlighted
(i.e. typing "clear") the text is still in the X buffer (middle button or
shift insert pastes correctly), but the windows clipboard is empty.

- Andy

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com
> [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Harold L Hunt II
> Sent: Thursday, January 08, 2004 10:20 AM
> To: cygwin-xfree@cygwin.com
> Subject: Re: Updated: XFree86-xserv-4.3.0-33
>
>
> Andrew Braverman wrote:
>
> > I seem to be the one not to have any luck lately.  I tried
> running this
> > package and get a standard windows "XWin-33.exe has
> encountered a problem
> > and needs to close.  We are sorry for the inconvenience."
> message.  There
> > was no useful stackdump.  After going through my batch
> file, I found that if
> > I put a "sleep 2" before the "xhost +hostname" command that
> I have in the
> > file, XWin does not crash.  If I use "sleep 1", it
> sometimes crashes.  With
> > no sleep, it crashes.  I have attached an XWin.log from one
> of the attempts
> > with no sleep.
> >
> > - Andy
>
> Andy,
>
> You should not need the 'xhost +hostname' unless hostname is
> a remote host.
>
> Have you tried without the -clipboard parameter to confirm
> whether the
> problem persists in that case?
>
> Harold
>

Re: Updated: XFree86-xserv-4.3.0-33

[Harold L Hunt II]

Andrew,

Andrew Braverman wrote:
> I had not checked, but I just did.  If I remove the -clipboard and the
> sleep, all is well.  As another data point, a longer sleep is needed if the
> files are run on windows login (which is not surprising).

Your crash is possibly due to xhost being the first X Client to 
connect... when it disconnects, the X Server tries to reset.  There may 
be some problems in -clipboard that cause a crash in such a quick server 
startup followed by a reset.  I have tried to fix those problems, but it 
is going to take me a while to find all of the bugs that have krept into 
the server reset code.  Currently you can't even reset the server more 
than twice, without -clipboard and without -multiwindow, before it just 
exits without a warning or error message.  So, you are likely to have to 
work around this problem for a while if it doesn't magically go away in 
the next release.  For now, I would just drop the xhost command from 
your startup file.

> On a different note, I have noticed that the X clipboard will transfer to
> windows as long as the data is highlighted.  Once the data is unhighlighted
> (i.e. typing "clear") the text is still in the X buffer (middle button or
> shift insert pastes correctly), but the windows clipboard is empty.

That is an interesting point that I had thought of, but didn't really 
want to think hard about :)  I spent about 12 hours coding this up... 
everytime I thought I had it, I realized that more basic changes were 
needed in the clipboard code.  Now I have it working, I believe.

One of the funniest things that I fixed was that we were creating one 
clipboard thread *per* screen.  I realized, in looking at 
xc/programs/Xserver/dix/dispatch.c, that the selections are global to 
all screens running on the same display (or instance of XWin.exe).  So, 
we really only needed one clipboard client thread, no matter how many 
-screen parameters were passed to XWin.exe.  I changed the code to 
create just one clipboard client thread for the entire process... that 
really simplified the process of changing the code, since I didn't have 
to track things per-screen anymore.

I have made your request work only for the PRIMARY and CLIPBOARD 
selections.  It won't matter if the X client still has data in the 
SECONDARY selection, because we do not monitor that selection.  So, 
don't complain if you can still paste in one or two X apps but not in 
Win32 :)

Harold

XFree86-xserv-4.3.0-38 test results

[Andrew Braverman]

> [...]  For now, I would just drop the xhost command from
> your startup file.

No problem.  I can deal with it as long as you are aware of the issue.

>
> > On a different note, I have noticed that the X clipboard
> will transfer to
> > windows as long as the data is highlighted.  Once the data
> is unhighlighted
> > (i.e. typing "clear") the text is still in the X buffer
> (middle button or
> > shift insert pastes correctly), but the windows clipboard is empty.
>
> That is an interesting point that I had thought of, but didn't really
> want to think hard about :)  I spent about 12 hours coding this up...
> everytime I thought I had it, I realized that more basic changes were
> needed in the clipboard code.  Now I have it working, I believe.

It seems to work now.  Thanks.

> I have made your request work only for the PRIMARY and CLIPBOARD
> selections.  It won't matter if the X client still has data in the
> SECONDARY selection, because we do not monitor that selection.  So,
> don't complain if you can still paste in one or two X apps but not in
> Win32 :)

I try not to COMPLAIN about anything. :-)  Seriously, though - I do realize
how much time and energy are put into this project by the few core people
and though I will report issues I see or ask questions, I will never
complain about what is or is not done.  You guys do too much work to deserve
that.  One of these days, I will make enough time to make some contributions
of my own - and then I MIGHT have a right to complain a little.  You guys
have done a wonderful job, and as many have said before, we appreciate your
work.  Thank you.

>
> Harold
>

OS: Windows XP

Language: English

Win32->X11 Copy and Paste: Worked

X11->Win32 Copy and Paste: Worked

Xdmcp: Did Not Try


- Andy

Re: XFree86-xserv-4.3.0-38 test results

[Harold L Hunt II]

Andrew,

Andrew Braverman wrote:
>>[...]  For now, I would just drop the xhost command from
>>your startup file.
> 
> 
> No problem.  I can deal with it as long as you are aware of the issue.

Okay.  I think it needs to be fixed eventually so that the problem is 
not repeatedly reported.

>>>On a different note, I have noticed that the X clipboard
>>
>>will transfer to
>>
>>>windows as long as the data is highlighted.  Once the data
>>
>>is unhighlighted
>>
>>>(i.e. typing "clear") the text is still in the X buffer
>>
>>(middle button or
>>
>>>shift insert pastes correctly), but the windows clipboard is empty.
>>
>>That is an interesting point that I had thought of, but didn't really
>>want to think hard about :)  I spent about 12 hours coding this up...
>>everytime I thought I had it, I realized that more basic changes were
>>needed in the clipboard code.  Now I have it working, I believe.
> 
> 
> It seems to work now.  Thanks.

No problem.

>>I have made your request work only for the PRIMARY and CLIPBOARD
>>selections.  It won't matter if the X client still has data in the
>>SECONDARY selection, because we do not monitor that selection.  So,
>>don't complain if you can still paste in one or two X apps but not in
>>Win32 :)
> 
> 
> I try not to COMPLAIN about anything. :-)  Seriously, though - I do realize
> how much time and energy are put into this project by the few core people
> and though I will report issues I see or ask questions, I will never
> complain about what is or is not done.  You guys do too much work to deserve
> that.  One of these days, I will make enough time to make some contributions
> of my own - and then I MIGHT have a right to complain a little.  You guys
> have done a wonderful job, and as many have said before, we appreciate your
> work.  Thank you.

Sorry.  My "complain" should be read as more of a "I am already aware of 
this problem, so it doesn't have to be mentiond" and it was really 
written for other readers, not for you.  I don't think you are 
complaining :)  It is just that if others see this in the future, I 
don't want them saying "me too" if they notice this problem.

> OS: Windows XP
> 
> Language: English
> 
> Win32->X11 Copy and Paste: Worked
> 
> X11->Win32 Copy and Paste: Worked
> 
> Xdmcp: Did Not Try

Thanks for testing!

Harold