Re: [reSIProcate] More Heap corruption..
Julien,
at the time I encountered these problems I spent almost a week trying different
VS 8.0 compiler and linker settings. I was sure that these settings where
identical for all projects and I was sure that none of these settings was wrong.
Though, after I grabbed a completely new version from SVN and re-upgraded the
VS 7.1 projects to 8.0 everything worked fine, for whatever reason...
Best regards
Matthias Moetje
______________________________________________
TERASENS GmbH Phone: +49.89.143370-0
Augustenstraße 24 Fax: +49.89.143370-22
80333 Munich e-mail: info@xxxxxxxxxxxx
GERMANY Web: www.terasens.com
______________________________________________
-----Original Message-----
From: julien [mailto:julien@xxxxxxxxxxx]
Sent: Wednesday, November 08, 2006 12:41 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Cc: Matthias Moetje; Byron Campen
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@xxxxxxxxxxxx <mailto:info@xxxxxxxxxxxx>
> www.terasens.com <http://www.terasens.com/>*
>
>
> ------------------------------------------------------------------------
> *From:* Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
> *Sent:* Thursday, June 08, 2006 4:46 PM
> *To:* Matthias Moetje - TERASENS GmbH
> *Cc:* resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> *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@xxxxxxxxxxxx <mailto:info@xxxxxxxxxxxx>
>> www.terasens.com <http://www.terasens.com/>*
>>
>> <TERASE1.jpg>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
>> <mailto:resiprocate-devel@xxxxxxxxxxxxxxxxxxx>
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
--
Julien Saito
ジュリアン 齋藤
julien@xxxxxxxxxxx