Bug#335105: perl FTBFS in t/op/fork
reassign 335105 kernel close 335105 2.6.5 thanks On Sun, Dec 11, 2005 at 10:24:56AM +, Andrew Suffield wrote: My bet is that it's this kernel bug: I don't know if you've been following, but it was recently discoverd that on smp, if multiple processes read from /dev/urandom at the same time, they can get the same data. Theodore Tytso posted a patch to fix this for 2.6, and someone else told me this problem has existed all the way back to 1.3. Fixed in 2.4.29 and 2.6.5. What kernel version have you got there? If it's 2.4.27 (sarge) then I think we have our problem found. Thanks Andrew, This does appear to be the cause of the problem. I tracked down the original patch which added the fork/rand test. The intent of the addition is to test rand (specifically the implicit srand on first call) rather than fork: a change in 5.8.1 to randomise hash ordering was causing an implicit call of srand when perl was started, causing a behaviour change: $ perl -le 'fork; print rand' was printing the same value twice. Re-assigning to kernel and closing. --bod -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#335105: perl FTBFS in t/op/fork
Processing commands for [EMAIL PROTECTED]: reassign 335105 kernel Bug#335105: perl FTBFS in t/op/fork Bug reassigned from package `perl' to `kernel'. close 335105 2.6.5 Bug#335105: perl FTBFS in t/op/fork 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug marked as fixed in version 2.6.5, send any further explanations to Thiemo Seufer [EMAIL PROTECTED] thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335105: perl FTBFS in t/op/fork
Andrew Suffield wrote: [snip] Hm, it is easily reproducible on SWARM, as well as on a Octane with 2 CPUs. Which probably means it is a SMP-induced race condition in fork. My bet is that it's this kernel bug: I don't know if you've been following, but it was recently discoverd that on smp, if multiple processes read from /dev/urandom at the same time, they can get the same data. Theodore Tytso posted a patch to fix this for 2.6, and someone else told me this problem has existed all the way back to 1.3. Fixed in 2.4.29 and 2.6.5. What kernel version have you got there? If it's 2.4.27 (sarge) then I think we have our problem found. 2.4.27 (sarge) on SWARM, 2.6.12 on the Octane. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335105: perl FTBFS in t/op/fork
This one time, at band camp, Thiemo Seufer said: Andrew Suffield wrote: [snip] Hm, it is easily reproducible on SWARM, as well as on a Octane with 2 CPUs. Which probably means it is a SMP-induced race condition in fork. My bet is that it's this kernel bug: I don't know if you've been following, but it was recently discoverd that on smp, if multiple processes read from /dev/urandom at the same time, they can get the same data. Theodore Tytso posted a patch to fix this for 2.6, and someone else told me this problem has existed all the way back to 1.3. Fixed in 2.4.29 and 2.6.5. What kernel version have you got there? If it's 2.4.27 (sarge) then I think we have our problem found. 2.4.27 (sarge) on SWARM, 2.6.12 on the Octane. I can reliably reproduce failures on 2.6.8-686-smp (sarge), but not on 2.6.14-686-smp (sid), just as a datapoint. So it looks like the fix for 2.6.5 was not the only change. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#335105: perl FTBFS in t/op/fork
On Sat, Dec 10, 2005 at 07:39:04PM +0100, Thiemo Seufer wrote: Andrew Suffield wrote: This doesn't look like #223110 to me - that bug is specific to signal handlers. After a closer look I agree. I just tried the test on casals against 5.8.7-6 though, and I can't get it to break (although it is still breaking on the buildd). What do you know about it? I need to duplicate the pesky thing somehow... Hm, it is easily reproducible on SWARM, as well as on a Octane with 2 CPUs. Which probably means it is a SMP-induced race condition in fork. My bet is that it's this kernel bug: I don't know if you've been following, but it was recently discoverd that on smp, if multiple processes read from /dev/urandom at the same time, they can get the same data. Theodore Tytso posted a patch to fix this for 2.6, and someone else told me this problem has existed all the way back to 1.3. Fixed in 2.4.29 and 2.6.5. What kernel version have you got there? If it's 2.4.27 (sarge) then I think we have our problem found. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#335105: perl FTBFS in t/op/fork
Andrew Suffield wrote: This doesn't look like #223110 to me - that bug is specific to signal handlers. After a closer look I agree. I just tried the test on casals against 5.8.7-6 though, and I can't get it to break (although it is still breaking on the buildd). What do you know about it? I need to duplicate the pesky thing somehow... Hm, it is easily reproducible on SWARM, as well as on a Octane with 2 CPUs. Which probably means it is a SMP-induced race condition in fork. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335105: perl FTBFS in t/op/fork
This doesn't look like #223110 to me - that bug is specific to signal handlers. I just tried the test on casals against 5.8.7-6 though, and I can't get it to break (although it is still breaking on the buildd). What do you know about it? I need to duplicate the pesky thing somehow... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#335105: perl FTBFS in t/op/fork
This is probably caused by glibc's #223110. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335105: perl FTBFS in t/op/fork
Package: perl Version: 5.8.7-7 Severity: serious According to http://buildd.debian.org/fetch.php?pkg=perlarch=mipsver=5.8.7-7stamp=1129566720file=log perl fails for the t/op/fork test on mips. I tried to reproduce it and found that the test succeeds with a probability of ~50% for a locally built 5.8.7-7 binary, and ~75% for 5.8.7-6 from unstable. Stracing with both versions succeeded always, the output showed no significant differences. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
