Bug 104181 – Example segfaults after some time

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 104181 - Example segfaults after some time


Summary:	Example segfaults after some time


Status:	RESOLVED FIXED

Product:	gconfmm
Classification:	Other
Component:	general
Version:	git master
Hardware:	Other other

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

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2003-01-22 20:46 UTC by Ole Laursen
Modified:	2011-01-16 23:35 UTC

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

Attachments
Patch of gconfmm/ChangeLog and gconfmm/gconf/gconfmm/callback.cc (1.65 KB, patch) 2003-01-27 22:22 UTC, Ole Laursen	none	Details \| Review

Description Ole Laursen 2003-01-22 20:46:18 UTC

The example in gconfmm/example/client segfaults for me after some time if I
press and hold down a key in one of the entries - e.g. it just segfaulted
after having written "dddddddd".

The backtrace doesn't give any useful information:

  gdb --core=core .libs/test_client
  [...]
  (gdb) bt

+ Trace 33023

#0 strstr
from /lib/libc.so.6
#1 g_strsplit
from /usr/lib/libglib-2.0.so.0
#2 gconf_listeners_remove_if
from /usr/lib/libgconf-2.so.4
#3 gconf_client_change_set_from_current
from /usr/lib/libgconf-2.so.4
#4 gconf_client_change_set_from_current
from /usr/lib/libgconf-2.so.4
#5 gconf_client_change_set_from_current
from /usr/lib/libgconf-2.so.4
#6 g_timeout_add
from /usr/lib/libglib-2.0.so.0
#7 g_get_current_time
from /usr/lib/libglib-2.0.so.0
#8 g_main_context_dispatch
from /usr/lib/libglib-2.0.so.0
#9 g_main_context_dispatch
from /usr/lib/libglib-2.0.so.0
#10 g_main_loop_run
from /usr/lib/libglib-2.0.so.0
#11 gtk_main
from /usr/lib/libgtk-x11-2.0.so.0
#12 Gtk::Main::run_impl
from /usr/lib/libgtkmm-2.0.so.1
#13 Gtk::Main::run
from /usr/lib/libgtkmm-2.0.so.1
#14 main
at main.cc line 33


I'm experiencing the same problem in my own application with spinbuttons -
random crashes after changing the values a few times.

Comment 1 Ole Laursen 2003-01-27 21:12:47 UTC

I've run the example with Electric Fence enabled. It seems to crash
the program consistently when working with a hash table:

+ Trace 33206

#0 strcmp
from /lib/libc.so.6
#1 g_str_equal
from /usr/lib/libglib-2.0.so.0
#2 g_hash_table_destroy
from /usr/lib/libglib-2.0.so.0
#3 g_hash_table_lookup
from /usr/lib/libglib-2.0.so.0
#4 gconf_client_value_changed
from /usr/lib/libgconf-2.so.4
#5 gconf_client_change_set_from_current
from /usr/lib/libgconf-2.so.4
#6 gconf_client_change_set_from_current
from /usr/lib/libgconf-2.so.4
#7 g_timeout_add
from /usr/lib/libglib-2.0.so.0
#8 g_get_current_time
from /usr/lib/libglib-2.0.so.0
#9 g_main_context_dispatch
from /usr/lib/libglib-2.0.so.0
#10 g_main_context_dispatch
from /usr/lib/libglib-2.0.so.0
#11 g_main_loop_run
from /usr/lib/libglib-2.0.so.0
#12 gtk_main
from /usr/lib/libgtk-x11-2.0.so.0
#13 Gtk::Main::run_impl()
from /usr/lib/libgtkmm-2.0.so.1
#14 Gtk::Main::run(Gtk::Window&)
from /usr/lib/libgtkmm-2.0.so.1
#15 main
at main.cc line 33


I have no idea whether this really is related to the bug though. I
also don't quite understand the stack trace since g_hash_table_lookup
doesn't seem to be calling g_hash_table_destroy at all in
glib/ghash.c. Perhaps it is just a really nasty memory bug.

Comment 2 Ole Laursen 2003-01-27 22:21:09 UTC

I've found the bug. In gconf/gconfmm/callback.cc there is the function:

void CallbackHolder::call(GConfClient* client, guint i, GConfEntry*
pEntry, void* data)
{
  if(data)
    ((CallbackHolder*)data)->m_Slot (i, Entry (pEntry));
}

If the contents is #if'ed out, I can't reproduce the bug:

void CallbackHolder::call(GConfClient* client, guint i, GConfEntry*
pEntry, void* data)
{
#if 0
  if(data)
    ((CallbackHolder*)data)->m_Slot (i, Entry (pEntry));
#endif
}

If, however, the entry is still created, I can reproduce it:

void CallbackHolder::call(GConfClient* client, guint i, GConfEntry*
pEntry, void* data)
{
  Entry e(pEntry);
#if 0
  if(data)
    ((CallbackHolder*)data)->m_Slot (i, Entry (pEntry));
#endif
}

I've looked at the definition of Entry. It seems Entry(pEntry) assumes
 that the constructor is given a copy of the C object. But the
reference on GConf says:

  GConfClientNotifyFunc ()
  ...  The value argument should not be modified, and should be
  copied if you want to keep it around (the GConfClient will
  destroy it sometime after your notify function is called).

So Entry(pEntry) should be Entry(pEntry, true). Is it customary that
values in gtkmm don't need to be copied? It seems unsafe to use a
default argument here, when the risk is memory corruption.

I'm attaching a patch. Since the bug renders gconfmm almost completely
 unusable with spinbuttons, I think it might be a good idea to release
a new version.

Comment 3 Ole Laursen 2003-01-27 22:22:04 UTC

Created attachment 13862 [details] [review]
Patch of gconfmm/ChangeLog and gconfmm/gconf/gconfmm/callback.cc

Comment 4 Murray Cumming 2003-01-28 23:14:19 UTC

Fantastic. Well done. I was beginning to worry about this. By the way,
valgrind might also have been helpful but it crashes on this example.

Unless it's urgent for you, I will release a new version after a few
days, just in case.