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

  • From: Raymond Dahlberg <rd@xxxxxxxxxxx>
  • To: muscle@xxxxxxxxxxxxx
  • Date: Thu, 8 Apr 2010 12:38:52 +0200

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>
> 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: