Paul Eggert <[email protected]> wrote: > On 02/09/2012 01:35 AM, Aki Helin wrote: > > A date just got printed without issues even though > > it was matching with Grep that had been patched to crash if it tries to > > exit with 0 from the bottom of main(). > > Sounds like the bug's outside of 'grep', then.
Yes, could be that this seems to happen only with grep because a very specific timing, IO etc is required to trigger a shell bug. > I'm not observing any problems with similar loops on > three machines: > > Ubuntu 11.10 x86 grep 2.9 (bundled) AMD Opteron 1210 > RHEL 5.7 x86-64 grep 2.10 (built with GCC 4.6.2) Intel Xeon E5620 > Fedora 15 x86-64 grep 2.9 (bundled) AMD Phenom II X4 910e > > Which Atom CPU is the system using? What are the > contents of /proc/cpuinfo, and what's the output of > "uname -a"? Linux ni3 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux /proc/cpuinfo is 4x (modulo processor id) processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 28 model name : Intel(R) Atom(TM) CPU D510 @ 1.66GHz stepping : 10 cpu MHz : 1662.716 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm bogomips : 3325.43 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: > If this is a Cedar Trail Atom, you're the first guy > I know who's running 64-bit GNU/Linux on it seriously. > You're braver than I would be.... That doesn't sound good... Luckily we couldn't afford such modern processors over here. This is Pineview :) -- Aki Helin
