[reSIProcate] More Heap corruption..

Thu Jun 8 16:34:19 CDT 2006

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
 <mailto:info at terasens.com> info at terasens.com
 <http://www.terasens.com/> 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
 <mailto:info at terasens.com> info at terasens.com
 <http://www.terasens.com/> www.terasens.com	

<TERASE1.jpg>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at list.sipfoundry.org
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060608/3247b23b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: att6a3a8.jpg
Type: image/jpeg
Size: 2937 bytes
Desc: att6a3a8.jpg
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060608/3247b23b/attachment.jpg>