bugGNUstep - Bugs: bug #26046, Infinite loop on quit...

Group
 
 

bug #26046: Infinite loop on quit...

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Mon 30 Mar 2009 04:12:40 AM UTC
   
 
Category:  Gui/AppKit Severity:  2 - Minor
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 26 Dec 2009 07:22:30 AM UTC, comment #11: 

This is no longer an issue.

Gregory John Casamento <gcasa>
Group administrator
Wed 01 Apr 2009 09:02:29 PM UTC, comment #10: 

Hey Xavier...

I will try as soon as possible.  I've been a bit bogged down lately. 

I will report back once I've given it a shot.

Thanks, GC

Gregory John Casamento <gcasa>
Group administrator
Wed 01 Apr 2009 08:38:00 AM UTC, comment #9: 


> And please try to stick with our coding convention. The current
> commented out code wont compile with gcc 2.95.


What is the problem ?

> And why is this code different from the one Greg showed below?


Because it has been changed by Greg who did comment it out.

Greg, did you try the changes I propose (continue --> break) ?

- <_57132>
Tue 31 Mar 2009 08:39:01 PM UTC, comment #8: 

After Greg's commit I am now also able to run the gromtest application, but still no sign of an infinit loop.

I suggest that we close this bug report as invalid.


Xavier, could you please make the code changes you came up with to try to make that code as fail save as possible. And please try to stick with our coding convention. The current commented out code wont compile with gcc 2.95.
(And why is this code different from the one Greg showed below?)

Fred Kiefer <FredKiefer>
Group Member
Mon 30 Mar 2009 05:48:27 PM UTC, comment #7: 

Sure it may happen but it actually does not with gormtest on my computer. I don't even get a VisibilityNotify event when the app is closing: my code is not executed. So i can not know if turning the 'continue's into 'break's prevents the endless loop. Could someone check ?

Moreover the late events are NSEvent dequeued by the runloop (in gui), not XEvent got from the X server (in back). We get a X11 error : could a XWindow ID from a XEvent be invalid ? This means the XWindow has been destroyed before the event in processed. Confusing.

VisibilityNotify event is send when a part of the window is unhidden. How could this happen when you close the app ? Still confusing.

Silly idea: maybe a software mouse pointer ? Does the pointer moves can cause VisibilityNotify events ?

- <_57132>
Mon 30 Mar 2009 04:50:21 PM UTC, comment #6: 

Xavier Wrote:

>
>Nothing to do with my changes. This code is not executed at all: >the loop is only entered when the window of the event is not a >NSWindow, and AFAIK this only happend with a NSOpenGLView. In >short cWin is never null.


i'm guessing that this could happen if an event is received by back after the NSWindow has been deallocated in that case cWin could be null

see the large comment at the beginning of NSWindow -sendEvent: describing previous issues with late arriving events.

matt rice <ratmice>
Group Member
Mon 30 Mar 2009 04:25:05 PM UTC, comment #5: 

I now can run gormtest, but I still can not reproduce the error, with or without the 'break' correction.

But I can make the application hang if I close it (with the menu) as soon as it displays. If I wait 1 or 2 sec before I ask for quitting (I get some more 'released' messages), the application stops silently.
There is a short halt before the last 17 'released' log messages: the application is still loading (some widgets are not fully displayed). If I click on 'Quit' after these lines are printed the application quits normally.

But this might come from my old and lazy computer.

Anyway, with '--GNU-Debug=NSEvent' the last log messages is:
PropertyNotify - 'WM_CLASS'

Nothing to do with my changes. This code is not executed at all: the loop is only entered when the window of the event is not a NSWindow, and AFAIK this only happend with a NSOpenGLView. In short cWin is never null.

I don't understand and can not be of any help until I can reproduce the problem. Any suggestion ?

- <_57132>
Mon 30 Mar 2009 11:12:16 AM UTC, comment #4: 

I can not reproduce the problem. Same warnings than Fred. If you start the application from a console you can quit with ctrl-c and it stops silently.

FYI:
The code Greg found out is intended to find the top-most parent of a sub-window that gnustep does not recognize. It is needed to send the event from an OpenGL x11 subwindow to its parent NSWindow. Maybe the subwindow (and/or a parent) has already been destroyed when the visibility event is processed here. Should this happend ?

Anyway I found THE ugly dummy mistake : we may replace "continue" with "break" ! (in this loop and the similar one some lines below)
That will not prevent the error, but should prevent the endless loop.

I would test when I succeed reproducing the problem.

- <_57132>
Mon 30 Mar 2009 10:04:27 AM UTC, comment #3: 

I tried to reproduce this problem, but failed long before getting there. When I compile gormtest I get the following warnings:

Warning: English.lproj/urltest.gorm not found - ignoring
Warning: English.lproj/testmatrix.nib not found - ignoring


The application starts fine though, but fails to display a menu. All I get is an application icon and a window with scrollable area. Moving the mouse gives plenty of messages
(2009-03-30 11:09:19.434 gormtest[5807] Released: <NSWindow: 0x833a978>)

I have no idea how to quit that application as there isn't even a context window.

Any other application I could try to reprocuce this with?

Fred Kiefer <FredKiefer>
Group Member
Mon 30 Mar 2009 05:38:20 AM UTC, comment #2: 

I'm going to comment this code out and notify Xavier Glattard about the problem so that it can be corrected.

Gregory John Casamento <gcasa>
Group administrator
Mon 30 Mar 2009 04:29:06 AM UTC, comment #1: 

 
I've narrowed it down to this code in XGServerEvent.m @ line 942

 28036        xgl         // sub-window ?
 28036        xgl           {
 28036        xgl             Window xw;
 28036        xgl             xw = xEvent.xvisibility.window;
 28036        xgl             while (cWin == 0)
 28036        xgl               {
 28036        xgl                 Window rw, *cw; unsigned int nc;
 28036        xgl                 if ( !XQueryTree(dpy, xw, &rw, &xw, &cw, &nc) )
 28036        xgl                   continue;
 28036        xgl                 if ( cw != NULL )
 28036        xgl                   XFree(cw);
 28036        xgl                 generic.cachedWindow
 28036        xgl                   = [XGServer _windowForXWindow:xw];
 28036        xgl               }
 28036        xgl           }
 28036        xgl

Can anyone suggest a fix for this?   The XQueryTree code is what seems to be causing the issue.

Gregory John Casamento <gcasa>
Group administrator
Mon 30 Mar 2009 04:12:40 AM UTC, original submission:  

1) Go to the tests directory and build gormtest.app.
2) run it...
3) Quit

RESULT: You will get this....
                    type: 0
       serial number: 2687
        request code: 15
2009-03-30 00:03:52.283 gormtest[18991] X-Windows error - BadWindow (invalid Window parameter)
          on display: :0.0
                    type: 0
       serial number: 2688
        request code: 15
2009-03-30 00:03:52.283 gormtest[18991] X-Windows error - BadWindow (invalid Window parameter)
          on display: :0.0
                    type: 0
       serial number: 2689
        request code: 15
2009-03-30 00:03:52.284 gormtest[18991] X-Windows error - BadWindow (invalid Window parameter)
          on display: :0.0
                    type: 0
       serial number: 2690
        request code: 15
2009-03-30 00:03:52.284 gormtest[18991] X-Windows error - BadWindow (invalid Window parameter)
          on display: :0.0
                    type: 0
       serial number: 2691
        request code: 15
2009-03-30 00:03:52.284 gormtest[18991] X-Windows error - BadWindow (invalid Window parameter)
          on display: :0.0
                    type: 0
       serial number: 2692
        request code: 15

EXPECTED: App should quit.

This happens with other apps as well.  I'm not sure why it's happening, but I am looking into it.  If anyone else has any ideas, let me know.

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ratmice (Posted a comment)
  • -email is unavailable- added by _57132 (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-12-26 gcasa StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2009-03-31 FredKiefer Severity5 - Blocker 2 - Minor
    2009-03-30 gcasa StatusNone In Progress
        Assigned toNone gcasa

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code