[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#509796: marked as done (Deadlock in libxrandr2.so)

Your message dated Fri, 2 Jan 2009 18:48:19 +0100
with message-id <20090102174818.GF4922@patate.is-a-geek.org>
and subject line Re: Bug#509796: Deadlock in libxrandr2.so
has caused the Debian Bug report #509796,
regarding Deadlock in libxrandr2.so
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
509796: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509796
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libxrandr2
Version: 2:1.1.0.2-5
Severity: normal
Debian Release: etch/stable
Architecture: i386

I have wrote a simple example that do the following:
XInitThreads
XOpenDisplay
XDefaultScreen
XRRTimes
XCloseDisplay
It appears that proccess hangs in XRRTimes while trying to _XLockDisplay for a second time. 

Breakpoint 2, _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
485     ../../src/locking.c: No such file or directory.
       in ../../src/locking.c
(gdb) bt
#0  _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
#1 0xb7fe1b1a in XRRTimes (dpy=0x8353e48, screen=0, config_timestamp=0xbfecb524) at ../../src/Xrandr.c:321 
(gdb) c
Continuing.

Breakpoint 2, _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
485     in ../../src/locking.c
(gdb) bt
#0  _XLockDisplay (dpy=0x8353e48) at ../../src/locking.c:485
#1 0xb730ee36 in XQueryExtension (dpy=0x8353e48, name=0xb7fe2188 "RANDR", major_opcode=0xbfecb3d0, first_event=0xbfecb3d4, 
   first_error=0xbfecb3d8) at ../../src/QuExt.c:46
#2 0xb730360b in XInitExtension (dpy=0x8353e48, name=0xb7fe2188 "RANDR") at ../../src/InitExt.c:49 
#3  0xb72d6ea3 in XextAddDisplay () from /usr/lib/libXext.so.6
#4  0xb7fe0f29 in XRRFindDisplay (dpy=0x8353e48) at ../../src/Xrandr.c:139
#5 0xb7fe1aa7 in _XRRValidateCache (dpy=0x832fd10, screen=137707080) at ../../src/Xrandr.c:242 #6 0xb7fe1b24 in XRRTimes (dpy=0x8353e48, screen=0, config_timestamp=0xbfecb524) at ../../src/Xrandr.c:322

Attachment: xrandr_test.tar.bz2
Description: application/bzip


--- End Message ---
--- Begin Message --- 
Version: 2:1.2.0-1

On Fri, Dec 26, 2008 at 15:08:32 +0300, Oleg Malashenko wrote:

> I have wrote a simple example that do the following:
> XInitThreads
> XOpenDisplay
> XDefaultScreen
> XRRTimes
> XCloseDisplay
>
> It appears that proccess hangs in XRRTimes while trying to _XLockDisplay  
> for a second time.
>
This was fixed upstream in libXrandr 1.2.0:

commit 36a4a633a93a89bd854f49e670777925c9751de3
Author: Keith Packard <keithp@neko.keithp.com>
Date:   Sat Jan 6 12:42:47 2007 -0800

    Avoid nested LockDisplay calls.
    
    XRRFindDisplay must make extension requests that use LockDisplay, so don't
    call it with the display locked, instead pass the info around to the
    internal functions that were calling it themselves, having acquired the info
    before the outer LockDisplay is called.


Cheers,
Julien

--- End Message ---
Reply to: