[asterisk-dev] Error msg: Asterisk is not Thread safe

[Tilghman Lesher]

On Sunday 07 December 2008 08:47:05 Russell Bryant wrote:
> On Dec 6, 2008, at 5:23 PM, Tilghman Lesher wrote:
> > This appears to be a problem on Ubuntu 8.04 and 8.10, while 7.10 is
> > okay.
> > Also, Debian Lenny does not appear to manifest this issue.  Of note
> > is that
> > Ubuntu 7.10 uses glibc version 2.6.1, while 8.04 and 8.10 both use
> > glibc 2.7.
> > It would be helpful for several people on different distributions to
> > run this
> > testcase program, and report back the distribution name, version,
> > and glibc
> > version on that machine.  My suspicion is that this is either a
> > glibc issue
> > that Debian has fixed and has not made its way into Ubuntu yet, or
> > else
> > Ubuntu introduced this problem downstream of Debian.  Knowing whether
> > other distributions on glibc 2.7 also have this issue will help us
> > isolate
> > the cause.
>
> Before we go off chasing version issues, let's take a look at the
> code.  At first glance, the test seems invalid.
>
> The test runs two threads, both tweaking the value of the same
> integer.  The two functions that run in parallel are
> test_thread_body() and test_for_thread_safety().
>
> test_thread_body() modifies the integer with only test_lock held, and
> then later, with only test_lock2 held.
>
> test_for_thread_safety() modifies the integer with both test_lock and
> test_lock2 held, and at one point, only with test_lock2 held.
>
> The problem is that one thread assumes it can modify the integer with
> only test_lock held, and the other assumes it can modify it with only
> test_lock2 held.  This could cause valid errors to occur in the test.

While you're right in that the last two tests probably don't mean anything
and should probably be eliminated, some of the test is still valid.  For the
results shown so far, I think Kaloyan's machines (Slackware, glibc 2.7) are
fine, while Patrick's machine (Fedora 10, glibc 2.9) has the indicated issue.
This would tend to suggest that the problem occurred north of the distribution
level and only certain distributions have detected the issue and fixed it
downstream.

-- 
Tilghman