Bug on a very simple test on glibmm...

[jey zemarmot net]

Hi,

first I hope this is the good mailing-list, because there was one for gtkmm, and
one for gnome. But I am using only glibmm, and there was no glibmm ml... So it
could have been both list (I think). I took this one.

Indeed I intended to use the glibmm smart pointers: the Glib::RefPtr.

But I had some trouble on using it. Finally, I made different tests, and even
when I only initialize the pointer, the bug appears. To be clear, here are the
simplest program I made to show the bug, and the bug appearance:

____________________
#include <glibmm.h>

class Node : public Glib::Object
{
    public:
        Node () {};
};

int main( int argc, char **argv )
{
    Glib::RefPtr<Node> v (new Node ());
    return 0;
}
_______________________

You see, it cannot be simplest.
I compile it with:
g++ -o test test.cpp `pkg-config glibmm-2.4 --cflags --libs`

And I exported the PKG_CONFIG_PATH variable to /usr/local/lib/pkgconfig, because
I am on a Mandrake, and it has not the most recent library version.
So I installed in my /usr/local/ the glib-2.6.4, libsigc++-2.0.12 and
glibmm-2.6.1, which seemed to be all the latest versions (but it didn't work
either with older versions I had before).

So it compiles...

But when I run it, I get:
_______________
(process:2208): GLib-GObject-CRITICAL **: file gobject.c: line 853
(g_object_newv): assertion `G_TYPE_IS_OBJECT (object_type)' failed

(process:2208): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_unref): assertion `G_IS_OBJECT (object)' failed
______________

If my class was derived from Glib::ObjectBase, I have only 1 assertion:
_____________
(process:2127): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_unref): assertion `G_IS_OBJECT (object)' failed
______________

But still I have one...
And so I don't understand...

But the funniest is that the program doesn't even crash. I thought than an
assertion was supposed to stop the process, doesn't it?
But it continued. To check it, I tried to wait for an input from the user, just
after the Glib::RefPtr initialisation, and it worked (so no crash, just funny
output message).
I could see then than the first assertion was launched at the pointer
initialisation,
and the second, after my input, so probably when the program shut down.

Indeed in my initial program, I was trying to insert one of my Node in a
std::map<Glib::ustring,Glib::RefPtr<Node> >. Then it actually crashed: there
were several assertions too and it segmented fault. But I could not reproduce it
after modifying several things, so I am not sure this was related to this
assertions problems.

Anyway, even though it doesn't crash, I still get many many of these assertions
on my output (because I use those pointer a lot indeed). And I don't want
these. I like programmation when it is perfect and clean (and clear). So what is
happening?
What may be the problem?

For now, if you cannot deal with the problem immediately (so forget this
question if you are able to answer me and give me the reason and the solution
right now), could someone lead me to another good smart pointer? And then maybe
I will be back on the Glib pointer later; because in a few weeks, I have things
to present to an university supervisor (I am programming this to implement some
university work).
I would like also a reference counter pointer (so not the std pointer).

And then if someone can explain and correct this bug, it will be great. Just
tell me, and I will use the library again. If I can help to explain better how I
got it,
don't hesitate to ask. But I think I said all what I did. You saw that in my
test program, I got an assertion, just by initializing the Glib pointer.
Strange.
Thanks.

Jehan