| [ 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: | |
Trouble Report Files:
[ Post File ]
|
#1 | bgbnbigben 20:25 Apr 24, 2011 |
| t.cxx 0k | |
Trouble Report Comments:
[ Post 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 ]
|
| |