Please describe the problem:
I need to start a timer (Glib::TimeoutSource) but be able to stop it before it necessarily signals. So I have to call destroy() (just unrefering my timer pointer won't stop the timer).
On the other hand, I'm reusing the same Glib::RefPtr variable. And I'll get 
GLib-CRITICAL **: g_source_unref: assertion `source != NULL' failed

Seems to be the same thing discussed even here (Jan 2006) ? :
http://markmail.org/message/7shyxixmeevv7ojw#query:glibmm timeoutsource still+page:1+mid:smh2eorgiblrpqrz+state:results

Looking at code, it seems the problem might be the bogus implementation of GLib::Source::[un]reference(): they blindly say to unreference gobject_ while, since a destroy might have been called, the  variable gets to be 0 (from Source's destructor). And the unreference function is called by destructor/swap inside Glib::RefPtr.


Steps to reproduce:
Code, not showing my exact problem... but, still: (see comment on how to compile):

#include <glibmm.h>

// g++ -g `pkg-config --cflags glibmm-2.4` `pkg-config --libs glibmm-2.4`  t.cpp


static bool on_t1(Glib::RefPtr<Glib::MainLoop> l)
{
	printf("timer 1\n");
	l->quit();
	return FALSE;
}


int main(int argc, char *argv[])
{
	Glib::init();

	Glib::RefPtr<Glib::MainLoop> loop(Glib::MainLoop::create());

	Glib::RefPtr<Glib::TimeoutSource> t1;

	t1 = Glib::TimeoutSource::create(1000);
	t1->connect(sigc::bind(sigc::ptr_fun(on_t1), loop));
	t1->attach();
	
	loop->run();
	printf("ending loop (timer 1=%p)\n", t1->gobj());
	t1.clear();
	return 0;
}


Actual results:
Get an assertion failure:
GLib-CRITICAL **: g_source_unref: assertion `source != NULL' failed

Expected results:
to not have the assertion failure :)

Does this happen every time?
yes

Other information:
Patch is simple: modify Glib::[un]reference to do ref/unref only if gobject_ is not 0/NULL. Well, I guess gobj_copy() as well. But most critical is unreference()

Last minute update: ay.. there seem to be bigger problems in there, w/ C GSource mistunderstanding and destroy, and memory access. Will post another bug :-( (which will probably make "obsolete" this bug.