GNOME Bugzilla – Bug 94207
TextMark::get_iter does not do a reference on Glib::RefPtr<TextMark>().
Last modified: 2004-12-22 21:47:04 UTC
Gtk::TextMark::get_iter() does not do a reference on the Glib::RefPtr<TextMark>(this) passed to Gtk::TextBuffer::get_iter_at_mark(). This results in the underlying GtkTextMark getting freed and subsequent seg fault (e.g. on a second call of Gtk::TextBuffer::insert_at_cursor()). I have attached a patch which fixes the problem although, being new to gtkmm, perhaps the developers may have a better method of addressing the problem.
Created attachment 11262 [details] [review] Patch to textmark.ccg
Created attachment 11263 [details] [review] Same as previous patch. This time using requested 'cvs diff -u' command.
Shouldn't Gtk::TextBuffer::get_iter_at_mark() do the referece()? Where does the corresponding unreference() take place?
You catch me a little late in the evening - so be it :-) I'm relatively new to C++, as well as gtkmm. That aside, reading the documentation, doesn't the unreference() of 'Glib::RefPtr<TextMark>(this)' occur when it goes out of scope in Gtk::TextMark::get_iter()? I understood (maybe :-)) that Gtk::TextBuffer::get_iter_at_mark() would normally be called with a Glib:RePtr<> that had been constructed in such a way as to have had a 'reference()' conducted. The constructor 'Glib::Refptr(T_CppObject* pCppObject)' as far as I can see in refptr.h is only for use with create* methods - don't they do their own references?
Yes, it is a little late in the evening :-) WhatI meant to say was - after construction via 'Glib::RefPtr<TextMark>(this)' - as far as I can see no 'reference()' is conducted, but an a 'unreference()' *will* be when it goes out of scope in 'get_iter()' - no?
That's the correct fix. Applied. It looks unusual, but that's just because it's unusual to make a RefPtr-ed this. Remember, that this isn't necessary outside of the class because that copy constructor is not public anyway.