[reSIProcate] More Heap corruption..
julien
julien at aplix.co.jp
Thu Nov 9 03:26:00 CST 2006
Thank you for you answers,
I downloaded the latest version of resiprocate,
Do I have to use /MDd or /MTd would work too?
Because the project I am trying to link to is in MTd mode so I am using
MTd in resiprocate too.
could that be the problem?
Thank you for your help all
Scott Godin a écrit :
> Make sure you are compiling all libraries and components with the same
> version of the c-runtime library (ie. MultiThreaded DLL).
>
> -----Original Message-----
> From: resiprocate-devel-bounces at list.sipfoundry.org
> [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of julien
> Sent: Wednesday, November 08, 2006 6:41 AM
> To: resiprocate-devel at list.sipfoundry.org
> Subject: Re: [reSIProcate] More Heap corruption..
>
> Hello Everyone,
> I am having some heap corruption popping everytime I try to free a
> resiprocate object :
> Even the smallest call :
> SipMessage *test = new SipMessage();
> delete test;
> generates a Heap corruption error inside "delete test"...
> Everything works fine until I try to delete,
> So I can use resiprocate correctly, send messages and everything but I
> can't delete anything without getting errors
>
> I have tried adding #define _HAS_ITERATOR_DEBUGGING 0 in my compile
> options (as suggested in this thread),
> but it doesn't change anything.
> I am compiling resiprocate on vs2005 with the following compiler options :
>
> /D "WIN32" /D "_DEBUG" /D "_LIB" /D "USE_ARES" /D "USE_IPV6" /D
> "_VC80_UPGRADE=0x0710" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fo"Debug\\"
> /Fd"Debug\vc80.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt /Zm300 /D
> "_HAS_ITERATOR_DEBUGGING=0"
>
> (On compilation I receive a lot of warning about strcpy and such being
> deprecated)
>
> I think It has to do with my compile options :-/ ?
>
> Any help/pointing in the right direction/investigation tips would be
> most welcome!!
> Thank you very much for your help
> Best Regards,
> Julien
>
>
> Matthias Moetje - TERASENS GmbH a écrit :
>
>> hhmpf, forget my last message, it still didn't work
>> as a non-heap variable.
>> I found that the problem could be even reduced to this
>> if (true)
>> {
>> ContactRecordList Contacts;
>> }
>> As soon as the Contacts variable went out of scope
>> I got the heap corruption message, even when
>> nothing was done with the variable.
>> Well, you could easily think now, that the heap corruption
>> comes from elswhere but it just occurs when a
>> ContactRecordList goes out of scope, not with other
>> variable types.
>> Now I have disabled iterator debugging through:
>> #define _HAS_ITERATOR_DEBUGGING 0
>> I did this for my application and for all the stack and
>> now I don't get any more heap corruption errors.
>> Though I still don't know the actual reason for this
>> problem and I'm not really sure if I have just disabled
>> the error or if I have eliminated the reason for the
>> error.
>>
>> Best regards,
>>
>> Matthias Moetje
>>
>> *TERASENS GmbH
>> Augustenstraße 24
>> 80333 Munich
>> GERMANY*
>> *Phone:
>> Fax:
>> e-mail:
>> Web:*
>> *+49.89.143370-0
>> +49.89.143370-22
>> info at terasens.com <mailto:info at terasens.com>
>> www.terasens.com <http://www.terasens.com/>*
>>
>>
>>
>>
> ------------------------------------------------------------------------
>
>> *From:* Byron Campen [mailto:bcampen at estacado.net]
>> *Sent:* Thursday, June 08, 2006 4:46 PM
>> *To:* Matthias Moetje - TERASENS GmbH
>> *Cc:* resiprocate-devel at list.sipfoundry.org
>> *Subject:* Re: [reSIProcate] More Heap corruption..
>>
>> I am not sure that is what you are seeing here. ContactRecord
>> doesn't contain pointers to anything, and the ContactRecordList
>> uses ContactRecord values (not pointers), so copy constructing the
>> ContactRecordList mContacts should make full copies of everything
>> (unless the copy constructor for Uri is broken somehow, which
>> would be very surprising indeed). There should be nothing shared
>> between the returned list and the list that is internal to the
>> RegistrationPersistenceManager. Are you using the
>> InMemoryRegistrationDatabase found in dum, or some other
>> implementation of RegistrationPersistenceManager?
>>
>> Best regards,
>> Byron Campen
>>
>>
>>> Hi,
>>> I'm currently facing another heap corruption problem. I think this is
>>> caused by the way the RegistrationPersistenceManager::getContacts
>>> is implemented:
>>>
>>> typedef std::list<ContactRecord> ContactRecordList;
>>>
>>> virtual ContactRecordList getContacts(const Uri& aor) = 0;
>>>
>>>
>>> When this function is used like:
>>>
>>> *ContactRecordList mContacts = pStore->getContacts(aor);*
>>>
>>> then the contents of the returned list get assigned to
>>> mContacts, but the internal ContactRecordList gets
>>> destroyed which causes it to destroy(delete) all elements
>>> and this is causing the heap corruption because the
>>> elements are still present in mContacts.
>>>
>>> To proof this is skipped the delete in the debugger and
>>> the corruption message does not occur.
>>>
>>> How can we solve this problem? (or am I missing something?)
>>>
>>> What about making getContacts return shared_ptr<ContactRecordList>?
>>>
>>> Best regards,
>>>
>>> Matthias Moetje
>>>
>>> <TERASE1.jpg>
>>> *TERASENS GmbH
>>> Augustenstraße 24
>>> 80333 Munich
>>> GERMANY*
>>> *Phone:
>>> Fax:
>>> e-mail:
>>> Web:*
>>> *+49.89.143370-0
>>> +49.89.143370-22
>>> info at terasens.com <mailto:info at terasens.com>
>>> www.terasens.com <http://www.terasens.com/>*
>>>
>>> <TERASE1.jpg>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at list.sipfoundry.org
>>> <mailto:resiprocate-devel at list.sipfoundry.org>
>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>
>
>
>
--
Julien Saito
ジュリアン 齋藤
julien at aplix.co.jp
More information about the resiprocate-devel
mailing list