Re: [reSIProcate] VB: Assert in TransactionState.cxx
Here is a link to the discussion thread I was referring too:
http://list.resiprocate.org/archive/resiprocate-devel/msg06605.html
Are you building with openSSL, so that you get the crypto random implementation?
Scott
On Thu, Jul 24, 2008 at 3:28 AM, Krister Jarl <kj@xxxxxxxxxxx> wrote:
> I'm afraid they're both running in a single thread, well to be completely
> correct my application runs several threads but it's only dealing with
> creating requests in the main thread. From what I understand from the
> resiprocate code the branch-parameter is created by the call to
> makeReqeustInternal() when I call makeAck(). So the tid-part of the branch
> is final after this call?
>
>
>
> I've had a look through the posting archives but I found nothing of
> interest.
>
>
>
> ________________________________
>
> Från: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Skickat: den 18 juli 2008 16:13
> Till: Krister Jarl; resiprocate-devel@xxxxxxxxxxxxxxx
> Ämne: RE: [reSIProcate] VB: Assert in TransactionState.cxx
>
>
>
> Perhaps your app is generating random numbers from multiple threads and your
> test program isn't.
>
>
>
> From: Krister Jarl [mailto:kj@xxxxxxxxxxx]
> Sent: Friday, July 18, 2008 10:13 AM
> To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxx
> Subject: SV: [reSIProcate] VB: Assert in TransactionState.cxx
>
>
>
> Thanks for the reply!
>
>
>
> I'll have a look at the archives!
>
> I've broken out the code generating the branch and run a couple of million
> tests without running into a double. In our application this happens after
> ~100 dialogs. So I'm kind of confused here.
>
>
>
> /kj
>
>
>
> ________________________________
>
> Från: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> Skickat: den 18 juli 2008 15:48
> Till: Krister Jarl; resiprocate-devel@xxxxxxxxxxxxxxx
> Ämne: RE: [reSIProcate] VB: Assert in TransactionState.cxx
>
>
>
> Hi Krister,
>
>
>
> Sorry for the lack of responses – I've never seen this behavior, but there
> was some discussion about random number generation on some platforms a few
> months back. You may want to try a search through the posting archives and
> see if anything rings a bell:
> http://www.resiprocate.org/Searching_the_Mailing_Lists
>
>
>
> Scott
>
>
>
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Krister Jarl
> Sent: Friday, July 18, 2008 9:26 AM
> To: resiprocate-devel@xxxxxxxxxxxxxxx
> Subject: [reSIProcate] VB: Assert in TransactionState.cxx
>
>
>
> Hello again!
>
>
>
> I still haven't received any response to this so I'm rephrasing myself:
>
> Has anybody else experienced that reciprocate generates the same branch for
> different requests in different dialogs? Is it known to happen?
>
>
>
> If anybody would have the time to look at this I would much appreciate it!
>
>
>
> /kj
>
>
>
> ________________________________
>
> Från: Krister Jarl
> Skickat: den 25 juni 2008 17:28
> Till: resiprocate-devel@xxxxxxxxxxxxxxx
> Ämne: Assert in TransactionState.cxx
>
>
>
> Hi!
>
>
>
> We're experiencing some problems with resiprocate-1.2. The scenario is
> described below:
>
>
>
> Our implementation sends an INVITE which is answered with 100 Trying. After
> this we receive a 200 ok to another INVITE sent to another destination. We
> respond to this by calling createDialogAsUAC() and then makeAck(). This
> works fine in most cases (99%) but sometimes the ACK gets the same tid as
> the first INVITE. This results in an incorrect state and we get an assert at
> line 253 in TransactionState.cxx. Any ideas on what might be wrong?
>
>
>
> Please find the logs attached. Thanks!
>
>
>
> /kj
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>