Re: 2.3.2 beta 2 hang
Re: 2.3.2 beta 2 hang
- Subject: Re: 2.3.2 beta 2 hang
- From: robert delius royar <email@hidden>
- Date: Wed, 29 Oct 2008 08:24:38 -0400
- Organization: An Apple OS X end user
- Priority: normal
Tue, 28 Oct 2008 (15:01 -0700 UTC) Jeremy Huddleston wrote:
Yeah... we've had a couple of reports that boil down to this bug over the
past year...
We need to fix this by either making the xp_ stuff thread safe (preferred) or
by making sure only the server thread calls into xp_*() (probably not ideal,
but it's what I did with the older bugs).
sendX11Event had the following check added recently. Basically, it prevents
a mouse event from being sent to the server while another OSX application is
in the foreground unless the window under the mouse cursor is an X11 window.
if(!quartzServerVisible) {
952 xp_window_id wid;
...
960 wid = 0;
961 xp_find_window(pointer_x, pointer_y, 0, &wid);
962
963 if (wid == 0)
964 return;
965 }
This should be the only xp_* call that is in the AppKit thread and why the
bug is new/back in 2.3.2_beta2.
I am running XQuartz 2.3.2 (xorg-server 1.4.2-apple20) (2.3.2beta1), and
I have seen a similar hang, emailed a trace to you earlier. I also
noticed that I no longer see X11 windows that are behind OSX windows
respond to mouse movements that are over the OSX window that obscures
the X11 window. I used to see the (buggy) reaction of X11 windows when
the mouse was over the area those windows occupied but an OSX
application was in the foreground and actively accepting input.
Now, I see the focus move to partially obscured X11 windows only when
X11 is the topmost application. I have wm_ffm set. I do still see
something that to me seems odd: if the X11 windows are interleaved with
OSX windows with X11 in the foreground (e.g. xterm has focus and is
topmost; Safari is next and partially obscures another X11 xterm), if I
move my mouse out of the top xterm and over the Safari window (without
raising Safari), then the xterm beneath the Safari window receives focus
whenever the mouse hovers over the area that it occupies which is
beneath Safari's window. However, I believe that is how the system has
to work. On the other hand were OSX to support FFM for all
applications, then I suppose this would not be correct behavior.
On Oct 28, 2008, at 13:00, Greg Parker wrote:
On Oct 28, 2008, at 6:27 AM, Jamie Kennea wrote:
> I've experienced a couple of hangs of X11, i.e. permanent beach balls. I
> can't figure out the cause, however I've attached the output of Activity
> Monitor's sample.
I see two threads in _xp_synchronize:
> 1619 -[X11Application(Private) sendX11NSEvent:]
> 1619 xp_find_window
> 1619 xp_synchronize
> 1619 _xp_synchronize
> 1619 _xp_async_dequeue
> 1619 pthread_cond_wait$UNIX2003
> 1586 __semwait_signal
> 1586 __semwait_signal
> 32 0xffffffff
> 32 _sigtramp
> 32 _sigtramp
> 1 __spin_lock
> 1 __spin_lock
> 1619 RootlessStartDrawing
> 1619 xprStartDrawing
> 1619 xp_lock_window
> 1619 xp_synchronize
> 1619 _xp_synchronize
> 1619 _xp_async_dequeue
> 1619 pthread_cond_wait$UNIX2003
> 1619 __semwait_signal
> 1619 __semwait_signal
I don't like this xp-async stuff at all. I haven't examined the entire
threading structure, but several things look suspicious. Unless there's
some higher-level locking going on, these are likely to be bugs:
* If I understand _xp_synchronize correctly, the above sample has two
threads processing events from the same queue until a target event is
found. But if each thread happens to grab the other thread's target event,
they'll both spin the queue forever without finding what they want.
* I don't see any locks around the use of next_serial.
* If one thread calls _xp_do_request and another calls xp_synchronize(),
they'll both use the same value from next_serial, which means at least one
will fail to dequeue the event it's looking for.
* While they're processing the queue the two threads are firing arbitrary
events on effectively random threads. Unless the event callbacks themselves
lock something, you'll get corruption.
There's also a signal that arrived while the main thread was trying to
dequeue. I think that's harmless; it looks like _xp_async_dequeue has the
right spurious wakeup checks around its condition variable. In any case,
the app had presumably already hanged before this sample started.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Dr. Robert Delius Royar Associate Professor of English
Morehead State University Morehead, Kentucky
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden