forgot the last line of the bt:

+ Trace 34515

all my libraries are the latest anoncvs

My first step would be to comment parts of the example out until I had
a simple-as-possible-but-still-crashing example.

Ok, I isolated the problem to line 43 of hellowindow.cc of the hello
example.  I made my own application (a slimmed down version of the
hello example) to demonstrate this.  Compile it with this command:
g++ -ggdb *.cc `pkg-config libgnomeuimm-2.0 --cflags --libs` -o test

then run test and click the WM's X.  It will segfault.

This example takes all comments out of the hello example and brings in
no XML.  The culprit line is line 11.  Hope this helps!

Created attachment 14841 [details]
Here's the test case....

save the attachment as hello_isolated.tar.gz

Confirmed. The example segfaults on quit for me too.

I need to check this with the latest orbitcpp from cvs - there have
been some lifetime changes. But the orbitcpp from cvs doesn't work
with libbonobomm. Stay tuned. I just wanted to say I hadn't forgotten
this.

Could you check with the latest orbitcpp again?

Yes, it still segfaults.  If you need a new backtrace, I can provide
it.  Thanks for checking this all out for me Murray.  Hopefully, soon,
I'll be able to figure it out after dealing with vfs stuff :).

I finally built the latest cvs orbit and libbonobouimm and this bug
still exists.

There are two problems with the example. First, the UIComponent_impl
HelloWindow::m_servantComponent is destructed before the
Gnome::Bonobo::Window base class. The destruction of the base class
attempts to call methods on the m_servantComponent resulting in the
segmentation fault you are getting. Next, the m_servantComponent is
activiated in the Root POA but never deactivated. When program exits
ORBit tries to clean up all still active objects. Again resulting in a
seg fault. Thus the simplest and most hackish way to fix the problem
is to new allocate the HelloWindow object and never delete it. I
haven't got my head around the correct way to fix these two problems.

Created attachment 21368 [details] [review]
Correct order of destruction and perform object deactivation (ugly and leaks memory/references).

Hi,

I have just added a patch that reorders the destruction of members and
bases and deactivates the servant object before destroying it. The
result is very ugly. To do this nicely I suggest we add a class
template to bonobomm: 

// Encapsulate ownership of a single servant and automatically
// deactivate in bonobo POA at end of lifetime.
template <class S>
class ServantOwner {
protected:
        S m_servant;
        ~ServantOwner()
        {
                _orbitcpp::CEnvironment env;
                PortableServer_POA poa = bonobo_poa();
                                                                     
          
                PortableServer_Servant servant =
m_servant._orbitcpp_get_c_servant();
                PortableServer_ObjectId* oid =
PortableServer_POA_servant_to_id(poa, servant, env._orbitcpp_cobj());
                env.propagate_poaex();
                PortableServer_POA_deactivate_object(poa, oid,
env._orbitcpp_cobj());
                env.propagate_poaex();
        }
};