×

Discussion Board

Results 1 to 7 of 7
  1. #1
    Registered User
    Join Date
    Nov 2004
    Posts
    38

    SIP Plugin Memory Leak

    Hello,

    We are building an app based on the SIP plugin.

    The following code sets up some SIP message headers and sends a subscribe message. The problem lies with the CSIPMessageElements object. When it is passed to the CSIPSubscribeDialogAssoc::SendSubscribeL() method, ownership of the CSIPMessageElements object is transferred meaning the responsibility to free the memeory held by this object becomes that of the SIP stack.

    It appears that ownership is transferred as attempting to destroy the object causes an access violation. However, Alloc panic (memory leak) is reported when the application is closed within the emulator. If I comment out the SendSubscribeL() call and change the Pop(iSubscribeMsgElems) to PopAndestroy(iSubscribeMsgElems) the leak is gone!

    Is this a known problem with the SIP stack?

    Thanks,
    RE

    if( iProfile->Status() == CSIPProfile::ERegistered )
    {
    // Check for a connection
    if( !iConnection )
    iConnection = iProfileRegistry->ConnectionL(*iProfile);

    // reset if retrying
    if( iSIPSubscribeDialogAssoc )
    {
    delete iSIPSubscribeDialogAssoc;
    iSIPSubscribeDialogAssoc = 0;
    }

    // Create Subscribe dialog assoc
    iSIPSubscribeDialogAssoc = CreateSIPSubscribeDialogAssoc();

    // Create the messageElements to contain the User Headers Array
    CSIPMessageElements *iSubscribeMsgElems = CSIPMessageElements::NewLC();

    // Create the User Headers for the SUBSCRIBE
    RPointerArray<CSIPHeaderBase > *userHeadersArr = new(ELeave) RPointerArray<CSIPHeaderBase>;
    CleanupStack::PushL(userHeadersArr);

    // Create Expires Header
    CSIPExpiresHeader *expiresHdr = new(ELeave)CSIPExpiresHeader(3600);
    CleanupStack::PushL(expiresHdr);
    userHeadersArr->Append(expiresHdr);

    // Create the event header
    _LIT8(aEventPackage, "presencelist");
    CSIPEventHeader *eventHdr = CSIPEventHeader::NewLC(aEventPackage);
    userHeadersArr->Append(eventHdr);

    // Create the Accept Header
    _LIT8(aMediaType, "application");
    _LIT8(aMediaSubtype, "cpim-pidf+xml");
    CSIPAcceptHeader *acceptHdr = CSIPAcceptHeader::NewLC( aMediaType, aMediaSubtype );
    userHeadersArr->Append(acceptHdr);

    // Create the 2nd Accept Header (to insure we are identical with header in SAL Subscribe)
    _LIT8(aMediaType2, "application");
    _LIT8(aMediaSubtype2, "cpim-plidf+xml");
    CSIPAcceptHeader *acceptHdr2 = CSIPAcceptHeader::NewLC( aMediaType2, aMediaSubtype2 );
    userHeadersArr->Append(acceptHdr2);

    // Send Subscribe
    iSubscribeMsgElems->SetUserHeadersL(*userHeadersArr);
    if ( iSIPSubscribeDialogAssoc )
    {
    if ( iSUBSCRIBEClientTransaction )
    delete iSUBSCRIBEClientTransaction;

    iSUBSCRIBEClientTransaction = iSIPSubscribeDialogAssoc->SendSubscribeL(iSubscribeMsgElems);
    }

    CleanupStack::Pop(acceptHdr2);
    CleanupStack::Pop(acceptHdr);
    CleanupStack::Pop(eventHdr);
    CleanupStack::Pop(expiresHdr);
    userHeadersArr->Close();
    CleanupStack::PopAndDestroy(userHeadersArr);
    CleanupStack::Pop(iSubscribeMsgElems);
    return E_OK;

  2. #2
    Registered User
    Join Date
    Jan 2005
    Posts
    15

    SIP mem leak

    I too have observed this. I've tried adjusting the tear-down sequence, but it doesn't help. I assume someone is looking into it, but am not sure...

  3. #3
    Registered User
    Join Date
    Nov 2004
    Posts
    38

    SIP Mem Leak

    I am using Version 2.0 of the SIP Plugin and have not had a chance to try version 3.0. Which version are you using?

    RE

  4. #4
    Registered User
    Join Date
    Jan 2005
    Posts
    15

    SIP Mem leak

    Version 2.

    Have you tried registering with a public SIP server yet?

  5. #5
    Registered User
    Join Date
    Nov 2004
    Posts
    38

    SIP Mem Leak.

    Hello,

    I have discovered that the SIP stack leak is actually a red herring and that the leak occurs in the incoming Notifications which result from the Subscribe request. The ownership of the incoming Transaction objects is transferred from the stack to the application and so it is the responsibility of the app to free the memory of these objects.

    We have not registered with public SIP server per say although with the 6620, the registration messages are sent using our carriers network and are routed back to our internal network and SIP server. In this context we could be considered to be registering with a public server.

    RE

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    15

    Mem leak

    Thanks, I'll see if this fixes it. I thought I tried deleting the transaction object, but I'll try again.

    When we attempt to register with a public server from behind a firewall(WINS emulator, or 6620), the SIP stack rejects the servers registration acknowledgement with 'ERegistrarRespondedWithDifferentSipAddressInContact'.

    You may want to look into this. There are several public servers you can attempt to register with.

  7. #7
    Registered User
    Join Date
    Nov 2004
    Posts
    38
    I'm not surprised to hear that the emulator does not receive the ACK. The stack on your PC (emulator) is most likely storing private network address in the SIP messages. The public SIP server is reponding using that IP which is not a public IP address...

    Hope this helps,
    RE

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •