Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 09/11/2013 15:05, John Emmas wrote:
On 08/11/2013 14:16, Kjell Ahlstedt wrote:
Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(),
it calls Gtk::Object::disconnect_cpp_wrapper(), which removes
glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_.
Thanks Kjell, I'll test that on my system and see if I also get those
changes (I'm guessing I won't).
Hi Kjell, I got so bogged down with gtkmm problems that I forgot about
comparing my own execution path here - but yes, my code follows the very
same path. FWIW this is the interesting code from 'gtk/gtkmm/object.cc'
(function 'Object::disconnect_cpp_wrapper()')
if(gobj())
{
//Prevent gtk vfuncs and default signal handlers from calling our
instance methods:
g_object_steal_qdata((GObject*)gobj(), Glib::quark_); //It will
no longer be possible to get the C++ instance from the C instance.
//Allow us to prevent generation of a new C++ wrapper during
destruction:
g_object_set_qdata((GObject*)gobj(),
Glib::quark_cpp_wrapper_deleted_, (gpointer)true);
//Prevent C++ instance from using GTK+ object:
gobject_ = 0;
}
Pay particular attention to that last comment. This, I believe, is the
root of the problem. Setting 'gobject_' to zero DOES NOT prevent any
C++ wrapper from attempting to access it. Here's an example from
Gtk::Widget::on_unrealize() which can get called AFTER the call to
Object::disconnect_cpp_wrapper().
void Gtk::Widget::on_unrealize()
{
BaseClassType *const base = static_castBaseClassType*(
g_type_class_peek_parent(G_OBJECT_GET_CLASS(gobject_)) // Get
the parent class of the object class (The original underlying C class).
);
if(base base-unrealize)
(*base-unrealize)(gobj());
}
The commented line consistently crashes (for me) if 'gobject_' is zero.
I gave a very similar example here yesterday:-
https://mail.gnome.org/archives/gtkmm-list/2013-November/msg00034.html
The consensus of replies was that it's NOT safe to call these functions
if gObject_ == NULL. Does that give us any more help in tracking these
issues down??
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 08/11/2013 14:16, Kjell Ahlstedt wrote: Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(), it calls Gtk::Object::disconnect_cpp_wrapper(), which removes glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_. I have run your test case that contains /delete mainWnd/. Thanks Kjell, I'll test that on my system and see if I also get those changes (I'm guessing I won't). Which versions of glib, glibmm, gtk+, and gtkmm do you use? glib= 2.38.02 (git) glibmm = 2.38.00 (git) gtk+ = 2.34.23 (git) gtkmm = 2.24.4(tarball) John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
Grrr there was a typo On 09/11/2013 15:05, John Emmas wrote: Which versions of glib, glibmm, gtk+, and gtkmm do you use? glib= 2.38.02 (git) glibmm = 2.38.00 (git) gtk+ = 2.34.23 (git)// --- this should have been 2.24.23 gtkmm = 2.24.4(tarball) ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 07/11/2013 17:39, John Emmas wrote: On 07/11/2013 16:08, Kjell Ahlstedt wrote: I've used gdb to see what's happening in the functions that you mention. The datalist in g_datalist_get_data() contains 2 entries: -- GQuark 1007, gtk-window-icon-info -- GQuark 181, glibmm_Glib::quark_cpp_wrapper_deleted_ You're right. In my build (now building from the tarball sources) the number of registered quarks (in other words, seq_id) is 995. At the point where it crashes the number of datalist entries (d-len) equals 3 and their values are:- 1st entry: 93// Don't know how to work 2nd entry: 856 // out what these ones are 3rd entry: 3219138047 // I'm assuming this one's garbage. The above values are the values I get when the search string is gtk-selection-handlers. For other search strings I get different values. Hi Kjell, Better late than never but this morning, I realised I could simply print out the relevant strings! Here's what I'm getting for those first two entries:- 1st entry (GQuark 93)= glibmm__Glib::quark_ 2nd entry (GQuark 856) = gtk-window-icon-info Notice that my 2nd string is the same as your 1st string. I wonder if this indicates some kind of alignment problem? John n ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
2013-11-08 09:12, John Emmas skrev: On 07/11/2013 17:39, John Emmas wrote: On 07/11/2013 16:08, Kjell Ahlstedt wrote: I've used gdb to see what's happening in the functions that you mention. The datalist in g_datalist_get_data() contains 2 entries: -- GQuark 1007, gtk-window-icon-info -- GQuark 181, glibmm_Glib::quark_cpp_wrapper_deleted_ You're right. In my build (now building from the tarball sources) the number of registered quarks (in other words, seq_id) is 995. At the point where it crashes the number of datalist entries (d-len) equals 3 and their values are:- 1st entry: 93// Don't know how to work 2nd entry: 856 // out what these ones are 3rd entry: 3219138047 // I'm assuming this one's garbage. The above values are the values I get when the search string is gtk-selection-handlers. For other search strings I get different values. Hi Kjell, Better late than never but this morning, I realised I could simply print out the relevant strings! Here's what I'm getting for those first two entries:- 1st entry (GQuark 93)= glibmm__Glib::quark_ 2nd entry (GQuark 856) = gtk-window-icon-info Notice that my 2nd string is the same as your 1st string. I wonder if this indicates some kind of alignment problem? John There are two errors in your datalist, I think. First of course the third garbage entry. Second glibmm_Glib::quark_ instead of glibmm_Glib::quark_cpp_wrapper_deleted_. Here's a backtrace from gdb when gtk_widget_unrealize() is called, with some missing functions manually added. #0 g_quark_to_string (quark=1007) at gquark.c:260 #1 0x74f84648 in g_datalist_get_data (datalist=datalist@entry=0x6bf0e0, key=key@entry=0x75ad8c30 gtk_selection_handler_key gtk-selection-handlers) at gdataset.c:1036 #2 0x7529a83f in g_object_get_data (object=object@entry=0x6bf0d0, key=key@entry=0x75ad8c30 gtk_selection_handler_key gtk-selection-handlers) at gobject.c:3444 #3 0x7590f5f8 in gtk_selection_target_list_remove (widget=0x6bf0d0) at gtkselection.c:817 #4 IA__gtk_selection_remove_all (widget=widget@entry=0x6bf0d0) at gtkselection.c:999 #5 0x759bfa5f in gtk_widget_real_unrealize (widget=0x6bf0d0) at gtkwidget.c:8950 #6 0x75291007 in _g_closure_invoke_va (closure=0x6a98c0, return_value=0x0, instance=0x6bf0d0, args=0x7fffd758, n_params=0, param_types=0x0) at gclosure.c:840 #7 0x752aae5c in g_signal_emit_valist (instance=0x6bf0d0, signal_id=optimized out, detail=optimized out, var_args=var_args@entry=0x7fffd758) at gsignal.c:3238 #8 0x752ab732 in g_signal_emit (instance=instance@entry=0x6bf0d0, signal_id=optimized out, detail=detail@entry=0) at gsignal.c:3386 #9 0x759c3592 in IA__gtk_widget_unrealize (widget=0x6bf0d0) at gtkwidget.c:3605 #10 0x759c4a20 in gtk_widget_dispose (object=0x6bf0d0) at gtkwidget.c:8791 #11 0x75297730 in g_object_run_dispose (object=0x6bf0d0) at gobject.c:1077 Missing from gdb's backtrace: gtk_object_destroy()gtkobject.c:402 Gtk::Window::_destroy_c_instance() window.cc:111 Gtk::Window::destroy_() window.cc:97 #12 0x77aa1dcf in Gtk::Window::~Window (this=0x6a5ff0, __in_chrg=optimized out, __vtt_parm=optimized out) at window.cc:612 #13 0x77aa1ea9 in Gtk::Window::~Window (this=0x6a5ff0, __in_chrg=optimized out, __vtt_parm=optimized out) at window.cc:613 #14 0x00400b60 in main (argc=1, argv=0x7fffd9b8) at main3.cc:13 Before Gtk::Window::_destroy_c_instance() calls gtk_object_destroy(), it calls Gtk::Object::disconnect_cpp_wrapper(), which removes glibmm_Glib::quark_ and adds glibmm_Glib::quark_cpp_wrapper_deleted_. I have run your test case that contains /delete mainWnd/. Which versions of glib, glibmm, gtk+, and gtkmm do you use? Kjell ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 06/11/2013 10:01, Kjell Ahlstedt wrote:
I've made some tests on a Linux system (Ubuntu 13.10) with gtk+
2.24.22 and gtkmm 2.24.4 from tarballs, glib and glibmm fairly new
versions from git's master branch. I get the same sequence of calls as
you get, but no crash. gtk_widget_dispose() is called after
gtk_widget_unrealize() in both cases. valgrind does not report any
accesses to freed memory.
I'll make some more tests. It would be nice if I could reproduce the
crash or some similar misbehaviour. I wonder if gtk+ behaves
differently on Windows and Linux systems.
Thanks Kjell,
Literally within the last few minutes I've discovered the exact cause of
the crash. Although it showed all the hallmarks of a double deletion
somewhere, I gradually became convinced that it was something more
subtle. Last time, I mentioned that I'd traced the crash as far as line
3065 of gtkwidget.c:-
On 05/11/2013 10:10, John Emmas wrote:
g_signal_emit (widget, widget_signals[UNREALIZE], 0);
As you can probably imagine, the crash occurs in the handler for
UNREALIZE. Unfortunately the handler is fearsomely convoluted but
eventually it ends up in 'gtk_widget_real_unrealize()' which calls
'gtk_selection_remove_all()'. That seems to remove some things called
'current_retrievals' and 'current_selections' (whatever they are) and it
ends up calling 'gtk_selection_target_list_remove()'. This calls
'g_object_get_data()' which ends up in 'g_datalist_get_data()' which
looks like this:-
gpointer
g_datalist_get_data (GData **datalist,
const gchar *key)
{
gpointer res = NULL;
GData *d;
GDataElt *data, *data_end;
g_return_val_if_fail (datalist != NULL, NULL);
g_datalist_lock (datalist);
d = G_DATALIST_GET_POINTER (datalist);
if (d)
{
data = d-data;
data_end = data + d-len;
while (data data_end)
{
if (strcmp (g_quark_to_string (data-key), key) == 0) //
--- NOTE THIS LINE
{
res = data-data;
break;
}
data++;
}
}
g_datalist_unlock (datalist);
return res;
}
NOTE THE MARKED LINE - 'g_quark_to_string()' gets called and its return
value is compared (in this case) to the string
gtk-selection-handlers*. But 'g_quark_to_string()' can return NULL.
Here's what it looks like:-
const gchar *
g_quark_to_string (GQuark quark)
{
gchar* result = NULL;
gchar **strings;
gint seq_id;
seq_id = g_atomic_int_get (quark_seq_id);
strings = g_atomic_pointer_get (quarks);
if (quark seq_id)
result = strings[quark];
return result;
}
Going back to where it gets called on the final iteration around
the 'while' loop, 'data-key' appears to have an uninitialized value.
This causes 'g_quark_to_string()' to return NULL, which crashes
strcmp(). This is all way above my comfort level with GTK. I've no
idea what data-key represents or whether there's some valid reason why
it might be uninitialized - BUT - on my particular system its value
happens to be a very high number. If it had been zero (or any low
number) this problem would probably go unnoticed.
Hope one of you guys can make sense of this.
John
P.S. If I appear to be slow in responding please forgive me. At my
end, the gtkmm mailing list is very variable. Sometimes postings get
sent to me straight away. Other times they can take a day or more to
reach me!!
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
2013-11-07 13:02, John Emmas skrev:
Literally within the last few minutes I've discovered the exact cause
of the crash. Although it showed all the hallmarks of a double
deletion somewhere, I gradually became convinced that it was
something more subtle. Last time, I mentioned that I'd traced the
crash as far as line 3065 of gtkwidget.c:-
On 05/11/2013 10:10, John Emmas wrote:
g_signal_emit (widget, widget_signals[UNREALIZE], 0);
As you can probably imagine, the crash occurs in the handler for
UNREALIZE. Unfortunately the handler is fearsomely convoluted but
eventually it ends up in 'gtk_widget_real_unrealize()' which calls
'gtk_selection_remove_all()'. That seems to remove some things called
'current_retrievals' and 'current_selections' (whatever they are) and
it ends up calling 'gtk_selection_target_list_remove()'. This calls
'g_object_get_data()' which ends up in 'g_datalist_get_data()' which
looks like this:-
gpointer
g_datalist_get_data (GData **datalist,
const gchar *key)
{
gpointer res = NULL;
GData *d;
GDataElt *data, *data_end;
g_return_val_if_fail (datalist != NULL, NULL);
g_datalist_lock (datalist);
d = G_DATALIST_GET_POINTER (datalist);
if (d)
{
data = d-data;
data_end = data + d-len;
while (data data_end)
{
if (strcmp (g_quark_to_string (data-key), key) == 0)
// --- NOTE THIS LINE
{
res = data-data;
break;
}
data++;
}
}
g_datalist_unlock (datalist);
return res;
}
NOTE THE MARKED LINE - 'g_quark_to_string()' gets called and its
return value is compared (in this case) to the string
gtk-selection-handlers*. But 'g_quark_to_string()' can return NULL.
Here's what it looks like:-
const gchar *
g_quark_to_string (GQuark quark)
{
gchar* result = NULL;
gchar **strings;
gint seq_id;
seq_id = g_atomic_int_get (quark_seq_id);
strings = g_atomic_pointer_get (quarks);
if (quark seq_id)
result = strings[quark];
return result;
}
Going back to where it gets called on the final iteration around
the 'while' loop, 'data-key' appears to have an uninitialized value.
This causes 'g_quark_to_string()' to return NULL, which crashes
strcmp(). This is all way above my comfort level with GTK. I've no
idea what data-key represents or whether there's some valid reason why
it might be uninitialized - BUT - on my particular system its value
happens to be a very high number. If it had been zero (or any low
number) this problem would probably go unnoticed.
Hope one of you guys can make sense of this.
John
No, unfortunately I can't make any sense of it.
I've used gdb to see what's happening in the functions that you mention.
The datalist in g_datalist_get_data() contains 2 entries:
-- GQuark 1007, gtk-window-icon-info
-- GQuark 181, glibmm_Glib::quark_cpp_wrapper_deleted_
The number of registered quarks (seq_id in g_quark_to_string()) is 1059.
I would not be surprised if the quark indexes or the total number of
quarks differ slightly in a Windows system, or with other versions of
gtk+ and/or glib than my versions.
Since gtk-selection-handlers is not in the datalist,
g_datalist_get_data() returns NULL, but that's no problem.
Kjell
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 07/11/2013 16:08, Kjell Ahlstedt wrote: I've used gdb to see what's happening in the functions that you mention. The datalist in g_datalist_get_data() contains 2 entries: -- GQuark 1007, gtk-window-icon-info -- GQuark 181, glibmm_Glib::quark_cpp_wrapper_deleted_ The number of registered quarks (seq_id in g_quark_to_string()) is 1059. I would not be surprised if the quark indexes or the total number of quarks differ slightly in a Windows system, or with other versions of gtk+ and/or glib than my versions. You're right. In my build (now building from the tarball sources) the number of registered quarks (in other words, seq_id) is 995. At the point where it crashes the number of datalist entries (d-len) equals 3 and their values are:- 1st entry: 93// Don't know how to work 2nd entry: 856 // out what these ones are 3rd entry: 3219138047 // I'm assuming this one's garbage. The above values are the values I get when the search string is gtk-selection-handlers. For other search strings I get different values. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On Mon, 2013-11-04 at 17:58 +, John Emmas wrote:
Allowing the window to close normally will call
'gtk_widget_destroy()'
I wouldn't expect that. gtkmm Windows are not destroyed just because you
close them, though that can be the case with regular GTK+ windows.
which, in turn, calls 'gtk_object_destroy()' and
ultimately, 'g_object_run_dispose()'. As expected, the gtkmm window
disappears from my screen.
And you think that the GObject and/or the C++ instance is freed here,
right? But how are you sure of that?
On Linux, valgrind would tell us about use of freed memory.
Now we reach this line:-
delete mainWnd; // --- crashes here !
The above line invokes the d'tor for Gtk::Window. The d'tor calls
'Gtk::Window::destroy_()' which then calls
'Gtk::Window::_destroy_c_instance()'. Note that
'Gtk::Window::_destroy_c_instance()' contains some warnings about
ensuring that 'C' and C++ objects get destroyed in the correct
sequence. Once inside 'Gtk::Window::_destroy_c_instance()' we hit
this
code:-
if (!gobject_disposed_)
{
//Windows can not be unrefed. They are self-owning.
gtk_object_destroy(object);
}
and bingo! We call 'gtk_object_destroy()' all over again on an
object
that's already been destroyed! The crash actually occurs in
'g_object_run_dispose()' at this line:-
G_OBJECT_GET_CLASS (object)-dispose (object);
Effectively, we're trying to get the class of an object that GTK+
just
destroyed for us. Hope you can make sense of all that!
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On Sat, 2013-11-02 at 14:55 +, John Emmas wrote: The following code crashes when built against gtkmm v2.24.4 Does this happen with the official (but old) gtkmm 2.22 (and its dependencies) binaries? https://wiki.gnome.org/gtkmm/MSWindows -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 05/11/2013 09:31, Murray Cumming wrote: Does this happen with the official (but old) gtkmm 2.22 (and its dependencies) binaries? https://wiki.gnome.org/gtkmm/MSWindows Hi Murray, I can't be precise about that. A week ago I did try going back to version 2.22 but it seemed to be too old for version 3 of our app (I got loads of unresolved symbols at link time). Having said that, 2.22 would definitely work against my simplified test app but there's a huge amount of work involved for me to get back to 2.22 - and even when I get there I can't debug anything effectively. FWIW, version 2 (of our app) uses a much older version of gtkmm (2.6) which I can confirm does NOT exhibit this problem. After some further digging this morning I discovered that the actual crash seems to occur in GTK+ at line 3605 of gtkwidget.c, namely:- g_signal_emit (widget, widget_signals[UNREALIZE], 0); Does that give you any clue about the possible cause? AFAICT that one statement is the only place where the UNREALIZE signal ever gets emitted. From my observations this morning it DOESN'T appear as if it's getting emitted twice. Therefore perhaps the signal is never getting caught anywhere? Is there some default function that should get called if there's no actual handler? Just clutching at straws here. John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
Again, just clutching at straws - but does this give us any clue...?
Here's a partial sequence of function calls if I build my app using
gtkmm. Here's the sequence I see after clicking to close my main window:-
gtk_widget_destroy()
g_object_run_dispose()
g_object_run_dispose()
gtk_widget_dispose()
gtk_widget_unrealize() // --- crashes during unrealize
As near as I can make it, here's the same test app written to use plain GTK+
#include gtk/gtk.h
static void destroy (GtkWidget *window, gpointer data)
{
gtk_main_quit ();
}
int main (int argc, char *argv[])
{
GtkWidget *window;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title (GTK_WINDOW (window), Hello World!);
gtk_widget_set_size_request (window, 200, 100);
/* Connect the main window to the destroy signal */
g_signal_connect (G_OBJECT (window), destroy, G_CALLBACK
(destroy), NULL);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
and here's the (subtlely different) sequence of function calls at closure:-
gtk_widget_destroy()
g_object_run_dispose()
gtk_widget_dispose()
gtk_widget_unrealize() // --- doesn't crash this time
gtk_widget_dispose()
Not sure if that helps at all. I'd assume that the sequence should
essentially be the same??
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On Sat, 2013-11-02 at 14:55 +, John Emmas wrote:
The following code crashes when built against gtkmm v2.24.4 (using MSVC) :-
This is with the gtkmm that you have built yourself, right, and from
git, not from a tarball?
#include gtkmm/main.h
#include gtkmm/window.h
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
Gtk::Window mainWnd;
mainWnd.set_title(Hello World!);
app.run( mainWnd );
return 0;
}
The crash
Do you have a backtrace?
occurs at shutdown, when object 'mainWnd' is getting destroyed
(I believe unrealized is the gtkmm parlance). OTOH if I modify
function main() to look like this, the code doesn't crash any more:-
[snip]
If you are the only one who can reproduce this then I'm afraid you will
need to do some investigtion yourself. If this was happening for other
people they would notice rather quickly.
At the very least, you might derive a Gtk::Window and put some std::cout
output in its destructor, to see when that is being called.
You could also try to handle the underlying GtkWidget's destroy
signal. If that is being emitted too soon, you could investigate why.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
www.openismus.com
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
Thanks for the suggestions, Murray.
On 04/11/2013 08:20, Murray Cumming wrote:
This is with the gtkmm that you have built yourself, right, and from
git, not from a tarball?
Up until yesterday, yes. But yesterday I built gdkmm and gtkmm from the
2.4.4 tarball and got the same results. Over the next day or two I'll
probably swap all my mm libraries to their tarball code and see if
that changes anything.
Do you have a backtrace?
Not at the moment. MSVC isn't as good at generating backtraces as gcc
is, although I should be able to get something...
If you are the only one who can reproduce this then I'm afraid you will
need to do some investigtion yourself. If this was happening for other
people they would notice rather quickly.
At the very least, you might derive a Gtk::Window and put some std::cout
output in its destructor, to see when that is being called.
That's okay, I don't mind doing the detective work. The crash has all
the hallmarks of something getting double deleted but when I placed a
breakpoint in Gtk::Window::~Window() there was no evidence that it was
getting called twice. Perhaps one of its components might be getting
double deleted? The only other thing which strikes me as odd is this:-
// From gtk/gtkmm/window.cc...
Window::~Window()
{
destroy_(); // --- Breakpoint #2 here
}
// From my testing code (not the full example)...
int main (int argc, char *argv[])
{
Gtk::Window* pW = new Gtk::Window;
delete pW; // --- Breakpoint #1 here
return 0;
}
When my code stops at breakpoint #1 I make a note of the value of 'pW'.
When it stops at breakpoint #2 I'd expect my 'this' pointer to have the
same value - but it doesn't. It's always slightly different. For
example, when pW == 0x03604fb0 at breakpoint #1, I notice that at
breakpoint #2, 'this' == 0x03604fcc. I'm not familiar enough with gtkmm
to know if that indicates a problem but there's a consistent difference
between them. Does that seem sensible to you?
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On Mon, 2013-11-04 at 10:31 +, John Emmas wrote: When my code stops at breakpoint #1 I make a note of the value of 'pW'. When it stops at breakpoint #2 I'd expect my 'this' pointer to have the same value - but it doesn't. It's always slightly different. For example, when pW == 0x03604fb0 at breakpoint #1, I notice that at breakpoint #2, 'this' == 0x03604fcc. I'm not familiar enough with gtkmm to know if that indicates a problem but there's a consistent difference between them. Does that seem sensible to you? There is some multiple inheritance involved, which I suppose could cause this, though I would only expect that on different pointer types to the same object. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
Hi Murray, I've made great progress with this today and I've discovered
what the problem is - though not yet where to fix it. I'm sure anyway
that you'll be much better informed about where to implement a fix. The
main thing is that the problem had nothing to do with any 'this' pointer
anomaly. That was a complete red herring. Here's my test code again:-
#include gtkmm/main.h
#include gtkmm/window.h
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
Gtk::Window* mainWnd = new Gtk::Window;
mainWnd-set_title(Hello World!);
app.run( *mainWnd );
delete mainWnd; // --- crashes here !
return 0;
}
'app.run( *mainWnd );' displays an empty gtkmm window with the title
Hello World. Allowing the window to close normally will call
'gtk_widget_destroy()' which, in turn, calls 'gtk_object_destroy()' and
ultimately, 'g_object_run_dispose()'. As expected, the gtkmm window
disappears from my screen. Now we reach this line:-
delete mainWnd; // --- crashes here !
The above line invokes the d'tor for Gtk::Window. The d'tor calls
'Gtk::Window::destroy_()' which then calls
'Gtk::Window::_destroy_c_instance()'. Note that
'Gtk::Window::_destroy_c_instance()' contains some warnings about
ensuring that 'C' and C++ objects get destroyed in the correct
sequence. Once inside 'Gtk::Window::_destroy_c_instance()' we hit this
code:-
if (!gobject_disposed_)
{
//Windows can not be unrefed. They are self-owning.
gtk_object_destroy(object);
}
and bingo! We call 'gtk_object_destroy()' all over again on an object
that's already been destroyed! The crash actually occurs in
'g_object_run_dispose()' at this line:-
G_OBJECT_GET_CLASS (object)-dispose (object);
Effectively, we're trying to get the class of an object that GTK+ just
destroyed for us. Hope you can make sense of all that!
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
Same version of gtkmm, but on linux (mint maya, gcc 4.7.3) both
problematic
proggies work as expected,
On Sat, Nov 2, 2013 at 7:55 AM, John Emmas john...@tiscali.co.uk wrote:
The following code crashes when built against gtkmm v2.24.4 (using MSVC) :-
#include gtkmm/main.h
#include gtkmm/window.h
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
Gtk::Window mainWnd;
mainWnd.set_title(Hello World!);
app.run( mainWnd );
return 0;
}
The crash occurs at shutdown, when object 'mainWnd' is getting destroyed
(I believe unrealized is the gtkmm parlance). OTOH if I modify function
main() to look like this, the code doesn't crash any more:-
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
Gtk::Window* mainWnd = new Gtk::Window;
mainWnd-set_title(Hello World!);
app.run( *mainWnd );
return 0;
}
whereas if I add my own 'delete' statement, it crashes in the same way as
before, while executing 'delete' :-
int main (int argc, char *argv[])
{
Gtk::Mainapp (argc, argv);
Gtk::Window* mainWnd = new Gtk::Window;
mainWnd-set_title(Hello World!);
app.run( *mainWnd );
delete mainWnd; // --- now crashes here !
return 0;
}
This suggests to me that gtkmm is deleting objects somewhere (a) without
knowing whether or not it created them; and (b) without even knowing if
they were created from the free store. FWIW if I adapt the code to use
pure GTK+ functionality the problem goes away (i.e. if the same program
gets implemented using GTK+ instead of gtkmm). I just wondered if this
might ring any bells with anyone here?? Alarm bells, at least..! ;-)
Thanks.
John
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Is gtkmm deleting stuff it shouldn't be deleting ??
On 2 Nov 2013, at 15:05, Tim O'Neil wrote: Same version of gtkmm, but on linux (mint maya, gcc 4.7.3) both problematic proggies work as expected, Hi Tim and thanks for trying my samples so quickly! If I'm absolutely honest the fact that it works with gcc doesn't give me much confidence. I've always found gcc to be very lax when it comes to memory management. gcc seems quite happy to let you carry on using memory after it's been deleted as well as allowing you to use memory that's no longer in scope and even delete memory that already got deleted earlier! MSVC is hugely less forgiving in those respects. I'm pretty certain this will be a problem in one of the mm libraries somewhere :-( John ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
