Re: Why is XSetStandardProperties freezing?
>> >> OK, will do that. I assume your suggestion means that (from my >> description) this looks likely to be an OpenSuse problem and not the >> fault of the library for not doing some essential synchronization. >> > > At least it is something they have to explain :) > > re, > wh OK, I moved the question to OpenSuse-xorg mailing list and filed the bug report as well. The problem appears to be a bug in the XLib version used in OpenSuse 12.1, and fixed in upstream and also in the XLib version that ships with 11.2 http://lists.opensuse.org/opensuse-xorg/2012-06/msg00019.html https://bugzilla.novell.com/show_bug.cgi?id=768775 Thanks everyone for your help. Myrosia ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
Am 22.06.2012 16:52, schrieb Myrosia Dzikovska: >> You are quiet advanced with that, you should setup a bugreport >> at opensuse: https://bugzilla.novell.com/index.cgi >> >> there is also a special mailinglist for opensuse: opensuse-x...@opensuse.org >> > > OK, will do that. I assume your suggestion means that (from my > description) this looks likely to be an OpenSuse problem and not the > fault of the library for not doing some essential synchronization. > At least it is something they have to explain :) re, wh ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
> You are quiet advanced with that, you should setup a bugreport > at opensuse: https://bugzilla.novell.com/index.cgi > > there is also a special mailinglist for opensuse: opensuse-x...@opensuse.org > OK, will do that. I assume your suggestion means that (from my description) this looks likely to be an OpenSuse problem and not the fault of the library for not doing some essential synchronization. Myrosia ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
Am 21.06.2012 23:13, schrieb Myrosia Dzikovska:
> On Thu, Jun 21, 2012 at 3:07 PM, Adam Jackson wrote:
>> On Thu, 2012-06-21 at 13:08 +0100, Myrosia Dzikovska wrote:
>>
>>> TASKTYPE TASKMOD XEventThread(void *data)
>>> {
>>>XEvent xev;
>>>HEventRec r;
>>>HWin win;
>>>HThread t;
>>>do{
>>> XNextEvent(globDisp, &xev);
>>> r=convertXevToHEventRec(xev);
>>> if(r.event != HIGNORE) {
>>> win=FindWindowRec(xev.xany.window);
>>> t=win->theThread;
>>> postEventToQueue(t, r);
>>> }
>>> HFlush();
>>>}
>>>while(True);
>>> }
>>>
>>> Basically, it's taking up X events and re-posting them into queues
>>> handled by the apps with the convertXevToHEventRec and
>>> postEventToQueue calls.
>>>
>>> If I disable the creation of that thread, nothing freezes anymore, but
>>> the apps that depend on the library start misbehaving (e.g., windows
>>> not reacting properly to close events).
>>>
>>> I tried adding XLockDisplay/XUnlockDisplay around the calls to
>>> XNextEvent, but that does not work because it blocks waiting for
>>> events and the display is permanently locked.
>>
>> Do you mean you halt in XLockDisplay, or in XNextEvent? If the former,
>> then xlib is probably already locked by another thread. If the latter,
>> then perhaps you didn't call XInitThreads, or didn't call it early
>> enough.
>>
>> Alternatively, the OSes you're comparing may not have identical versions
>> of libX11 and libxcb, and the failing one is missing a thread-safety
>> fix.
>
>
> Sorry, I wasn't clear enough. This is what appears to be happening.
>
> On the OS that does not work (OpenSuse 12.1)
> 1. XInitThreads is called
> 2. A thread ("XEventThread") created by the library and starts executing
> 3. XEventThread calls XNextEvent
> 4. XNextEvent blocks waiting for events; it does not return
> immediately because there are no windows yet
> 5. XEventThread releases control to the main app thread
> 6. the main app thread calls XLockScreen
> 7 the main app thread starts creating windows
> 8. The first call to X functions, e.g. XCreateSimpleWindow, hangs
> This is with XSyncrhonize enabled; if it is disabled, a few X calls
> will succeed, but eventually something will hang forever.
>
> On the OSes that work (FC13, ScientificLinux 6) the difference is
> point 8 - the calls to X never lock, everything proceeds happily.
>
> I cannot call XLockScreen on the XEventThread because this creates a
> deadlock with the main app thread while it's sitting there waiting.
>
You are quiet advanced with that, you should setup a bugreport
at opensuse: https://bugzilla.novell.com/index.cgi
there is also a special mailinglist for opensuse: opensuse-x...@opensuse.org
hope that helps,
re,
wh
> Would this be evidence for your last suggestion, that OpenSuse libX11
> or libxcb are missing some thread safety fix? Or is this bad X
> synchronization and it would eventually break on a different OS as
> well? I am not entirely clear if every call to X has to be locked or
> not, and what to do with the blocking XNextEvent in that case.
>
> If it is the former, then I need to figure out what to report to
> OpenSuse; if this is the latter, I need to figure out if there is a
> way to make it thread safe (not my design idea, but this is very core
> to the library, so I need to see if I can salvage it without getting
> into a big "re-write the whole library" deal).
>
> Myrosia
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.x.org/mailman/listinfo/xorg
> Your subscription address: wha...@bfs.de
>
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
On Thu, Jun 21, 2012 at 3:07 PM, Adam Jackson wrote:
> On Thu, 2012-06-21 at 13:08 +0100, Myrosia Dzikovska wrote:
>
>> TASKTYPE TASKMOD XEventThread(void *data)
>> {
>> XEvent xev;
>> HEventRec r;
>> HWin win;
>> HThread t;
>> do{
>> XNextEvent(globDisp, &xev);
>> r=convertXevToHEventRec(xev);
>> if(r.event != HIGNORE) {
>> win=FindWindowRec(xev.xany.window);
>> t=win->theThread;
>> postEventToQueue(t, r);
>> }
>> HFlush();
>> }
>> while(True);
>> }
>>
>> Basically, it's taking up X events and re-posting them into queues
>> handled by the apps with the convertXevToHEventRec and
>> postEventToQueue calls.
>>
>> If I disable the creation of that thread, nothing freezes anymore, but
>> the apps that depend on the library start misbehaving (e.g., windows
>> not reacting properly to close events).
>>
>> I tried adding XLockDisplay/XUnlockDisplay around the calls to
>> XNextEvent, but that does not work because it blocks waiting for
>> events and the display is permanently locked.
>
> Do you mean you halt in XLockDisplay, or in XNextEvent? If the former,
> then xlib is probably already locked by another thread. If the latter,
> then perhaps you didn't call XInitThreads, or didn't call it early
> enough.
>
> Alternatively, the OSes you're comparing may not have identical versions
> of libX11 and libxcb, and the failing one is missing a thread-safety
> fix.
Sorry, I wasn't clear enough. This is what appears to be happening.
On the OS that does not work (OpenSuse 12.1)
1. XInitThreads is called
2. A thread ("XEventThread") created by the library and starts executing
3. XEventThread calls XNextEvent
4. XNextEvent blocks waiting for events; it does not return
immediately because there are no windows yet
5. XEventThread releases control to the main app thread
6. the main app thread calls XLockScreen
7 the main app thread starts creating windows
8. The first call to X functions, e.g. XCreateSimpleWindow, hangs
This is with XSyncrhonize enabled; if it is disabled, a few X calls
will succeed, but eventually something will hang forever.
On the OSes that work (FC13, ScientificLinux 6) the difference is
point 8 - the calls to X never lock, everything proceeds happily.
I cannot call XLockScreen on the XEventThread because this creates a
deadlock with the main app thread while it's sitting there waiting.
Would this be evidence for your last suggestion, that OpenSuse libX11
or libxcb are missing some thread safety fix? Or is this bad X
synchronization and it would eventually break on a different OS as
well? I am not entirely clear if every call to X has to be locked or
not, and what to do with the blocking XNextEvent in that case.
If it is the former, then I need to figure out what to report to
OpenSuse; if this is the latter, I need to figure out if there is a
way to make it thread safe (not my design idea, but this is very core
to the library, so I need to see if I can salvage it without getting
into a big "re-write the whole library" deal).
Myrosia
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
On Thu, 2012-06-21 at 13:08 +0100, Myrosia Dzikovska wrote:
> TASKTYPE TASKMOD XEventThread(void *data)
> {
>XEvent xev;
>HEventRec r;
>HWin win;
>HThread t;
>do{
> XNextEvent(globDisp, &xev);
> r=convertXevToHEventRec(xev);
> if(r.event != HIGNORE) {
> win=FindWindowRec(xev.xany.window);
> t=win->theThread;
> postEventToQueue(t, r);
> }
> HFlush();
>}
>while(True);
> }
>
> Basically, it's taking up X events and re-posting them into queues
> handled by the apps with the convertXevToHEventRec and
> postEventToQueue calls.
>
> If I disable the creation of that thread, nothing freezes anymore, but
> the apps that depend on the library start misbehaving (e.g., windows
> not reacting properly to close events).
>
> I tried adding XLockDisplay/XUnlockDisplay around the calls to
> XNextEvent, but that does not work because it blocks waiting for
> events and the display is permanently locked.
Do you mean you halt in XLockDisplay, or in XNextEvent? If the former,
then xlib is probably already locked by another thread. If the latter,
then perhaps you didn't call XInitThreads, or didn't call it early
enough.
Alternatively, the OSes you're comparing may not have identical versions
of libX11 and libxcb, and the failing one is missing a thread-safety
fix.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
Thanks. First. I tried a bunch of different window managers across all
systems. And it either works on all of them (on the systems where it
works),
or on none of them. So not a WM issue.
> I would probably start by calling XSynchronize(dpy, 1) just after
> XOpenDisplay, to see if that changes where the hang happens.
>
Ah, I think I may know what the problem is, but not how to fix it.
Adding X changed where the hang happens, and now it is consistently
slightly earlier,
at a call to XCreateSimpleWindow
win->theWindow = XCreateSimpleWindow(win->theDisp, win->rootW, x, y,
w, h, bw, black, white );
But turns out that just before that call the library sets up and
starts a new thread (using pthreads) running the loop below, and I
think it's the thread that causes the deadlock.
TASKTYPE TASKMOD XEventThread(void *data)
{
XEvent xev;
HEventRec r;
HWin win;
HThread t;
do{
XNextEvent(globDisp, &xev);
r=convertXevToHEventRec(xev);
if(r.event != HIGNORE) {
win=FindWindowRec(xev.xany.window);
t=win->theThread;
postEventToQueue(t, r);
}
HFlush();
}
while(True);
}
Basically, it's taking up X events and re-posting them into queues
handled by the apps with the convertXevToHEventRec and
postEventToQueue calls.
If I disable the creation of that thread, nothing freezes anymore, but
the apps that depend on the library start misbehaving (e.g., windows
not reacting properly to close events).
I tried adding XLockDisplay/XUnlockDisplay around the calls to
XNextEvent, but that does not work because it blocks waiting for
events and the display is permanently locked.
Does this seem to be a likely diagnosis? If so, is there the correct
way to do this without causing the deadlocks but without losing the
basic idea that the library relies on (copying X events to an
app-specific queue)?
Myrosia
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Why is XSetStandardProperties freezing?
On Thu, 2012-06-14 at 13:52 +0100, Myrosia Dzikovska wrote: > Hi, > > I have a program using an X graphics library that works on FC 13 and > ScientificLinux 6, but freezes on OpenSuse 12.1. I need to get it > running, and I am trying to determine the cause of failure. I'm not an > X developer, and because the library is complex, I am struggling to > come up with a minimal example. > > The specific cause of the problem is the call in the code: > XSetStandardProperties(win->theDisp, win->theWindow, wname, hgraf, > None, NULL, 0, &(win->hints)); > > I verified by putting print statements around it that it never > returns, the program freezes there. > > The initialization code is complex, but the best I can tell it boils down to > char *hgraf = "HGraf"; > win->theDisp = XOpenDisplay(0) > win->theScreen=DefaultScreen(win->theDisp); > win->rootW=RootWindow(win->theDisp, win->theScreen); > win->theWindow = XCreateSimpleWindow(win->theDisp, win->rootW, x, y, > w, h, bw, black, white ); > > > I am at a loss as to what I should be checking here, and what could > cause the program to hang at that XSetStandardProperties call, with no > error messages or exceptions. How can I debug this? I would probably start by calling XSynchronize(dpy, 1) just after XOpenDisplay, to see if that changes where the hang happens. Another strategy would be to compare the generated X protocol between the OSes that work and the ones that don't. You can use wireshark for this if you set DISPLAY=localhost:0 (and didn't start your X server with -nolisten tcp); alternatively, there's xscope(1). Are you using the same window manager across all systems? If not, that's a pretty likely place to start looking. - ajax signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
