Bug Report: Locking X11 with FOX

[Hal Brand]

Both FOX V1.6.36 and V1.7.19 can lock-up X11 if the application
temporarily starves the FOX event loop.

We have applications that can have lots of work to do soon after
starting depending on many factors. We have observed X11 lock-ups (X
Server grabbed, but FOX not processing the events properly) on numerous
occasions. This is a problem with our application in the field as users
often start clicking as soon as the window appears.

This problem can be reproduced using at least one FOX test program with
simple mods to simulate the situation. (It will probably occur with any
FOX test application that involves pop-up menus (and maybe other pop-up,
server-grabbing widgets).) In this case, I have used a FXChore that
consumes a lot of CPU, then continually halves the CPU used until it
finally doesn't schedule itself any more.

Reproduction of the problem is simple. Build FOX, cd  into the tests/
directory and patch using the supplied context differences. (Note: these
differences were generated from V1.6.36, but can be applied to V1.7.19.)
Now, "make" and run the imageviewer. As soon as the window appears, left
mouse click on File, (don't wait for any action) then left mouse click
on Edit. With proper timing, the cursor will change from left pointing
to right pointing and your X session will be locked. Note that no amount
of mouse clicking anywhere will get results. Most window managers will
allow a keyboard escape. The one I use is CTRL-ALT-d which shrinks all
windows and releases the server grab.

It may be necessary to adjust the loop counter initial value (static int
c = 70000000;) for the machine running the test. The value chosen pretty
reliably locks my machine which is (from /proc/cpuinfo) "Intel(R)
Core(TM)2 Extreme CPU X9650  @ 3.00GHz".

I can provide a FOX -tracelevel <v> file if desired. The level 500 file
is 149KBytes so I guessed it best to send it by request.

--
Hal Brand



*** imageviewer.cpp.orig 2009-03-12 22:45:10.000000000 -0700
--- imageviewer.cpp 2009-06-08 15:48:02.000000000 -0700
***************
*** 74,79 ****
--- 74,81 ----
    long onCmdScale(FXObject*,FXSelector,void*);
    long onCmdCrop(FXObject*,FXSelector,void*);
    long onUpdImage(FXObject*,FXSelector,void*);
+   long onChore(FXObject*,FXSelector,void*);
+
  public:
    enum{
      ID_ABOUT=FXMainWindow::ID_LAST,
***************
*** 91,96 ****
--- 93,99 ----
      ID_MIRROR_BOTH,
      ID_SCALE,
      ID_CROP,
+     ID_CHORE,
      ID_LAST
      };
  public:
***************
*** 238,245 ****
--- 241,263 ----
    FXMAPFUNC(SEL_UPDATE,        ImageWindow::ID_MIRROR_BOTH,ImageWindow::onUpdImage),
    FXMAPFUNC(SEL_UPDATE,        ImageWindow::ID_SCALE,      ImageWindow::onUpdImage),
    FXMAPFUNC(SEL_UPDATE,        ImageWindow::ID_CROP,       ImageWindow::onUpdImage),
+   FXMAPFUNC(SEL_CHORE,ImageWindow::ID_CHORE,ImageWindow::onChore)
    };
 
+ long ImageWindow::onChore(FXObject*,FXSelector,void*)
+ {
+   static double d = 0.0;
+   static int c = 70000000;
+   FXTRACE((300,"ImageWindow::onChore In[%i]\n",c));
+   double sum = 0.0;
+   for (int i = 0; i < c; ++i)
+     sum += sin(double(i)/double(c));
+   d += sum;
+   c /= 2;
+   if (c > 1)
+     FXApp::instance()->addChore(this,ID_CHORE,0);
+   return 1;
+ }
 
  // Object implementation
  FXIMPLEMENT(ImageWindow,FXMainWindow,ImageWindowMap,ARRAYNUMBER(ImageWindowMap))
***************
*** 778,783 ****
--- 796,803 ----
    // Passed image file?
    if(argc>1) window->loadimage(argv[1]);
 
+   application.addChore(window,ImageWindow::ID_CHORE,0);
+
    // Run
    return application.run();
    }

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Niall Douglas]

On 8 Jun 2009 at 16:22, Hal Brand wrote:

> Both FOX V1.6.36 and V1.7.19 can lock-up X11 if the application
> temporarily starves the FOX event loop.

Are you using XInitThreads(), XIM or OpenGL?

Cheers,
Niall






------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Melton, Ryan]

I have also experienced X completely locking up with a high cpu intensive chore... I had to change by application architecture to avoid it.  Seems like an operating system bug to allow an application to lock the entire OS however.  Jeroen - any comments?

Ryan

-----Original Message-----
From: Hal Brand [mailto:brand1@...]
Sent: Monday, June 08, 2009 5:22 PM
To: foxgui-users@...; jeroen@...
Subject: [Foxgui-users] Bug Report: Locking X11 with FOX

Both FOX V1.6.36 and V1.7.19 can lock-up X11 if the application
temporarily starves the FOX event loop.

We have applications that can have lots of work to do soon after
starting depending on many factors. We have observed X11 lock-ups (X
Server grabbed, but FOX not processing the events properly) on numerous
occasions. This is a problem with our application in the field as users
often start clicking as soon as the window appears.

This problem can be reproduced using at least one FOX test program with
simple mods to simulate the situation. (It will probably occur with any
FOX test application that involves pop-up menus (and maybe other pop-up,
server-grabbing widgets).) In this case, I have used a FXChore that
consumes a lot of CPU, then continually halves the CPU used until it
finally doesn't schedule itself any more.

Reproduction of the problem is simple. Build FOX, cd  into the tests/
directory and patch using the supplied context differences. (Note: these
differences were generated from V1.6.36, but can be applied to V1.7.19.)
Now, "make" and run the imageviewer. As soon as the window appears, left
mouse click on File, (don't wait for any action) then left mouse click
on Edit. With proper timing, the cursor will change from left pointing
to right pointing and your X session will be locked. Note that no amount
of mouse clicking anywhere will get results. Most window managers will
allow a keyboard escape. The one I use is CTRL-ALT-d which shrinks all
windows and releases the server grab.

It may be necessary to adjust the loop counter initial value (static int
c = 70000000;) for the machine running the test. The value chosen pretty
reliably locks my machine which is (from /proc/cpuinfo) "Intel(R)
Core(TM)2 Extreme CPU X9650  @ 3.00GHz".

I can provide a FOX -tracelevel <v> file if desired. The level 500 file
is 149KBytes so I guessed it best to send it by request.

--
Hal Brand





This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Tuesday 09 June 2009, Melton, Ryan wrote:
> I have also experienced X completely locking up with a high cpu intensive chore... I had to change by application architecture to avoid it.  Seems like an operating system bug to allow an application to lock the entire OS however.  Jeroen - any comments?


Well,

I would need to investigate Hal Brand's particular case.

It appears to me that people are conflating several types of lock-ups:

        1) mouse grabs which aren't released when they're supposed to.

        2) getting stuck in select().


The former (1) is due to a failure of calling ungrab() along some path through the code;
note that this needs to be investigated on a case-by-case basis since there are MANY widgets
and thus many paths through the code whereby a call to ungrab() may be missed.

Number (2) is more fundamental O.S. related.  It'll need to be looked at carefully since
its possible there's some sort of race in the code leading up to select().



        - Jeroen

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hal Brand]

Niall Douglas wrote:

On 8 Jun 2009 at 16:22, Hal Brand wrote:

  

Both FOX V1.6.36 and V1.7.19 can lock-up X11 if the application 
temporarily starves the FOX event loop.
    

Are you using XInitThreads(), XIM or OpenGL?
  

The compile and link lines for V1.6.36 are:

> make
g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"fox\" -DVERSION=\"1.6.36\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_X11_EXTENSIONS_SHAPE_H=1 -DHAVE_X11_EXTENSIONS_XSHM_H=1 -DHAVE_PNG_H=1 -DHAVE_TIFF_H=1 -DHAVE_ZLIB_H=1 -DHAVE_BZLIB_H=1 -DHAVE_X11_XCURSOR_XCURSOR_H=1 -DHAVE_X11_EXTENSIONS_XRANDR_H=1 -DHAVE_VSSCANF=1 -DHAVE_VSNPRINTF=1 -DHAVE_STRTOLL=1 -DHAVE_STRTOULL=1 -DHAVE_LIBDL=1 -I. -I.  -I../include -I../include    -g -O2 -DHAVE_XSHAPE_H=1 -DHAVE_XSHM_H=1 -DFOX_THREAD_SAFE=1 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_GNU_SOURCE -DHAVE_
JPEG_H=1 -DHAVE_PNG_H=1 -DHAVE_TIFF_H=1 -DHAVE_ZLIB_H=1 -DHAVE_BZ2LIB_H=1 -DHAVE_XCURSOR_H=1 -DHAVE_XRANDR_H=1 -DNO_XIM -Wall -W -Woverloaded-virtual -Wformat -g -DDEBUG -DHAVE_GLU_H=1 -DHAVE_GL_H=1  -c imageviewer.cpp
/bin/sh ../libtool --mode=link g++  -g -O2 -DHAVE_XSHAPE_H=1 -DHAVE_XSHM_H=1 -DFOX_THREAD_SAFE=1 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_GNU_SOURCE -DHAVE_JPEG_H=1 -DHAVE_PNG_H=1 -DHAVE_TIFF_H=1 -DHAVE_ZLIB_H=1 -DHAVE_BZ2LIB_H=1 -DHAVE_XCURSOR_H=1 -DHAVE_XRANDR_H=1 -DNO_XIM -Wall -W -Woverloaded-virtual -Wformat -g -DDEBUG -DHAVE_GLU_H=1 -DHAVE_GL_H=1   -o imageviewer  imageviewer.o ../src/libFOX-1.6.la -lm -ldl  -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 -lm -lGLU -lGL
g++ -g -O2 -DHAVE_XSHAPE_H=1 -DHAVE_XSHM_H=1 -DFOX_THREAD_SAFE=1 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_GNU_SOURCE -DHAVE_JPEG_H=1 -DHAVE_PNG_H=1 -DHAVE_TIFF_H=1 -DHAVE_ZLIB_H=1 -DHAVE_BZ2LIB_H=1 -DHAVE_XCURSOR_H=1 -DHAVE_XRANDR_H=1 -DNO_XIM -Wall -W -Woverloaded-virtual -Wformat -g -DDEBUG -DHAVE_GLU_H=1 -DHAVE_GL_H=1 -o .libs/imageviewer imageviewer.o  ../src/.libs/libFOX-1.6.so -ldl -lpthread -lrt -ljpeg -lpng -ltiff -lz -lbz2 -lm -lGLU /usr/lib64/libGL.so  -Wl,--rpath -Wl,/goal/work2/local/lib -Wl,--rpath -Wl,/usr/lib64
creating imageviewer

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hal Brand]

Michal Suchanek wrote:

This is not FOX specific. GTK also uses menus that grab the X server
and if the application is busy and fails to remove the grab X server
is grabbed for a while before the application gets around to removing
the menu.
  

I beg to differ about the specifics of this case. I fully understand a grabbed server with no attention given to the event loop; all window systems are vulnerable. However, in my example, the "chore" quickly reduces the CPU load to 0 and the grab remains and mouse events are (seemingly) ignored. (I have evidence they are not ignored, just mishandled.) IMHO, it is a code path problem. My best guess is that it is caused by XLib's handling of the incoming events when they stack up; maybe XLib is combining events in some way that:

1. does not occur when the FOX polling loop is removing events at normal speed (because they don't stack up), and
   
2. confuses FOX into not properly setting up internal state such that when the server is grabbed the events are not properly dispatched.

I know exactly how to 100% reliably get FOX to exhibit #2. I've posted about it before. See my response to Jeroen for more.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hal Brand]

Jeroen van der Zijp wrote:

...

Well,

I would need to investigate Hal Brand's particular case.

It appears to me that people are conflating several types of lock-ups: 

	1) mouse grabs which aren't released when they're supposed to.

	2) getting stuck in select().


The former (1) is due to a failure of calling ungrab() along some path through the code;
note that this needs to be investigated on a case-by-case basis since there are MANY widgets
and thus many paths through the code whereby a call to ungrab() may be missed.

Number (2) is more fundamental O.S. related.  It'll need to be looked at carefully since
its possible there's some sort of race in the code leading up to select().
  

I have reason to believe that #1 is the problem based on another very similar FOX server grab lockup that is 100% reproducable. This lockup is based on ambushing FOX's keyboard accelerator code. (Yes, I know, it is an ambush. But its also mistake a programmer might make, it demonstrates a lack of robustness in the keyboard accelerator code, and it may provide clues to just what is going on in the "chore" case.)

Start with imageviewer.cpp and add a new message handler for SEL_KEYPRESS,0 and in that message handler, simply return. (Use the context diffs below for V1.6.36; I'm pretty sure patch will apply them to V1.7.19 also.) Start imageviewer and press ALT-f; you will see the File menu pop up, the cursor switch, but be unable to select any options in the File menu - worse, the server is grabbed, so you can't do anything with the mouse. Now, to show that FOX is still receiving mouse events, place the cursor below the Edit menu (near the "e" in the File menu's "Save..." will do) and press ALT-e. You will note that the Edit pop up appears (while the File pop up is also up) AND that the item under the cursor is highlighted.  Mouse clicks are still ignored, BUT mouse movement is not - move the mouse vertically between the Edit menu selections and watch the highlight follow the cursor - clearly FOX is getting at least mouse movement events. Now, move the cursor out of the Edit pop up and then back in. Notice that now, FOX is no longer highlighting the Edit menu selections. You can recover from this issue by pressing ALT-f and ALT-e again (either order).

>From this I conclude that FOX is getting the events, but not processing them correctly such that the code path to ungrab never happens.

Running the "chore" hang version with -tracelevel 500 confirms that FOX is getting mouse events:

On each left button press:

FXMenuBar::onButtonPress 0x10fd0640
FXMenuBar::onCmdUnpost 0x10fd0640
FXToolTip::hide 0x10fdd680
FXMenuBar::onButtonRelease 0x10fd0640
FXToolTip::hide 0x10fdd680

Remember that in this case, the hang occurs without a menu popup on the screen.

Thanks for your interest in this bug.

*** imageviewer.cpp.~1~ 2009-03-12 22:45:10.000000000 -0700
--- imageviewer.cpp 2009-06-04 15:33:15.000000000 -0700
***************
*** 74,79 ****
--- 74,80 ----
    long onCmdScale(FXObject*,FXSelector,void*);
    long onCmdCrop(FXObject*,FXSelector,void*);
    long onUpdImage(FXObject*,FXSelector,void*);
+   long onKey(FXObject*,FXSelector,void*);
  public:
    enum{
      ID_ABOUT=FXMainWindow::ID_LAST,
***************
*** 238,245 ****
--- 239,252 ----
    FXMAPFUNC(SEL_UPDATE,        ImageWindow::ID_MIRROR_BOTH,ImageWindow::onUpdImage),
    FXMAPFUNC(SEL_UPDATE,        ImageWindow::ID_SCALE,      ImageWindow::onUpdImage),
    FXMAPFUNC(SEL_UPDATE,        ImageWindow::ID_CROP,       ImageWindow::onUpdImage),
+   FXMAPFUNC(SEL_KEYPRESS, 0, ImageWindow::onKey)
    };
 
+ long ImageWindow::onKey(FXObject*,FXSelector,void*)
+ {
+   return 0;
+ }
+
 
  // Object implementation
  FXIMPLEMENT(ImageWindow,FXMainWindow,ImageWindowMap,ARRAYNUMBER(ImageWindowMap))

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Melton, Ryan]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Here is a super simple FXRuby application that recreates the X11 Lockup.  Run the program and then start clicking and mousing around the File Menu.  It will usually grab the mouse and not let go within a few seconds.   If you know where to look for this problem, please fix!  It definitely seems to be something to do with the FOX event loop falling far behind.

Thanks,

Ryan

 

require 'rubygems'

require 'fox16'

include Fox

 

def long_method (sender, sel, data)

  sum = 0

  1000000.times {|| sum += 1}

  FXApp.instance.addTimeout(10, method(:long_method))

end

 

application     = FXApp.new("NA", "NA")

window          = FXMainWindow.new(application, 'Title', nil, nil, DECOR_ALL, 0, 0, 500, 500)

frame           = FXVerticalFrame.new(window, LAYOUT_FILL_X|LAYOUT_FILL_Y)

menu_bar        = FXMenuBar.new(frame, LAYOUT_SIDE_TOP|LAYOUT_FILL_X)

file_menu       = FXMenuPane.new(frame)

file_menu_title = FXMenuTitle.new(menu_bar, "File", nil, file_menu)

menu_cmd        = FXMenuCommand.new(file_menu, "Process")

 

application.create

window.show

 

application.addTimeout(100, method(:long_method))

application.run

This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hal Brand]

Concerning the bug I reported about FOX hanging X11 by leaving the pointer grabbed when heavily loaded, I have found the following about the "FXChore" hang example:

1. In FXWindow::grab():
• XGrabPointer(...,getApp()->event.time) is returning 2 (GrabInvalidTime) so it then tries (as an error handling step?)
  
• XGrabPointer(...,CurrentTime) which returns 0.
2. In FXWindow::ungrab():
• Changing XUngrabPointer(DISPLAY(getApp()),getApp()->event.time) to XUngrabPointer(DISPLAY(getApp()),CurrentTime) prevents the problem. (I'm not suggest this the fix.)
  

The docs on XUngrabPointer() say it will NOT release the pointer if the specified time is earlier than the last-pointer-grab time or ...
I think what is happening is that with FOX way behind the XServer, the XGrabPointer(...,CurrentTime) sets the grab time to a larger time value than the time value of the event that FOX  (eventually) is processing when it does the XUngrabPointer(). Thus the time specified in the XUngrabPointer() is earlier than the grab time. Therefore the pointer is left grabbed.

What I have no explanation for at this time is just why XGrabPointer(...,getApp()->event.time) returns  GrabInvalidTime. The docs say "If the specified time is earlier than the last-pointer-grab time or later than the current X server time, it fails and returns GrabInvalidTime." Since this is the first grab, the first clause doesn't seem to apply, and since FOX seems to be using the time from the last XEvent containing a time, the time should not be ahead of the X server. Maybe somebody sees something I don't.

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Jeroen van der Zijp]

On Wednesday 10 June 2009, you wrote:

> Concerning the bug I reported about FOX hanging X11 by leaving the
> pointer grabbed when heavily loaded, I have found the following about
> the "FXChore" hang example:
>
>    1. In FXWindow::grab():
>           * XGrabPointer(...,getApp()->event.time) is returning 2
>             (GrabInvalidTime) so it then tries (as an error handling step?)
>           * XGrabPointer(...,CurrentTime) which returns 0.
>    2. In FXWindow::ungrab():
>           * Changing
>             XUngrabPointer(DISPLAY(getApp()),getApp()->event.time) to
>             XUngrabPointer(DISPLAY(getApp()),CurrentTime) prevents the
>             problem. (I'm not suggest this the fix.)
>
> The docs on XUngrabPointer() say it will NOT release the pointer if the
> specified time is earlier than the last-pointer-grab time or ...
> I think what is happening is that with FOX way behind the XServer, the
> XGrabPointer(...,CurrentTime) sets the grab time to a larger time value
> than the time value of the event that FOX  (eventually) is processing
> when it does the XUngrabPointer(). Thus the time specified in the
> XUngrabPointer() is earlier than the grab time. Therefore the pointer is
> left grabbed.

Hmm, so what it seems like is we need to remember which way we actually
succeeded with the XGrabPointer...

Perhaps we should just use CurrentTime in both cases?  Can you check if
that make the problem go away?

> What I have no explanation for at this time is just why
> XGrabPointer(...,getApp()->event.time) returns  GrabInvalidTime. The
> docs say "If the specified time is earlier than the last-pointer-grab
> time or later than the current X server time, it fails and returns
> GrabInvalidTime." Since this is the first grab, the first clause doesn't
> seem to apply, and since FOX seems to be using the time from the last
> XEvent containing a time, the time should not be ahead of the X server.
> Maybe somebody sees something I don't.

Yes, I don't understand why this happened either.  But one possibility
is that perhaps event.time is made invalid some place.

Please try the CurrentTime idea and see if that works....



                        - Jeroen




------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Niall Douglas]

On 9 Jun 2009 at 9:05, Hal Brand wrote:

> >> Both FOX V1.6.36 and V1.7.19 can lock-up X11 if the application
> >> temporarily starves the FOX event loop.
> >
> > Are you using XInitThreads(), XIM or OpenGL?

I only asked because there is a known interaction between XIM and X11
threading support i.e. the two don't coexist. I asked about OpenGL
because on Macs that won't work with X11 threading support either.

Anyway I see from later posts that the problem is likely a bug in
Xorg and mouse grabs. Chances are that FOX /used/ to work perfectly
fine and then a later Xorg release broke it. This has already
happened - XIM, OpenGL and X11 threads all used to play well together
once upon a time.

Cheers,
Niall




------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Hal Brand]

Jeroen van der Zijp wrote:

> ...
> Hmm, so what it seems like is we need to remember which way we actually
> succeeded with the XGrabPointer...
>
> Perhaps we should just use CurrentTime in both cases?  Can you check if
> that make the problem go away?
>
>  
>> What I have no explanation for at this time is just why
>> XGrabPointer(...,getApp()->event.time) returns  GrabInvalidTime. The
>> docs say "If the specified time is earlier than the last-pointer-grab
>> time or later than the current X server time, it fails and returns
>> GrabInvalidTime." Since this is the first grab, the first clause doesn't
>> seem to apply, and since FOX seems to be using the time from the last
>> XEvent containing a time, the time should not be ahead of the X server.
>> Maybe somebody sees something I don't.
>>    

Just for curiosity, I tried looping while XGrabPointer returned
GrabInvalidTime each time adding (another) 1000 to the time. Some tests,
after a few trys, it would return GrabSuccess; other times not (maybe
because it stepped into the future?). So right now, there is some
evidence that XGrabPointer doesn't like getting a time too far behind
the current time.
> Yes, I don't understand why this happened either.  But one possibility
> is that perhaps event.time is made invalid some place.
>
> Please try the CurrentTime idea and see if that works....
>  
I modified both FXWindow::grab() and FXWindow::ungrab() to specify
CurrentTime in all attempts to grab/ungrab the pointer. This fixed the
behavior of my test case. It didn't seem to have any adverse effects on
the FOX test cases I tried (by no means exhaustive), and best of all, it
fixed the behavior of our real-world application that starves the event
loop due to FXEvent processing (HLA RTI tick()). It appears this is a
viable fix.

--
Hal Brand



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Niall Douglas]

On 12 Jun 2009 at 4:47, Lothar Scholz wrote:

> > > > Are you using XInitThreads(), XIM or OpenGL?
> >
> > I only asked because there is a known interaction between XIM and X11
> > threading support i.e. the two don't coexist. I asked about OpenGL
> > because on Macs that won't work with X11 threading support either.
>
> Really? Do you have a link?

Only bitter experience in testing TnFOX. There's a warning message
printed during compilation on X11 to remind me to try uncommenting
the XIM support and testing to see if it now works with X11
threading. Last few years it hasn't and if you search particularly
the Qt mailing lists you'll see it's a well known problem.

Now that said 90% of the time it'll work just fine - the problem only
appears under load when lots of (say around sixteen) threads are
simultaneously hammering Xlib with graphics update calls. It'll work
for a while and then suddenly bam, it hangs.

Ctrl-C'ing in GDB and showing a stack backtrace clearly shows the
problem is in XIM. Removing XInitThreads() and implementing your own
mutex around X11 calls works properly, as does disabling XIM.

I caveat all this with that the last release of TnFOX was summer
2008. It is entirely possible that this bug has been fixed in the
past year - I wouldn't know (however the summer 2009 release is
coming soon). I *do* know that the bug was reported to Xorg and
someone important there said that input methods were going to be
overhauled shortly anyway with completely new code.

> I'm using XInitThreads (to draw animated progress bars) and XIM
> but have never tested the X11 version a lot.
>
> If it is true it really sucks and once again leaves a bad impression on
> Linux/Open Sources mantra:  release it often - release it with bugs.

Well in fairness to them the old XFree86 codebase (or X11) was never
intended to support Unicode and input methods were grafted on top of
code which didn't actually support that idea. The result was a nasty
hack which just happened to work most of the time (though if you
search google for XIM bugs you'll find many). Then XFree86 ossified
for a while and only with Xorg are we seeing progress after a long
period of stagnation.

Also, and not to be unfair to most of the world's population, until
very recently X11 was only being used mostly by Westerners with
fairly limited input method requirements. As with all open source,
it's demand driven - you need sufficient pain to get someone
motivated enough to go fix it and the recent splurge of cheap Linux
powered consumer MIDs has been that motivation. I might add that GNU
gettext() style translation is fundamentally incapable of working
correctly for many of the world's languages and yet we still see
little progress in fixing that either.

Regarding OpenGL support on the Mac, again this is a known bug and
Apple say they are fixing it. It was still present on early 10.5
releases - I haven't tested it since last year.

BTW when I reported that XIM + XInitThreads() interaction here
Jeroen's response was to remove the XInitThreads() call. Has that now
changed?

Cheers,
Niall




------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users

[Melton, Ryan]

Hi Jeroen,

Could we get a FOX 1.6 release that includes the mouse grab fix?

Thanks,
Ryan

-----Original Message-----
From: Hal Brand [mailto:brand1@...]
Sent: Thursday, June 11, 2009 8:54 PM
To: Jeroen van der Zijp
Cc: s_sourceforge@...; foxgui-users@...
Subject: Re: [Foxgui-users] Bug Report: Locking X11 with FOX

Jeroen van der Zijp wrote:

> ...
> Hmm, so what it seems like is we need to remember which way we actually
> succeeded with the XGrabPointer...
>
> Perhaps we should just use CurrentTime in both cases?  Can you check if
> that make the problem go away?
>
>  
>> What I have no explanation for at this time is just why
>> XGrabPointer(...,getApp()->event.time) returns  GrabInvalidTime. The
>> docs say "If the specified time is earlier than the last-pointer-grab
>> time or later than the current X server time, it fails and returns
>> GrabInvalidTime." Since this is the first grab, the first clause doesn't
>> seem to apply, and since FOX seems to be using the time from the last
>> XEvent containing a time, the time should not be ahead of the X server.
>> Maybe somebody sees something I don't.
>>    

Just for curiosity, I tried looping while XGrabPointer returned
GrabInvalidTime each time adding (another) 1000 to the time. Some tests,
after a few trys, it would return GrabSuccess; other times not (maybe
because it stepped into the future?). So right now, there is some
evidence that XGrabPointer doesn't like getting a time too far behind
the current time.
> Yes, I don't understand why this happened either.  But one possibility
> is that perhaps event.time is made invalid some place.
>
> Please try the CurrentTime idea and see if that works....
>  
I modified both FXWindow::grab() and FXWindow::ungrab() to specify
CurrentTime in all attempts to grab/ungrab the pointer. This fixed the
behavior of my test case. It didn't seem to have any adverse effects on
the FOX test cases I tried (by no means exhaustive), and best of all, it
fixed the behavior of our real-world application that starves the event
loop due to FXEvent processing (HLA RTI tick()). It appears this is a
viable fix.

--
Hal Brand



------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.

------------------------------------------------------------------------------
_______________________________________________
Foxgui-users mailing list
Foxgui-users@...
https://lists.sourceforge.net/lists/listinfo/foxgui-users