FLTK logo

STR #2611

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File | SVN ⇄ GIT ]

STR #2611

Application:FLTK Library
Status:3 - Active
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Multiple InputBrowsers will cause hang
Version:2.0-current
Created By:spoony
Assigned To:bgbnbigben
Fix Version:2.0-current (SVN: v8627)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size  
 
#1 bgbnbigben
20:25 Apr 24, 2011
t.cxx
0k
 
     

Trouble Report Comments:

Post Text ]
Name/Time/Date Text  
 
#1 spoony
19:54 Apr 24, 2011
The following two lines in InputBrowser::popup()(line 386,387 in InputBrowser.cxx)
  browser = list;
  ib = this;
should be moved out of if(!win).

The following will be changed:
if(!win) {
      win = new ComboWindow(0,0,0,0); // this will be moved later
      win->set_override();

      win->begin();
      list = new ComboBrowser(0,0,0,0);
      list->box(UP_BOX);
      list->callback(ComboBrowser::browser_cb, this);
      list->when(WHEN_CHANGED | WHEN_RELEASE_ALWAYS | WHEN_ENTER_KEY_ALWAYS);
      list->end();

      win->end();
      win->box(UP_BOX);

      browser = list;
      ib = this;
    }
to be:
  if(!win) {
      win = new ComboWindow(0,0,0,0); // this will be moved later
      win->set_override();

      win->begin();
      list = new ComboBrowser(0,0,0,0);
      list->box(UP_BOX);
      list->callback(ComboBrowser::browser_cb, this);
      list->when(WHEN_CHANGED | WHEN_RELEASE_ALWAYS | WHEN_ENTER_KEY_ALWAYS);
      list->end();

      win->end();
      win->box(UP_BOX);

      
    }
    browser = list;
    ib = this;

Thanks
Jim
 
 
#2 bgbnbigben
20:25 Apr 24, 2011
So it might just be me, but I can't cause a hang with two input browsers. Could you post a minimal example that exemplifies the problem? I've attached my own, and aside from the obviously poorly designed UI I don't see any issues with it - it runs like I would expect.  
 
#3 spoony
20:37 Apr 24, 2011
To reproduce the bug:
please click the first Inputbrowser and choose one item in popup menu and then the click second Inputbrowser and choose an item, and click the first one and choose again, then the mouse events will be kept trapped in the popped out menu by first Inputbrowser.
 
 
#4 spoony
20:46 Apr 24, 2011
I tried your test, and it trapped whole X system events. I must use another pc to login and kill the process.
Thanks
Jim
 
 
#5 bgbnbigben
22:33 Apr 24, 2011
Ah, okay. I've seen this before - a similar things happens in FLUID when creating a TabGroup, or something similar (it's in the STR system). I'll take a look, but the reason X is hanging is because FLTK is causing/eating an infinite loop of events, or something like that. rainbowsally had a simple method to avoid this bug (though it wasn't a fix). A simple usleep(1) forced FLTK to sleep intermittently and thus would procrastinate the problem effectively.

Whilst your fix most likely does the job - and thanks for putting in the work to find and fix this - what I'll do for the time being is investigate this further. The fact that it appears in two different places suggests - to me - that we're doing something stupid, and thus whilst your fix is adequate there must be a slightly smarter one somewhere.
 
 
#6 spoony
00:40 Apr 25, 2011
Hi, Ben,
  Other issues may be different, the issue around Inputbrowser is very clear, it is because the two variables involved are globals, and they did not switch back when the the first Inputbrowser is clicked again. Then the hidden_popup() is invoked, which did nothing since the second Inputbrowser
is invisible.
Thanks
Jim
 
 
#7 spoony
00:46 Apr 25, 2011
BTW, this issue is not related to FLTK event loop. I am using fltk2 in google native client where I dropped the whole FLTK event loop mechanism.
And I found the issue first there.
 
 
#8 bgbnbigben
17:51 Apr 25, 2011
Actually, your fix and the bug you're talking about doesn't explain the behaviour we're seeing. A modal window (or widget) eats all the incoming events, but *can also receive them*. What's happening here is that the window/widget is locking itself in an infinite loop, and thus is unable to receive anything (which is why it exhibits the behaviour you're describing). I probably misspoke - when I said "FLTK event loop" I didn't mean the capturing of X events, etc. It made sense in my head. :-P
Now, of course, once the above behaviour is fixed the *next* item on the agenda would be your fix, as you're right - the InputBrowser would clearly not gain focus and modality.
I really need to find some time to do a bit of heavy developing, but I'll be snowed under for the next couple of weeks. In the meantime, I'll commit your fix, because I suppose it does solve the issue, but doesn't triage the underlying problem. I think this problem was specific to X11, which means that there's (most likely) a simple fix somewhere in src/x11/run.cxx, but I'll have to follow this up.

Thanks for the bug report and the fix. I hate triaging bugs that lock up X servers, personally!.
 
 
#9 spoony
18:34 Apr 25, 2011
Hi, Ben,
  It is not worth wasting more time on this issue. When you have more than 2 items in each Inputbrowser, you will see what I mean.
The only thing here is that hide_popup() does not close the wait() loop inside exec() for a modal window.
You are also right, I also observed some abnormal message consuming sometimes (that is why I want to do some cleanup there if having free time), but that issue will not be exposed by current test case.
 
 
#10 spoony
18:46 Apr 25, 2011
Sorry, did not read your post carefully.
You are totally right, and the modal window eats all messages are the second Inputbrowser's popup menu, whose wait() loop should be broken by hide_popup() but not, due to that it is already invisible.
Thanks
 
 
#11 bgbnbigben
05:31 Apr 27, 2011
Solved in Subversion repository (I won't use fixed because like I've said, the underlying bug isn't fixed - though we're not going to see it anymore!)

I've dropped the priority of this down to "Low" to enable me to come back to it later on.
For my own reference, even with a modal window this doesn't explain the lack of mouse events, so there's something going on here that needs explaination.

Thanks for the STR+fix, spoony!
 
     

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.