On Tue, 2009-09-22 at 15:06 -0700, Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Robert Noland wrote: > > I guess that I am still trying to understand the original bug... The > > demo program that was included in the bug report seems to work fine > > here, unless I don't know what the output *should* look like. It seems > > to work both before and after this change on FreeBSD. FWIW, we use mesa > > glut, not freeglut. > > > > balrog% ./opengl-demo > > These numbers are random > > 1219944491 > > 1580682328 > > 7689659 > > 391079993 > > 1581482531 > > 571799598 > > 246523261 > > 820492564 > > 1026025761 > > 121279717 > > IRQ's not enabled, falling back to busy waits: 2 0 > > > > These numbers are not > > 386222616 > > 1547925878 > > 1373331788 > > 433122960 > > 1675509037 > > 327321748 > > 1590998669 > > 1595741086 > > 1844648666 > > 1936201370 > > I believe that running the test multiple times will generate the same > output after "These numbers are not". That's the bug. The code calls > HASH_RANDOM_INIT with a constant value. If HASH_RANDOM_INIT modifies > the global random number generator state (e.g., by calling srandom), > applications will get a predictable random number sequence after calling > into GLX... whether they want it or not.
Well, I don't have a log of the output without my patch... But, with my patch this is not the case. Running the demo multiple times produces different values. If it is of interest, I can revert the patch that broke the build and re-examine the output before any of these changes. Is it possible that the real issue is with freeglut? balrog% ./opengl-demo These numbers are random 1272970576 1584379418 2015139173 479483774 1325146074 177162681 1160844825 430040780 1412917305 26976609 IRQ's not enabled, falling back to busy waits: 2 0 These numbers are not 276817946 1029639020 719781614 594202947 969971679 765644576 466376008 66254906 1149675996 1694092713 balrog% ./opengl-demo These numbers are random 1273004190 1846269 965472025 301887443 1465880287 1117585225 1362899913 1198258889 35505857 1893968380 IRQ's not enabled, falling back to busy waits: 2 0 These numbers are not 1923946826 1113031703 2141266951 742689031 1199587653 893205935 1201457015 99318364 648950029 1981177937 balrog% ./opengl-demo These numbers are random 1273020997 284321518 440638451 1286831101 462505570 1587796497 1463927457 508626120 1494283780 1753722442 IRQ's not enabled, falling back to busy waits: 2 0 These numbers are not 600027619 80986221 1778267796 816932073 1314395640 2030728438 495255695 115850093 1472328869 2124720549 balrog% robert. > The available choices for fixing the bug seemed to be: > > 1. Use our own random number generator that doesn't modify the global > state. > > 2. Just don't call srandom, but use random anyway. This also modifies > the global state and could break other applications. This seems > unlikely, but it is possible. > > 3. Use a system random number generator that doesn't modify the global > state. > > I picked option 3. Option 2 was my second choice. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkq5SnoACgkQX1gOwKyEAw/H6ACeNo9DP7wTYMLecSA+z0FAUPRr > oewAnRiR4KTaq+izFYGNreYzaY6Et1Ox > =ueET > -----END PGP SIGNATURE----- -- Robert Noland <rnol...@2hip.net> 2Hip Networks ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
