Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 5, 2011, Thomas Fjellstrom wrote:
> On January 4, 2011, Thomas Fjellstrom wrote:
> > On January 4, 2011, Peter Wang wrote:
> > > On 2011-01-04, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > Another issue. Window movement. Seems with compiz, and a window with
> > > > a border/titlebar, we get sane amounts of window movement events,
> > > > but in ex_noframe, we get a ton. (I'm assuming the wm is compressing
> > > > all the events into just a few per window move)
> > > > 
> > > > At least thats what happens if I comment out that if at the bottom of
> > > > the configure event handler. Otherwise we never update the window's
> > > > position at all. It seems I don't even get that bogus configure event
> > > > the comment above mentions.
> > > > 
> > > > I'd like to also flag the code to update the display's new adapter
> > > > property there, but if that if is really needed, we never get a
> > > > chance. Can I just remove that check?
> > > 
> > > No, that's required.  I tried to remove it once, but confirmed the
> > > problem for myself.
> > 
> > It has to be done in some other way, or we never update the window
> > position. At least with compiz.
> 
> I just found out something interesting. the set_size_hint function seems to
> be breaking the fullscreen window positioning (window gets moved to not
> overlap gnome's top panel) and layering (panels layer over it). I ifed it
> out for fullscreen, and tested several wm's, including: kwin4, flwm,
> fluxbox, enlightenment, openbox, compiz and metacity. With the change, I
> think all of that stuff is fixed.
> 
> I've got a mostly complete patch now. Except I'm getting a deadlock (I
> think) on my laptop here, and I'm not sure how to track down whats causing
> it. valgrind (drd or hellgrind) only show data races (in the keyboard
> event, and ogl transforms code), not any deadlocks.
> 
> So, I'm posting the patch here, to see if anyone can find the deadlock
> before I can (going to bed soon, so it won't be for > 12 hours).
> 
> It still needs more native xrandr testing, this deadlock has stopped my
> testing in its tracks. Can't really test it if all it does is lock up.
> 
> oh, one important detail, ex_display_options locks up when you go
> fullscreen, then back to a window. It finishes destroying the fullscreen
> display, and updating the windowed display, /then/ it locks up.
> 
> > > Peter

I'm a little stuck here. It didn't seem to lock up for trentg on an older 
ubuntu, but here on debian with a really new X/Mesa/whatever I get this:

moose@xxxxxxxxxx$ gdb ./ex_display_options
GNU gdb (GDB) 7.2-debian
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from 
/home/moose/projects/allegro-5.1/build/examples/ex_display_options...done.
(gdb) r
Starting program: 
/home/moose/projects/allegro-5.1/build/examples/ex_display_options 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffef640710 (LWP 12967)]
[New Thread 0x7fffeb2ea710 (LWP 12968)]
^C
Program received signal SIGINT, Interrupt.
pthread_cond_wait@xxxxxxxxxx () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
162     ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such 
file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S
(gdb) thread apply all bt

Thread 3 (Thread 0x7fffeb2ea710 (LWP 12968)):
#0  0x00007ffff67f37dd in nanosleep () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007ffff75240be in al_rest (seconds=0.016580000000000154) at 
/home/moose/projects/allegro-5.1/src/unix/utime.c:68
#2  0x00007ffff74d4330 in timer_thread_proc (self=0x7ffff77b2480, unused=0x0) at 
/home/moose/projects/allegro-5.1/src/timernu.c:99
#3  0x00007ffff7524264 in thread_proc_trampoline (data=0x7ffff77b2480) at 
/home/moose/projects/allegro-5.1/src/unix/uxthread.c:36
#4  0x00007ffff67eb8ba in start_thread (arg=<value optimized out>) at 
pthread_create.c:300
#5  0x00007ffff219b02d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6  0x0000000000000000 in ?? ()

Thread 2 (Thread 0x7fffef640710 (LWP 12967)):
#0  __lll_lock_wait () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136
#1  0x00007ffff67ee104 in _L_lock_1024 () from /lib/libpthread.so.0
#2  0x00007ffff67edf67 in __pthread_mutex_lock (mutex=0x614f38) at 
pthread_mutex_lock.c:82
#3  0x00007ffff74cb5cf in _al_mutex_lock (m=0x614f30) at 
/home/moose/projects/allegro-5.1/include/allegro5/platform/aintuthr.h:60
#4  0x00007ffff7530f76 in xglx_background_thread (self=0x614ee8, arg=0x614e90) 
at /home/moose/projects/allegro-5.1/src/x/xsystem.c:132
#5  0x00007ffff7524264 in thread_proc_trampoline (data=0x614ee8) at 
/home/moose/projects/allegro-5.1/src/unix/uxthread.c:36
#6  0x00007ffff67eb8ba in start_thread (arg=<value optimized out>) at 
pthread_create.c:300
#7  0x00007ffff219b02d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#8  0x0000000000000000 in ?? ()

Thread 1 (Thread 0x7ffff7fb1a80 (LWP 12964)):
#0  pthread_cond_wait@xxxxxxxxxx () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
#1  0x00007ffff74cb65a in _al_cond_wait (cond=0xa43278, mutex=0xa43248) at 
/home/moose/projects/allegro-5.1/include/allegro5/platform/aintuthr.h:81
#2  0x00007ffff74c7ad8 in al_wait_for_event (queue=0xa43200, 
ret_event=0x7fffffffdf40) at /home/moose/projects/allegro-5.1/src/events.c:357
#3  0x000000000040316e in main () at 
/home/moose/projects/allegro-5.1/examples/ex_display_options.c:244
(gdb) 

The threads don't seem to be waiting on the same mutex, so how is it 
deadlocking?

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx