NOTE: while I was almost ready to post this message a new reply from Gonzalo appeared. I'm going to look into the other reply soon. My questions are similar to what Manolo asked. I'm posting my reply anyway as-is ...

On 4/28/24 10:50 Gonzalo Garramuño wrote:

On 4/28/2024 5:36 AM, Gonzalo Garramuño wrote:

Actually, the fix should be these two lines:

            Fl_Widget* p = parent(); for (p && ;p->visible();p = p->parent()) {}
            if (!p || p->type() >= FL_WINDOW) break; // don't do the unmap

Make that instead:

            Fl_Widget* p = parent(); for (p && ;p->visible();p = p->parent()) {}
            if (p && p->type() >= FL_WINDOW) break; // don't do the unmap

Gonzalo, I agree that the existing code is broken, and it was IMHO broken since it was introduced in the year 2000 as Manolo mentioned.

However, a typo seems to be in your suggested code in in `for (p && ;p->visible();` . I propose the following:

if (visible()) {

Fl_Widget* p = parent();

for (; p && p->visible(); p = p->parent()) {}

if (p && p->as_window()) break; // don't do the unmap

}

pWindowDriver->unmap();

I have these questions:

(1) After seeing your last proposal I considered changing it to the first proposal above, wondering which one was correct. Why did you change the first proposal to the later one? I came to the same conclusion, but can you elaborate why you changed it?

(2) Did you have a chance to test this code with the patch or let your user test it? Did it change the behavior?

(3) I agree with Manolo that we should investigate and understand why such old code triggers a bug (crash) in your code. Understanding what happens is important to know *what* exactly needs to be fixed. Maybe there's another bug elsewhere (in FLTK or inyour application) that causes this unexpected behavior. As Manolo wrote, it is possible that some code accesses a deleted widget or window which causes undefined behavior. Do you have any insights what may trigger the bug in your program?

The more info you can provide, the better we can fix the bug.

According to the stack trace posted elsewhere I assume that your program hides either a window or another widget, maybe one that contains a subwindow, inside a timer callback. Does this sound plausible (possible)?

Maybe the crash is triggered because the timer callback is called while the user has a menu open in your program. If we could confirm this it might give us more clues. Can you please ask the user if the crash happens while a menu is open?

It would be great if you could provide us with some more information about the program's state when the crash is triggered. Thanks in advance.

-- 
Gonzalo Garramuño
ggarra13@gmail.com