[reSIProcate] Issue with getRandomHex()

[Scott Godin]

Oh multiple processes - interesting - we use the pid to seed the random
number generator that you would think would avoid that issue.

Scott


On Mon, May 12, 2014 at 2:28 PM, Yannick Guay <yannick.guay at gmail.com>wrote:

> Hi Scott,
>
> it seems all 18 rutil/test/test* tests get executed successfully. This is
> no surprised to me as I had previously put similar tests code in my project
> in order to check for this.
>
> The way the API gets hammered in my project is really different than what
> the unit tests is doing in which a call generator triggers multiple
> processes which simultaneously generate an INVITE to a single B2BUA. This,
> as a consequence, makes Random::getRandomHex(8) method get hit multiple
> times. This issue can be reproduced 100% of the time.
>
> I will come up with a snippet of code that clearly demonstrates the issue
> and post it here. In the mean time feel free to comment on the issue.
> best regards,
> -Yannick Guay
>
>
>
>
> 2014-05-10 10:41 GMT-04:00 Scott Godin <sgodin at sipspectrum.com>:
>
> Hi Yannick,
>>
>> Thanks for keeping us posted about your findings.  I'm still baffled why
>> others aren't seeing this, when your test platforms are pretty standard.
>>  Out of curiosity - does rutil/test/testRandomHex show that there is a
>> uniqueness issue?
>>
>> Daniel Pocock - Have you seen anything like this on your *nix platforms?
>>
>> Scott
>>
>>
>> On Fri, May 9, 2014 at 2:17 PM, Yannick Guay <yannick.guay at gmail.com>wrote:
>>
>>> Hi Scott,
>>>
>>> I made more testing recently, trying to isolating the problem a little
>>> more. The first thing I tried was to execute the same set of tests on a
>>> different platform (Debian 6.0.6 64bit) and I'm seeing the exact same
>>> problem.
>>>
>>> I will conduct more testing next week and, as well, I will try the patch
>>> I suggested last week on Debian. In the interim please let me know if you
>>> have any comments.
>>>
>>> FWIW: our system will be deployed on ESXI so all tests are conducted on
>>> VMWare, not bare metal.
>>>
>>> best regards,
>>> -Yannick Guay
>>>
>>>
>>>
>>> 2014-05-01 10:45 GMT-04:00 Yannick Guay <yannick.guay at gmail.com>:
>>>
>>> Hi again,
>>>>
>>>> A colleague here pointed me at another API which I tried (srand48 and
>>>> lrand48, also part of standard library) and that seems to work better for
>>>> me. The replacements exist on all modern Unix platforms (Solaris, Mac OS X,
>>>> FreeBSD, Linux).
>>>>
>>>> Although Evan Jones describes this as not being thread safe (read this
>>>> post here <http://www.evanjones.ca/random-thread-safe.html>), this
>>>> could be a good starting point to work around the issue. I have only tested
>>>> my scenario where the DUM is generating new transaction id and I've had
>>>> success with it. I believe that's because all request for random numbers is
>>>> coming from a single thread.
>>>>
>>>> I'm aware that not everybody is suffering of this but I'm confident
>>>> it's solving a real issue so I'm posting the patch for review. Perhaps we
>>>> should confirm whether it is safe to use by running a wider range of tests?
>>>>
>>>> thanks,
>>>> -Yannick
>>>>
>>>>
>>>> 2014-05-01 8:48 GMT-04:00 Yannick Guay <yannick.guay at gmail.com>:
>>>>
>>>> Hi Scott,
>>>>>
>>>>> We've started using 1.9 as of  last week on Centos 6.3. I've tested
>>>>> the Random class separately and made it issue 20 8 byte long values without
>>>>> a problem, I can hardly identify what could cause this? I will keep
>>>>> investigating on my side and would be very thankful if anybody can give any
>>>>> sort of recommendation on how to get that fixed.
>>>>>
>>>>> thanks,
>>>>> -Yannick
>>>>>
>>>>>
>>>>> 2014-04-30 17:02 GMT-04:00 Scott Godin <sgodin at sipspectrum.com>:
>>>>>
>>>>> Hi Yannick,
>>>>>>
>>>>>> What resip release are you using?  There was quite a bit of work put
>>>>>> into the Random.cxx class a couple years ago to ensure random number
>>>>>> generator is seeded automatically for each thread (see
>>>>>> Random::initialize()).  If you are on an older release you may want to
>>>>>> compare your version Random.cxx with the latest one from SVN.  Note also -
>>>>>> there is a lot of platform depend code branches in this init logic, so your
>>>>>> platform may be playing a role here.  What platform are you using?
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 30, 2014 at 3:50 PM, Yannick Guay <yannick.guay at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I ran into an issue with DUM generating same transaction id several
>>>>>>> times when my b2bua is handling multiple simultaneous calls.
>>>>>>>
>>>>>>> I'm using DialogUsageManager::makeInviteSession() which generates a
>>>>>>> proper branch parameter for the outgoing call but when it's time to send
>>>>>>> them down to the stack the branch parameter is set again
>>>>>>> by DialogUsageManager::send() (line 1036 or so), but same value gets reused
>>>>>>> for all calls. As a result, only the first call gets out of my gateway, all
>>>>>>> other subsequent calls are considered bad and eventually get dropped by
>>>>>>> TransactionState.
>>>>>>>
>>>>>>> Here is the line that I'm finding in log files.
>>>>>>> 2014-04-30T15:12:27.854-04:00 Warning - B2BUA TU sent us a duplicate
>>>>>>> INVITE: fix this!
>>>>>>>
>>>>>>> My knowledge of srandom and random is rather limited but I trust
>>>>>>> after giving it a seed, then it should always hand off unique values?
>>>>>>>
>>>>>>> Any Ideas what I'm doing wrong?
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> -Yannick Guay
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> resiprocate-devel mailing list
>>>>>>> resiprocate-devel at resiprocate.org
>>>>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140512/69aec464/attachment.htm>