[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[schwab@linux-m68k.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[neleai at seznam dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

Ondrej Bilka <neleai at seznam dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |neleai at seznam dot cz
         Resolution|                            |INVALID

--- Comment #2 from Ondrej Bilka <neleai at seznam dot cz> 2012-12-19 21:41:08 UTC ---
On

http://www.opengroup.org/onlinepubs/9699919799/functions/erand48.html

change history shows that note on nonreentrancy was added in meantime:

Issue 5

A note indicating that the drand48(), lrand48(), and mrand48() functions need
not be reentrant

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[simon at josefsson dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

Simon Josefsson <simon at josefsson dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #3 from Simon Josefsson <simon at josefsson dot org> 2012-12-20 08:21:28 UTC ---
As noted jrand48, lcong48, nrand48, seed48, and srand48 also uses the global
variable.  The POISX description does not permit those functions to be thread
unsafe.

The title of this bug report could thus be changed to "jrand48, lcong48,
nrand48, seed48, and srand48 implementations not thread safe but POSIX says it
should be" but I don't see how to change the title in bugzilla.  If you want me
to open a new bug instead, let me know.

/Simon

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[neleai at seznam dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

--- Comment #4 from Ondrej Bilka <neleai at seznam dot cz> 2012-12-20 12:11:58 UTC ---
Sorry that I mistaken erand48 for drand48.

Note that there is a GNU extension reentrant functions drand48_r ...

Function lcong48 changes a,c in x_{n+1}=a*x_n+c mod 2^48 congruence formula. 
These are saved in __libc_drand48_data

Then erand48... read only these a,c from __libc_drand48_data.

There is indeed a race between lcong48 and *rand48 but it is mostly harmless.

Only thing that can go wrong is that when lcong48 with a',c' is called then
some seed will be updated according to formula x_{n+1}=a'*x_n+c . As then seed
is nondeterministic because both x_{n+1}=a*x_n+c , x_{n+1}=a'*x_n+c' are valid
updates.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2012-12-20 22:52:25 UTC ---
Can you clarify whether there is actually a bug here? POSIX says:

  The drand48(), lrand48(), and mrand48() functions need not be thread-safe.

If you're claiming erand48, jrand48, and/or nrand48 also have thread-safety
problems, please clarify that and explain what the problem is.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[simon at josefsson dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

--- Comment #6 from Simon Josefsson <simon at josefsson dot org> 2012-12-21 08:12:50 UTC ---
(In reply to comment #5)
> Can you clarify whether there is actually a bug here? POSIX says:
> 
>   The drand48(), lrand48(), and mrand48() functions need not be thread-safe.
> 
> If you're claiming erand48, jrand48, and/or nrand48 also have thread-safety
> problems, please clarify that and explain what the problem is.

The problem should be completely described if you read the first two posts in
this report.

To summarize the current state:

* drand48, lrand48, mrand48 need not be thread-safe.
* erand48, jrand48, lcong48, nrand48, seed48, and srand48 ought to be
thread-safe, as far as I understand.
* The erand48, jrand48, lcong48, nrand48, seed48, and srand48 functions appears
to be thread unsafe in glibc, since they use a global variable.

The links into git posted in the first post (3 years ago) still works, if you
want to read the code.

/Simon

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=10320

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> 2012-12-21 20:35:33 UTC ---
I think what you're saying is that srand48, seed48, and lcong48 are modifying
data in non-thread-safe ways, and that erand48, jrand48, and nrand48 are using
some of that data (the part set by lconf48) in non-thread-safe ways. Is this
correct?

The issue seems rather minor to me. srand48 and seed48 have no place in
multi-threaded usage at all; they only set the state for functions which are
not thread-safe anyway. lcong48 does set state that's used by the thread-safe
functions, but even if it did modify this state in a thread-safe way, calling
it at the same time random-number-generating functions are in use would have
unpredictable results.

Considering that it would be prohibitively expensive to make the thread-safe
random number interfaces perform locking to access the state set by lcong48, I
think the right approach to this issue is to open a bug report with the Austin
Group. It seems to me that failure to list srand48, seed48, and lcong48 as
non-thread-safe was just a mistake, not an intentional feature requirement on
implementations.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[jackie.rosen at hushmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10320

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #8 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[schwab at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=10320

Andreas Schwab <schwab at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jackie.rosen at hushmail dot com   |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=10320

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/10320] New: erand48 implementation not thread safe but POSIX says it should be

[simon at josefsson dot org]

POSIX specification for erand48:

http://www.opengroup.org/onlinepubs/9699919799/functions/erand48.html

It doesn't say the function may be non-reentrant, which IIUC, means it should be
thread safe.  However the implementation of erand48 does use a global variable:

http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/erand48.c;hb=HEAD

The variable is __libc_drand48_data and is defined in:

http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/drand48-iter.c;hb=HEAD

I can't find anyplace where it is made thread-local, so I'm assuming it is a
real global variable.

As far as I can tell, there is no requirement in the specification that erand48
update the global drand48 state.

-- 
           Summary: erand48 implementation not thread safe but POSIX says it
                    should be
           Product: glibc
           Version: 2.11
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: simon at josefsson dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=10320

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/10320] erand48 implementation not thread safe but POSIX says it should be

[simon at josefsson dot org]

------- Additional Comments From simon at josefsson dot org  2009-06-23 20:10 -------
By reading code, jrand48, lcong48, nrand48, seed48, and srand48 also uses the
variable __libc_drand48_data so may be subjec to the same concern.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10320

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.