bsmither

This is very interesting information and I am grateful for the time you've taken to explain the situation. Thank you!

Another experiment with a 8GiB file has these results: PHP did not time out. Even though max_execution_time is set to 60 seconds, it took 66 seconds for the entire process to finish (this function and and a few milliseconds of additional work elsewhere). The web server did time out waiting for PHP. Using NGINX where the default request timeout is 60 seconds, the result was a 504 Gateway Time-out. PHP's current memory allocation jumped from 3MiB to 12MiB at the point where md5_file() executed. Watching the drive activity light on the server box showed continuous activity for approximately 65 seconds. Followed by a brief blip for housekeeping. So, I can surmise that PHP's md5_file() reads the file in chunks - perhaps 8-9MiB per chunk - but unknown if the file fits completely in memory, then that is what will happen.

PHP 7.4.2 is given 256M as memory_limit. I am giving a 370MB file to md5_file(). I get a hash with no errors. Is PHP loading the entire file into memory, all at once, to process it? If so, is there then a practical limit to the size of the file without eventually causing an out-of-memory situation?

I wouldn't know what to look for when searching PHP's bug tracking system. That's why I asked here - maybe there is someone here who is far, far more into understanding the innards of PHP who could definitely say the extra line endings is a bug, and whether or not it is even directly associated with print_r(), or if the extra line endings were coded into the PHP source elsewhere and its appearance in print_r() is a knock-on effect.

After switching from PHP 5.3 on Windows Server 2003 to PHP 7.4.3 on Linux Mint 19.3 (Tricia Cinnamon), I find that the output of print_r() has changed. If we look at the documentation (https://www.php.net/manual/en/function.print-r.php), the provided example output is as it was on my earlier machine: <pre> Array ( [a] => apple [b] => banana [c] => Array ( [0] => x [1] => y [2] => z ) ) </pre> However, on the second machine, the output is: <pre> Array ( [a] => apple [b] => banana [c] => Array ( [0] => x [1] => y [2] => z ) <blank line> ) </pre> Note the unexpected new line after each recursed array's closing parenthesis. The new line is not present after the outermost array closing parenthesis. Also to note, there is a newer version of XDebug installed. My question is: Is this a bug? (Follow-on question: if possible to determine at which version the output changed, what version would that be?) This difference is causing existing code to not be able to correctly parse that output.

I installed it and created a survey. This was a few years ago. (My client, who I was researching a solution for, decided to go with a different application.) I haven't explored LimeSurvey any further since then.

Spreadsheet? LibreOffice Calc can publish to HTML.

And this: https://github.com/illuminate/database/commit/34ae98bd9d942cbf93ff32627b0d4f093b092ba4

The change is in the Github from two years ago: https://github.com/illuminate/database/commit/5dc6c29463ef5245f6e4d91501a7d8aac9d30df1

The $query from $this->getQuery() does not have a valid - as of PHP 7.2 - property. Prior to PHP 7.2, the result of count() with an invalid parameter would have been misleading (a 0 or 1). Suggest verifying if this package has been updated to work with PHP 7.2.

"I repeat the same process by going to his sponsor and his sponsor..." Unlimited looping needs a calculated release. In your table, user2's sponsor is user2. (Typo?) This could create an inescapable loop. I like the query above, but the sponsor tree needs a sort so that the LIMIT 1 will be the closest ancestor.