Re: sed oddity
>>>>> "roro" == roro <rossius@hrz.tu-chemnitz.de> writes:
>> The freshly built sed (invoked with ./sed) did the right thing.
>> Don't know why I tried /bin/sed again, to my surprise it was
>> working too!!!
roro> Does it mean you cannot reproduce the error anymore with the
roro> old sed?
Maybe when I run gcc's configure again after running and shutting down
X but I won't do that before gcc-2.7.2-3 is out (and I've got some
sleep).
roro> That may be a hardware error or a glitch in the kernel 1.3.50.
If it's a memory error, an even number of bits must have failed (4Mx9
SIMMs) or the parity logic is stuck - but then the error should show
up not only with sed.
>>>>> "Robert" == Robert Leslie <rob@advantage.org> writes:
Robert> This may be related to a problem I had with 1.2.13 <
Robert> kernels < 1.3.56. I believe it may be/have been a kernel
Robert> bug.
Robert> If a program is run and then its image is changed on disk,
Robert> sometimes the next time it is run it will dump core. For
Robert> example:
[...]
Robert> I haven't had any problems since I upgraded to 1.3.56.
Although /bin/sed hasn't been changed I'll try upgrading to the newest
kernel (1.3.57 afaik).
>> $ ls -l /bin/sed sed-2.05/sed
>> -rwxr-xr-x 1 root root 53993 Dec 1 21:10 /bin/sed
roro> A sed produced on this day was linked before the public
roro> libc.so.5.2.1[68]. An incompatibility is remote possible.
roro> This should be reproducible.
The error is intermittent and such an incompatibility should show up
with other programs too - or is there anything particular with sed?
Thanks for your comments
Siggy
--
email: bsb@uni-muenster.de // programmer/*nix admin for hire
bsb@beck.westfalen.de \\ Opinions are strictly my own,
bsb@beck.westfalen.sub.com \\ everything else is GPLed
voice: +49-251-8619-99 \\
Mime(RFC1521) encoded messages welcome \\ http://coming.soon/
Reply to: