Thank you for digging into this issue.
menu_cache_lookup() is an async call.
Once loading of the menu is finished, it calls reload callbacks.
This looks weird and is not intuitive, though.
Bad API design. :-(

menu_cache_lookup_sync() is a blocking call.
It runs a glib mainloop internally and blocks.
When the menu is loaded, it quitted the mainloop and the function returns.

On Fri, Mar 30, 2012 at 1:42 PM, Vadim Ushakov <igeekless@gmail.com> wrote:
I've received the following bug report: command "lxpanelctl run"
crashes lxpanel when there is no menu applet on the panel. The report
was against lxpanelx, but the bug is reproduced with original lxpanel

When a panel has menu applet, the applet initializes menu-cache in
right way and it works fine. When there is no menu applet, gtk_run()
gets an "empty" cache object from menu_cache_lookup(), then calls
menu_cache_list_all_apps(), and the program crashes at dereferencing
null pointer at list_app_in_dir().

I tried to use menu_cache_lookup_sync() instead of
menu_cache_lookup(), but the program simply hangs forever at this
call. So I just added line 'menu_cache_reload(menu_cache);' to work
around the problem, but it does not look like a right solution.

First, what about menu_cache_lookup_sync()? Is it buggy or did I use
it in wrong way?

And second, maybe we need some 'if cache->root_dir is null, reload the
cache now' logic inside menu_cache_list_all_apps()?

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Lxde-list mailing list