[reSIProcate] More Heap corruption..

[Matthias Moetje - TERASENS GmbH]

Byron,
 
thanks a lot for your reply. I'm using VS2005 on Windows, thus I can't 
really follow your suggestions.
 
I have now changed the PersistanceManager from a pointer to a member
variable and the problems are gone...!
 
Could this problem be specific to the list implementation VS is using?
It contains the following copyright line
* Copyright (c) 1992-2005 by P.J. Plauger. ALL RIGHTS RESERVED.

The code seems a bit ill (maybe correct, but looks awful), there are hundreds
of subroutines and I somewhat felt getting mad when trying to debug
through all that stuff ...
 
For now I can live with it, though the actual reason for the problem 
remains to be discovered..    
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 6:53 PM
To: Matthias Moetje - TERASENS GmbH
Subject: Re: [reSIProcate] More Heap corruption..


Using a heap-allocated InMemoryRegistrationDatabase should not be a problem. You might try using the debug stl (pass -D_GLIBCXX_DEBUG to the compiler through CXXFLAGS) to check whether some sort of badness is going on in the stl.

Best regards,
Byron Campen



Byron, Scott,

thanks very much for your replies. I'm using the InMemoryRegistrationDatabase. 

I understand that the list elements are'nt pointers, but the std::list implementation
calls delete two times and if I skip the first, the heap corruption does not occur.

I stepped through all of the list implementation code when assigning, but I never
passed the Uri's copy constructor, shouldn't this have occured?

One difference to repro is that I am creating the InMemoryRegistrationDatabase
with "new" (so it is created on the heap itself) and keep a pointer to it as long
as the session is running. Could this be the reason for the problem?

Matthias



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