Using glutCreateWindow() seeds RNG with predictable value

Created an attachment (id=29304)
Demo program using freeglut

Forwarding a bug report from ubuntu user Fred:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/421651

[Problem]
After calling glutCreateWindow() from the freeglut package on intel hardware, the output of rand() is the same every time the a test program is run.

[Original description]
Binary package hint: xserver-xorg-video-intel

The bug is what it says on the tin.

When glutCreateWindow() is called in the attached OpenGL program, the random number generator appears to be reseeded with a predictable number. This results in predictable output unless srand(time(NULL)) called again.

This appears to be an Intel driver specific bug; when the program was tested on an Nvidia card in a Linux distro running a similar version of freeglut there was no reseeding.

I think the bug probably is in the intel specific part of mesa. Using the test program I traced the glutCreateWindow call and added lines like
    printf("Random number 11 (fgOpenWindow): %i\n",rand());
in relevant places in the source code of the freeglut source package. glutCreateWindow() (in src/freeglut_window.c) calls fgCreateWindow() (in src/freeglut_structure.c) which calls fgOpenWindow() (in src/freeglut_window.c) which again calls glXMakeCurrent() like this:

    glXMakeCurrent(
        fgDisplay.Display,
        window->Window.Handle,
        window->Window.Context
    );

Before the glXMakeCurrent() call, rand() returns a random number, while after the call it returns the same every time.

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

$ lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

$ apt-cache policy xserver-xorg-video-intel
xserver-xorg-video-intel:
  Installed: 2:2.8.1-1ubuntu1
  Candidate: 2:2.8.1-1ubuntu1
  Version table:
 *** 2:2.8.1-1ubuntu1 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
Architecture: amd64
Date: Sun Aug 30 16:43:21 2009
DistroRelease: Ubuntu 9.10
MachineType: Dell Inc. Vostro1510
NonfreeKernelModules: wl
Package: xserver-xorg-video-intel 2:2.8.1-1ubuntu1
PccardctlIdent:

PccardctlStatus:

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-8-generic root=UUID=e183b92c-5171-4a2f-8883-fde441cfe962 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-8.28-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0~git20090817.7c422387-0ubuntu3
 libdrm2 2.4.12+git20090801.45078630-0ubuntu1
 xserver-xorg-video-intel 2:2.8.1-1ubuntu1
 xserver-xorg-video-ati 1:6.12.99+git20090629.f39cafc5-0ubuntu6
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.31-8-generic x86_64
XorgConf: Error: [Errno 2] No such file or directory: '/etc/X11/xorg.conf'
dmi.bios.date: 07/10/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A10
dmi.board.name: 0M277C
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnDellInc.:bvrA10:bd07/10/2008:svnDellInc.:pnVostro1510:pvrNull:rvnDellIn...

Created an attachment (id=29305)
Output of `lspci -vvnn`

Created an attachment (id=29306)
Xorg.0.log

Created an attachment (id=29307)
glxinfo output

It looks like this is caused by the use of srandom in src/glx/x11/glxhash.c. We can fix this by either not calling srandom or by providing our own random number generator. The GLX code always calls srandom with 0xDEADBEEF, which seems almost useless.

Ugh! That would explain some weirdness I saw a while back when debugging an app that used random numbers. Can we just get rid of the srandom() call and be done?

Created an attachment (id=29610)
glx: Use initstate_r / random_r instead of corrupting global random number state

The hash table code actually needs some random numbers. Calling random may not be safe, regardless of the srandom issue, in multithreaded applications. Using initstate_r and random_r should fix these issues.

Geir, could you test this patch?

(In reply to comment #6)
> Geir, could you test this patch?

Tested. With the patch, the test program gets new random numbers every new second, so the patch resolves the bug.

I see there is still a number of calls to srandom(0xbeefbeef) in src/glx/x11/glxhash.c , but those are probably not invoked when calling glxMakeCurrent().

(In reply to comment #7)
> (In reply to comment #6)
> > Geir, could you test this patch?
>
> Tested. With the patch, the test program gets new random numbers every new
> second, so the patch resolves the bug.
>
> I see there is still a number of calls to srandom(0xbeefbeef) in
> src/glx/x11/glxhash.c , but those are probably not invoked when calling
> glxMakeCurrent().
>

Correct. The other srandom calls are in a testing "main" function that is #ifdef'ed out.

I've pushed this patch to mesa_7_5_branch, and it will find its way to mesa_7_6_branch and master soon.