[muscle] Re: Fwd: Updating from 3.30 to 5.22

  • From: "Jeremy Friesner" <jeremyf@xxxxxxxxxxxxxx>
  • To: <muscle@xxxxxxxxxxxxx>
  • Date: Thu, 8 Apr 2010 07:17:43 -0700

Hi Raymond,

Look in ObjectPool.h, the #ifdef should be present there. (I'd look it up myself but I'm away from my computer this week and can't look at code from my cell phone)

Hunting down the non-released object is a good idea in any case, since it may indicate a memory leak. You might be able to make the assertion failure more helpful (e.g. By having it print out the type of the ObjectPool, which would include the type of the unreleased object as its template argument). Unfortunately it's not possible to print out the address of the unreleased object, only the address of the slab whose reference count is non-zero. You could print out the slab's reference count though; then you'd know how many objects are unaccounted for.

Jeremy




On Apr 8, 2010, at 3:39 AM, "Raymond Dahlberg" <rd@xxxxxxxxxxx> wrote:

The closest define I could find was MUSCLE_DISABLE_MESSAGE_FIELD_POOLS in the BUILDOPTIONS.txt file. I have now tested to build with this flag defined. But the problem is still there, and the error message is the same:

[C 04/08 11:35:02] ~ObjectPool 005E2560: slab 007A9798 is still in use when we destroy it! [C 04/08 11:35:02] 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 guess I have to try to find out which object that is not released.

Any hints welcome :-)

Raymond

On Wed, Apr 7, 2010 at 4:59 PM, Jeremy Friesner <jeremyf@xxxxxxxxxxxxxx > wrote:




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.


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

Other related posts: