< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Access Violation in Data.cxx


OK, so a few other things I’ve learned:

 

-          I can definitely reproduce this with basicCall (as is, latest code from SVN, with one minor modification to keep executing most of the main() in a loop).

-          One way I’ve found to make the issue happen fairly quickly is to bog down the processor – e.g. I had this running for about 30 minutes on my 1.7GHz laptop with 384 MB of RAM, then went to try and open the Start Menu which made the machine chug away for a bit (likely since I had Visual Studio open), and bang, there was the exception.  I also experienced this yesterday on my workstation just after I connected to it using Remote Desktop (which also makes a machine chug away for a bit).  So there seems to be a correlation.  Might point to a timing issue?

-          The problem seems to be in TransactionMap::add(..) at the point where it does mMap.erase(i).  The iterator appears to be invalid.  I have no idea why this might be the case, but I noticed something kinda strange:  in TransactionMap::erase(..) there’s a comment: “don't delete it here, the TransactionState deletes itself and removes itself from the map”.  However in TransactionMap::add(..) it actually *does* delete the TransactionState (delete i->second).  This is totally a guess, but seemed strange to me.

 

Very curious to know if anyone else can reproduce this, and if anyone has any thoughts on what the problem is?  As it is, the latest revision is unusable for me.

 

Thanks,

 - Jeremy -

 

 

 


From: Jeremy Geras
Sent: Thursday, November 16, 2006 3:42 PM
To: Jeremy Geras; Scott Godin; Byron Campen
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Access Violation in Data.cxx

 

Turns out I can repro this with basicCall…  Just created a batch file that keeps running basicCall.exe, and after 10 or 15 tries, I got the error…

 


From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Jeremy Geras
Sent: Thursday, November 16, 2006 2:53 PM
To: Scott Godin; Byron Campen
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Access Violation in Data.cxx

 

Not at the moment, but I’ll work on it…

 

Using MS Visual Studio 2003 SP1 and .NET 1.1 SP1.

 


From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, November 16, 2006 2:30 PM
To: Byron Campen; Jeremy Geras
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Access Violation in Data.cxx

 

Do you have test program that can post that will duplicate this error?

 

From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Byron Campen
Sent: Thursday, November 16, 2006 5:25 PM
To: Jeremy Geras
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Access Violation in Data.cxx

 

          So ApiCheckList didn't complain about anything? Hmm. I would ask what version of Visual Studio or .NET you're using, but frankly I know very little about working with resip on Windows. Scott Godin might have a better idea of what you're dealing with here. The members of the Data seem ok; is this from a crash?

 

Best regards,

Byron Campen

 

Including ApiCheckList.hxx didn’t help – same problem.

 

I’ve attached a screen shot showing the QuickWatch of the tid variable at TransActionMap::add

 

I’m not 100% sure any more that reverting 6504 completely fixes the problem (though it does seem to make it happen a lot less frequently)…  I.e. I’ve experienced a crash with that revision reverted, but unfortunately I wasn’t attached to the debugger so I’m not sure it was the same crash.

 


From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Thursday, November 16, 2006 12:26 PM
To: Jeremy Geras
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Access Violation in Data.cxx

 

            Ok, after looking at the stack trace in your mail, it appears that stuff is hosed well before we get into Data::rawHash() (unless 0xfeeefeee is a valid pointer, and you have a transaction id that is 427075694 characters long, both of which are doubtful). It is possible you're running into one of the known API/ABI mismatch issues that pop up when you compile against the resip headers with different flags than the libs were compiled with. Try including resip/stack/ApiCheckList.hxx in whatever app you're building, and see if anything pops up. If that doesn't solve anything, let's have a closer look at what state the members of that Data are in when things go south.

 

Best regards,

Byron Campen

Hi,

 

I’m using the latest revision from the SVN head, and I’ve got an access violation occurring consistently in Data.cxx.  I’ve attached a screen shot of the debugger at the point of the crash.

 

All I do to generate the crash is make/answer/hang up a few calls.

 

As you’ll see in the screen shot, I’m using Windows.  I’m also using DUM.

 

I didn’t have this problem until I updated a day or so ago…  I think prior to this update I was using a pretty old revision (probably from late August).

 

From the svn log it looks like there were some signed/unsigned changes to the hash stuff in Data…  wonder if that could be the cause?

 

Thanks,

 - Jeremy -

<resip_crash.PNG>

_______________________________________________

resiprocate-devel mailing list

 

<tid_quickwatch.PNG>