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 |
|
|
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 |
|
|
<TERASE1.jpg> _______________________________________________
resiprocate-devel mailing list
|