String corruption when clearing MenuButton when popped-up

[Mo_Al_]

Hello

Is there a way to detect whether Fl_Menu_Button is popped-up prior to calling clear on it?

Given the following code:

#include <FL/Fl.H>

#include <FL/Fl_Double_Window.H>

#include <FL/Fl_Menu_Button.H>

Fl_Menu_Button *m;

void timeout_cb(void *) {

    m->clear();

    m->add("Jan|Feb|Mar");

    Fl::repeat_timeout(1.0, timeout_cb, 0);

}

int main() {

  auto w = new Fl_Double_Window(300, 300);

  m = new Fl_Menu_Button(0, 0, 300, 300);

  m->type(Fl_Menu_Button::POPUP3);

  m->add("Jan|Feb|Mar");

  w->end();

  w->show();

  Fl::add_timeout(1.0, timeout_cb, 0);

  return Fl::run();

}

This will corrupt the strings sent to the font engine (pango for example) and might lead to a segfault. The corruption happens when calling clear on a popped-up menu button, otherwise calling clear doesn't cause issues. The minimal repro uses a timeout, however I've run to this situation in a widgets handle method.

[Manolo]

While the menu is pulled down, Fl::grab() returns the menu window and it returns NULL when the menu window is closed.

Thus, you can modify your timeout_cb function as follows

void timeout_cb(void *) {
  puts("running timeout");
  if (!Fl::grab()) {

    m->clear();
    m->add("Jan|Feb|Mar");
  }
    Fl::repeat_timeout(1.0, timeout_cb, 0);
}

If there are other grabbing windows around in your app, you would also have to make sure Fl::grab() returns another window.

[Mo_Al_]

Thank you Manolo.
I've check and it indeed works.

[Greg Ercolano]

[This was posted on fltk.general, carrying it over here for possible coredev discussion]

On 11/5/22 01:11, Mo_Al_ wrote:

Hello

Is there a way to detect whether Fl_Menu_Button is popped-up prior to calling clear on it?

    I can see where applications showing realtime status of asynchronous events could run into this easily.

  * Should FLTK provide is_posted() or is_popup() or some such method to Fl_Menu_ and friends?

  * Add warnings in docs for all the Fl_Menu_ 'clear()' methods/suggest how to avoid?

  * Perhaps clear() methods should automatically schedule/defer the work until the menu finishes posting?

[Greg Ercolano]

Meh, meant to send my reply to fltk.coredev instead of fltk.general, but hitting Cancel on the send still snuck it through, lol.

I did post it to fltk.coredev, where I'd prefer to see replies go, as usually this sort of thing gets technical fast.