[muscle] Fwd: Updating from 3.30 to 5.22

  • From: "Jeremy Friesner" <jeremyf@xxxxxxxxxxxxxx>
  • To: <muscle@xxxxxxxxxxxxx>
  • Date: Wed, 7 Apr 2010 07:59:59 -0700





Begin forwarded message:

From: "Jeremy Friesner" <jeremyf@xxxxxxxxxxxxxx>
Date: April 7, 2010 7:22:51 AM PDT
To: <muscle@xxxxxxxxxxxxx>
Subject: Re: [muscle] Updating from 3.30 to 5.22



Hi Raymond,

I think what you are seeing is a result of ObjectPool switching to a slab allocator mechanism. Older versions of ObjectPool used individually allocated objects, but with the move to ConstSocketRefs for socket tracking, I switched to slab allocation so that a whole array of objects is allocated at once instead.

As a side effect of that, the entire array of objects also needs to be freed at once. When the ObjectPool object itself is destroyed (e.g. at process exit time) it needs to delete its allocated object arrays, but if any of the objects are still in use (I.e. hasn't been released back to the pool), doing so would cause s dangling pointer, so an assertion failure is triggered to help track down the 'leak'.

The best fix is to figure out what object has been allocated from a pool and never returned to the pool, and make sure it gets returned to the pool before the process exits. The quick fix is to add - DMUSCLE_DISABLE_OBJECT_POOLS (iirc) to your Makefile to disable object pools (and thus the slab allocations). With that flag object pools just become a pass through to new/delete.

Jeremy


On Apr 7, 2010, at 4:30 AM, "Raymond Dahlberg" <rd@xxxxxxxxxxx> wrote:

Hi Muscle list!

We have been using Muscle for several years in our own network library. The code has been pretty stable and unchanged for some time, but now we want to do some changes, and decided it was time to upgrade Muscle too.

I have successfully adapted our code to the source incompatible changes, and everything builds, and the first tests show that basic functionality works. Clients connect to the server, and the can communicate. So far so good :)

But it seems something is changed in the cleanup code, since I always get a MUSCLE assertion failure when the last muscle application exits. It also outputs on the command line:

[C 04/07 13:20:22] ~ObjectPool 004FB268: slab 00A89CD0 is still in use when we destroy it! [C 04/07 13:20:22] ASSERTION FAILED: (\muscle\util/ObjectPool.h: 125) ObjectPool destroyed while its objects were still in use (Is a CompleteSetupSystem object declared at the top of main()?)

I understand that one must have a CompleteSetupSystem on top of main, but this has been there all the time (not changed during muscle upgrade). For example a little test server app where this is happening has this in main:

int main( int argc, char** argv )
{
    // Initialize NetBorealis.
    SNbSetupSystem ss;


Where SNbSetupSystem is a singleton with this constructor:

    SNbSetupSystem::SNbSetupSystem( )
        : m_CssPtr( 0 ),
        _serverExitedSignalHandle( 0 )
    {
        if ( m_CssPtr == 0 )
        {
            try {
                m_CssPtr = new CompleteSetupSystem( );
} catch ( bad_alloc& ) { fatalError( "FATAL ERROR: Out of memory (%s:%d).\n", __FILE__, __LINE__ ); }
        }
        _serverExitedSignalHandle = CreateEvent( 0, 0, 0, 0 );
    }

Any hints on this?

Regards,
Raymond

NOTICE: This email may contain confidential information.  Please see 
http://www.meyersound.com/confidential/ for our complete policy.

Other related posts: