STR #1873

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 1.3 ]

STR #1873

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:4 - High, e.g. key functionality not working
Scope:2 - Specific to an operating system
Subsystem:Core Library
Summary:more fl_ask issues
Version:1.3-current
Created By:wavexx
Assigned To:fabien
Fix Version:1.3-current
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 wavexx
13:31 Feb 14, 2008
askcrash.cc
0k
 
 
#2 wavexx
11:05 Feb 18, 2008
recursivehide.patch
1k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#1 wavexx
13:31 Feb 14, 2008
There are some weird issues going on when fl_ask (&family) is being used. It is possible to make an application crash when fl_ask is used in callbacks.

I was able to track a crash down to a simple test case while debugging another str. It crashes on OSX, but may apply to others.
 
 
#2 wavexx
11:04 Feb 18, 2008
This is a nasty one.

1: window is shown, focus goes to Fl_Input
2: press ESC, default_atclose calls hide()
3: hide() fixes focus, calling FL_LEAVE
4: FL_LEAVE causes Fl_Input to generate its callback
5: now enter the fl_ask's innards, re-entering Fl::wait
6: move the mouse over the main window
7: motion event is delivered to the window, which has "i" set to 0 to avoid drawing
8: watch it die!

In general, it's true that FL_HIDE should _not_ draw to the window, however I think we must not remove the xid handler until all events have been dispatched. It is possible that, during recursive behavior, other events gets generated. I don't think checking shown() for every callback ever made is a good idea.

This basically requires to move "i = 0" from Fl.cxx:935 to somewhere after Fl.cxx:956:handle(FL_HIDE);. This would also remove the need of the invasive cursor handling stuff in this function, that could be moved in the respective widget's FL_HIDE code.

SVN reveals this code is pretty old, so I'm unsure about the requirement of having "i = 0;" set as soon. Any comment?

I'm attaching a patch that fixes the recursive events sent to dying windows on carbon. It seems that the default carbon handler already checked for this, but not the mouse/activation/wheel handler.

The patch fixes THIS issue, but I strongly suggest to revisit this behavior.
 
 
#3 matt
10:19 Feb 20, 2008
This bug was pushed up from 1.1 . Even though the patch was applied and fixes the immediate problem, a better, more general solution must be found. IMHO, xid=0 should not be done until required. However, an existing xid (and theassociated window) also means that more event can be received.

Anyway, this needs some review.
 
 
#4 fabien
10:31 Oct 04, 2008
Is it still crashing in latest svn ?
I tried to reproduce the bug but didn't succeed under osx quartz.
 
 
#5 fabien
01:57 Nov 07, 2008
I reviewed that one twice and didn't find any crash situation, following the mentioned test case, again.  
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

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