Created attachment 29304 [details] 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:rvnDellInc.:rn0M277C:rvr:cvnDellInc.:ct8:cvrN/A: dmi.product.name: Vostro1510 dmi.product.version: Null dmi.sys.vendor: Dell Inc. fglrx: Not loaded system: distro: Ubuntu architecture: x86_64kernel: 2.6.31-8-generic
Created attachment 29305 [details] Output of `lspci -vvnn`
Created attachment 29306 [details] Xorg.0.log
Created attachment 29307 [details] 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 attachment 29610 [details] [review] 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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.