On 01/10/2017 01:12 PM, Rainer Jung wrote:
Hi Dennis,
Good day fine Sir.
<snip>
Firstly, sorry for awaking what seems like a long dead cold bug but it
really isn't a "Large Files not supported" bug as opposed to just a
message that needs to be tweaked. Indeed yes this is a 64 bit build and
so off_t and size_t and going to be 64-bit sized :
I will have a look at the message "Line 345: Large Files not supported"
coming from "make check" and see whether I can tweak it ("not supported
or not needed" or similar). Due to the API used by APR I think we can't
be more precise (effectively distinguish between the two cases) easily.
Hrmmm .. in that case perhaps a more harmless message can be
constructed. Perhaps even "possible Large File support issue" but
even that is misleading. So the API hides the truth? Is that the real
issue here? Or maybe I should say protects the user from the hardware.
...
As for the blocking rand, well hrmmm, not unless I was trying to read a
ton of data from /dev/random wherein :
Devices random(7D)
<snip>
So I would expect that /dev/random may slow down but not by too much
while many other processes are running on the system and in this case
the build system is a single virtual zone inside a machine with a
number of zones. There should be plenty of data. However I have never
run a benchmark. I can certainly run a test for "blocking rand()" as
per http://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html
However I will say that the Apache 2.4.25 server seems to be running
very well with this new apr and apr-util but I am sure we can sort out
this weird test behavior. I certainly have the Sparc hardware sitting
here and can even provide the Oracle Sparc M7 tests if needed.
/dev/random can block because many server systems quickly run out of
entropy.
Do we really need a crypto grade source of random data? Because we do
have /dev/urandom also and that will feed random noise endlessly.
If you could follow my suggestions for further debugging your hanging or
Am working on it .. was interrupted by the whole "work" thing among
others. :-)
extremely long running apr "make check" (using pstack, prstat, truss as
written in the ticket), I'm sure we can find the culprit. If it is
/dev/random, we can find that in this type of debug info, if it is
something else likely we can also determine it from the three.
Could be a time to roll out Dtrace even.
Dennis
