Bug 758813 – Gio::ActionMap::lookup_action() causes crash

After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.

Bug 758813 - Gio::ActionMap::lookup_action() causes crash


Summary:	Gio::ActionMap::lookup_action() causes crash


Status:	RESOLVED FIXED

Product:	glibmm
Classification:	Bindings
Component:	giomm
Version:	2.46.x
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	gtkmm-forge
QA Contact:	gtkmm-forge

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2015-11-29 20:56 UTC by Aurimas Černius
Modified:	2015-12-03 15:48 UTC

See Also:
GNOME target:	---
GNOME version:	---

Attachments
Test case (897 bytes, text/plain) 2015-11-30 20:05 UTC, Aurimas Černius	Details
Test case 2 (991 bytes, text/plain) 2015-12-03 15:37 UTC, Kjell Ahlstedt	Details

Description Aurimas Černius 2015-11-29 20:56:58 UTC

If I call lookup_action() in an Gtk::ApplicationWindow, it crashes. I pass in a valid action name, that was previously added to map.
If I call g_action_map_lookup_action() directly, it works and returns a not-NULL GAction.

Comment 1 Murray Cumming 2015-11-29 21:01:36 UTC

I don't see anything obviously wrong in the generated code, though there is a lookup_action_vfunc() which might have strange side-effects.

Do you have a backtrace? A simple test case would be nice too.

Comment 2 Aurimas Černius 2015-11-30 20:04:23 UTC

Spent more time investigating, so the findings are:
- failure happens when searching for actually added action
- it doesn't crash on a very simple application, but causes failures and prevents window from opening in the attached sample
- I get crash in Gnote I'm working on. Don't know why exactly that happens, but it looks to be when making C++ wrapper for C object. I'll post a stack trace.

Comment 3 Aurimas Černius 2015-11-30 20:05:50 UTC

Created attachment 316555 [details]
Test case

Command line output:

[aurimas@localhost gtkmmt]$ ./gtkmmt 

(gtkmmt:11098): glibmm-WARNING **: This object, of type gtkmm__GtkApplicationWindow, already has a wrapper.
You should use wrap() instead of a constructor.

(gtkmmt:11098): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed

(gtkmmt:11098): GLib-GObject-CRITICAL **: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed

Comment 4 Aurimas Černius 2015-11-30 20:06:53 UTC

Stacktrace from crash I get in Gnote:

(gdb) bt

+ Trace 235776

#0 g_type_get_qdata
#1 Glib::wrap_create_new_wrapper_for_interface(_GObject*, unsigned long)
#2 Gio::Action* Glib::wrap_auto_interface<Gio::Action>(_GObject*, bool)
#3 Glib::wrap(_GAction*, bool)
#4 Gio::ActionMap::lookup_action(Glib::ustring const&)
#5 gnote::NoteRecentChanges::NoteRecentChanges(gnote::NoteManager&)
at recentchanges.cpp line 109
#6 gnote::Gnote::new_main_window()
at gnote.cpp line 340
#7 gnote::Gnote::get_main_window()
at gnote.cpp line 361
#8 gnote::Gnote::end_main(bool, bool)
at gnote.cpp line 201
#9 gnote::RemoteControlProxy::register_object(Glib::RefPtr<Gio::DBus::Connection> const&, gnote::NoteManager&, sigc::slot<void, bool, bool, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> const&)
at /usr/include/sigc++-2.0/sigc++/functors/slot.h line 621
#10 gnote::RemoteControlProxy::register_object(Glib::RefPtr<Gio::DBus::Connection> const&, gnote::NoteManager&, sigc::slot<void, bool, bool, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil> const&)
at remotecontrolproxy.cpp line 141
#11 gnote::Gnote::register_object()
at gnote.cpp line 233
#12 gnote::Gnote::on_command_line(Glib::RefPtr<Gio::ApplicationCommandLine> const&)
at gnote.cpp line 121
#13 Gio::Application_Class::command_line_callback(_GApplication*, _GApplicationCommandLine*)
#14 ffi_call_unix64
#15 ffi_call
#16 g_cclosure_marshal_generic_va
#17 _g_closure_invoke_va
#18 g_signal_emit_valist
#19 g_signal_emit
#20 g_application_call_command_line
#21 g_application_real_local_command_line
#22 Gio::Application::local_command_line_vfunc(char**&, int&)
#23 Gio::Application_Class::local_command_line_vfunc_callback(_GApplication*, char***, int*)
#24 g_application_run
#25 gnote::Gnote::main(int, char**)
at gnote.cpp line 96
#26 main(int, char**)
at main.cpp line 35

Comment 5 Kjell Ahlstedt 2015-12-01 20:14:57 UTC

The test case, together with gdb, shows that the error is in

  auto win = new Gtk::ApplicationWindow(App::s_app);

Something is wrong with the ApplicationWindow constructor that takes a
const Glib::RefPtr<Gtk::Application>&.

A simple workaround is to replace that line with

  auto win = new Gtk::ApplicationWindow();
  App::s_app->add_window(*win);

Comment 6 Aurimas Černius 2015-12-01 21:19:03 UTC

(In reply to Kjell Ahlstedt from comment #5)
> The test case, together with gdb, shows that the error is in
> 
>   auto win = new Gtk::ApplicationWindow(App::s_app);
> 
> Something is wrong with the ApplicationWindow constructor that takes a
> const Glib::RefPtr<Gtk::Application>&.

Yes, that too. But it's not what this bug is about. Unless that makes lookup_action() work?
I remember that warning from constructor since it appeared, btw.

Comment 7 Kjell Ahlstedt 2015-12-02 19:43:57 UTC

You're right. Your test case triggers two independent bugs, one in the
Gtk::ApplicationWindow constructor and one in Gio::ActionMap::
lookup_action_vfunc(). I have fixed the bug in ActioMap.
https://git.gnome.org/browse/glibmm/commit/?id=10bf57e3a014351f65a8fe350269ec3df0293fc2

I keep this bug open until the bug in ApplicationWindow has also been fixed.

Comment 8 Kjell Ahlstedt 2015-12-03 15:37:34 UTC

Created attachment 316724 [details]
Test case 2

A modified test case. This test case uses a window derived from
Gtk::ApplicationWindow instead of a plain Gtk::ApplicationWindow. Then it can
clearly show the bug in Gio::ActionMap::lookup_action_vfunc() even if the bug
in the Gtk::ApplicationWindow constructor has been fixed.

Comment 9 Kjell Ahlstedt 2015-12-03 15:48:42 UTC

Now the bug the Gtk::ApplicationWindow constructor has been fixed.
I've hand-coded the failing constructor and added a comment explaining why the
gmmproc-generated version can't be used.
https://git.gnome.org/browse/gtkmm/commit/?id=c4500fe8c1f2d5d98e04aaabcdafa1e5b794e548