I found the weirdest bug in Linux today.
Some 'if' statements may randomly return true or false.
I was banging my head thinking I was doing something wrong, but no.
If you put a boolean expression in a constantly running while loop, it may randomly switch between true and false.
How is this unacceptable?

>>106166723 (OP)
works on my machine

>>106166723 (OP)
Buy a CPU that has in-built error correction from space radiation, dumbass.

>>106166723 (OP)
What's your shell?

what? you should probably run memtest86

>>106166761
bash

>>106166779
I found the cause of this, it's clearly a software bug. It takes about 1 second to switch to false lol

>>106166805
..........whats the cause then? why are you showing us how long it takes?

>>106166723 (OP)
>>106166805
Post your code, anon. Anyone can echo TRUE 30 times and then echo FALSE.

>>106166723 (OP)
all of that stupid screenshot and 0 actual code. you're a troll until you prove it with code.

>>106166907

#!/bin/bash

set -euo pipefail

{
while true; do
if ! ldconfig -p | grep -q 'libc.so.6'; then
echo "FALSE"
exit 1
else
echo "TRUE"
fi
done
}

Wonder how old this bug is

>>106166723 (OP)
(you) issue

>>106166951
Oh shit. Use it to get root, anon.

>>106166951
It must be a scheduling error that causes IO clobber or grep/ldconfig failing. One test ran for 400 iterations another 83

it's this
>ldconfig -p | grep -q 'libc.so.6'
you can use a different shell and get the same exit. it's not bash and you can strip the program to a basic loop with no tests and still get the result.

>>106166723 (OP)
>Some 'if' statements may randomly return true or false.
>>106166951
>if i smash ldconfig in an endless loop with no break, at some point it will cut the output
Don't you think those are two very different "bugs" you got here?
Don't you think that you yourself should be able to narrow your issue down significantly?

This is not your personal support board where people solve your problems for free if you just act retarded enough.
sage

>>106166951
great catch! it is actually a very well-known bug across many different operating systems and informational systems at all - PEBKAC. you should definitely email about this problem to Torwalds, Stallman and Musk, they will give you a million dollars

>>106167113 (me)
actually it's 'pipefail -e' exiting when the pipe fails.

>>106166951
The behavior you're observing (the script returning TRUE many times before eventually exiting with FALSE) is due to a combination of factors in your script's design and how ldconfig works. Let me explain why this happens:

ldconfig -p performance: The ldconfig -p command (which prints the cache) is relatively expensive to run in a tight loop. It has to read and process the entire library cache each time.

Race condition: There's a small chance that between checking the library cache and the next check, the cache could be temporarily unavailable or in a state where libc.so.6 isn't found. This becomes more likely the more times you run the check.

set -e behavior: With set -e, if any command fails (including grep not finding a match), the script will exit. However, in your case, you're explicitly handling the grep failure with if !, so that's not the immediate issue.

Pipe behavior with set -o pipefail: The more likely explanation is that after many iterations, one of the commands in the pipeline (ldconfig -p | grep -q) fails in a way that triggers the pipefail. For example:

ldconfig might fail to access the cache due to system load

The pipe might break due to resource constraints after many iterations

System resource limits: After 80+ rapid iterations, you might be hitting some system resource limits (file descriptors, memory, etc.) which could cause one of the commands to fail.

>>106167122
The while loop is just an example. I was making a script that checked for a library once, and every time it was executed (once, not in a loop) it gave different results.

>>106167186
remove the set part. why did you even add that? it can't be your default for every script.

>>106167186
Oh, so
>ldconfig intermittently fails on my machine! Why is this?
That's all you had to write in your OP instead of jerking yourself off on finding le obscure bug

>>106167176
I tried putting tee into the pipe and every time it fails the output of ldconfig -p is incomplete and cut at the same spot mid-entry. pretty suspicious

>>106167176
>There's a small chance that between checking the library cache and the next check, the cache could be temporarily unavailable or in a state where libc.so.6 isn't found.
wait wat why? not op

my thread is
>>106167222
please bmup it

but literally why does linux do that? this is highly disconcerting, is it also bsd?

>>106166951
I've been running it in a loop and nothing has happened.

>>106167804
ran it for 300,000 iterations before ^C-ing it. Your shit is broke or retarded or something.

declare -i x=0
while ldconfig -p | grep -q 'libc.so.6'; do
echo $(( x++ ))
done
echo FALSE


simplified it a bit though. idk what to tell you. should be functionally similar sans the counter vs the TRUE print.

The absolute state of troonix

>>106168030
watch, this comment will be deleted by butthurt linux users

This works:
#!/bin/bash
set -euo pipefail

{
while true; do
if ! ldconfig -p | grep 'libc.so.6' >/dev/null; then
echo "FALSE"
exit 1
else
echo "TRUE"
fi
done
}

>>106168943
Why echo at all? just print when it fails ;3

This also works:

#!/bin/bash
set -euo pipefail
trap '' PIPE
{
while true; do
if ! ldconfig -p | grep -q 'libc.so.6'; then
echo "FALSE"
exit 1
else
echo "TRUE"
fi
done
}

#!/bin/bash
set -euo pipefail

{
while true; do
if ! (trap '' PIPE; ldconfig -p | grep -q 'libc.so.6'); then
echo "FALSE"
exit 1
else
echo "TRUE"
fi
done
}

Another one:

#!/bin/bash
set -euo pipefail

{
while true; do
if ! { ldconfig -p || true; } | grep -q 'libc.so.6'; then
echo "FALSE"
exit 1
else
echo "TRUE"
fi
done
}

One more:

#!/bin/bash
set -euo pipefail

{
while true; do
if ! grep -q 'libc.so.6' < <(ldconfig -p); then
echo "FALSE"
exit 1
else
echo "TRUE"
fi
done
}

>yet another nothingburger
Yawn.

>>106169218
I like this one the most.

>>106166951
what makes you think the "IF" itself is the problem and not the condition dumb jeet

>>106168030
>>106168036
Kek, mad.

>>106171645
Good morning saar. The Linux is broken.
Brahmin use Python.

Initially I was making a script that would check for a libstdc++ 32 bit library with ldconfig instead of doing long "find /usr -name ..."
Here it fails even faster and just sometimes prints false. There's no heavy load for scheduler or anything.

#!/bin/bash
set -euo pipefail

declare -i x=0
while ldconfig -p | grep -q 'libstdc++.so.6 (libc6)'; do
echo $(( x++ ))
done
echo FALSE

>>106172739
What's ldconfig actually outputting when the loop breaks?

>>106166951
This is exactly one of the pitfalls of using 'set -o pipefail'. grep will early exit as soon as it finds the first instance of 'libc.so.6', however, ldconfig might not have finished writing all of its output to the pipe, causing a SIGPIPE to be raised when it tries to write the next chunk. 'pipefail' will just make the entire pipe fail with the exit code of the first command that failed, thus terminating your loop.

this is why i just use Powershell

>>106167176
Thank you ChatGPT

This fucking ldconfig is printing the most recently shared libraries that have been cached.
There's no reason you can expect any particular library to ALWAYS be in there. What are you doing?

>>106171619
Me too.