Test failing in ext/fileinfo/tests/bug78987.phpt on big-endian PPC

[orlitzky]

Description

We have a report of a test failure on Gentoo at https://bugs.gentoo.org/927461 that has been confirmed in php-8.3.3. The machine in question is a big-endian Linux-6.8.1-gentoo-ppc64-ppc64-POWER9_-architected-,_altivec_supported-with-glibc2.38. The same test does not fail on a little-endian machine.

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #78987 High memory usage during encoding detection [ext/fileinfo/tests/bug78987.phpt]
=====================================================================

---- EXPECTED OUTPUT
131072   => ok
262144   => ok
524288   => ok
1048576  => ok
2097152  => ok
4194304  => ok
8388608  => ok
16777216 => ok
---- ACTUAL OUTPUT
131072   => 9175040
262144   => 9175040
524288   => ok
1048576  => 11272192
2097152  => 13434880
4194304  => 17694720
8388608  => 23986176
16777216 => 36569088
---- FAILED

It's worth mentioning that, for example, $map[131072] = 10612736 is actually bigger than 9175040.

PHP Version

PHP 8.3.3

Operating System

Gentoo linux

[ranvis]

The output of the failed test is actually from the PHP 8.2.15 test case.

php-src/ext/fileinfo/tests/bug78987.phpt

Lines 13 to 22 in c7816bf

	$map = array(
	131072 => 9113600,
	262144 => 9113600,
	524288 => 10850304,
	1048576 => 11210752,
	2097152 => 13312000,
	4194304 => 17510400,
	8388608 => 23801856,
	16777216 => 36384768,
	);

If merged with the output, it looks like a usual failure:

buf size    peak        limit       excess
131072   => 9175040     9113600     61440
262144   => 9175040     9113600     61440
524288   => ok          10850304    -
1048576  => 11272192    11210752    61440
2097152  => 13434880    13312000    122880
4194304  => 17694720    17510400    184320
8388608  => 23986176    23801856    184320
16777216 => 36569088    36384768    184320

[orlitzky]

You're right of course. I asked "does it still fail with 8.3.3" when what I should have asked is "if it still fails with 8.3.3, what is the output?"

[orlitzky]

Here are the failure numbers from 8.3.4:

---- EXPECTED OUTPUT
131072   => ok
262144   => ok
524288   => ok
1048576  => ok
2097152  => ok
4194304  => ok
8388608  => ok
16777216 => ok
---- ACTUAL OUTPUT
131072   => 10092544
262144   => 10092544
524288   => 12189696
1048576  => 12189696
2097152  => 14352384
4194304  => 18612224
8388608  => 24903680
16777216 => 37486592
---- FAILED

After b7c5813#diff-aa61bd057307acacd5b7ffd0a378bb3c42f88f5ff90cae8ebdd492c07ed96427 by @nielsdos, the new limits will be,

$map = array(
	131072 => 10612736,
	262144 => 10612736,
	524288 => 11898880,
	1048576 => 12709888,
	2097152 => 14811136,
	4194304 => 19009536,
	8388608 => 25300992,
	16777216 => 37883904,
);

With the new limits, most of the existing failures should start to pass. I think the only exception is 524288 => 12189696, since 12189696 > 11898880.

[nielsdos]

I hate that test case so much, it adds so little value and is quite flaky when we change things to ext-fileinfo.
Anyway, feel free to submit a PR updating the numbers to what you got, the increase seems reasonable and not indicative of a regression.

[orlitzky]

I hate that test case so much, it adds so little value and is quite flaky when we change things to ext-fileinfo.

Just delete it :)

This was giving me deja vu. We had a similar situation in SageMath where the test runner was given an artificial memory limit to catch tests that used "too much" memory. Except nobody knows what "too much" means, and it's platform-dependent anyway. So, whenever someone would hit the memory limit... we would just raise it. And then find someone to review the commit. And then send it off to the release manager, to eventually ship it to users. All the while, the tests are failing. Clever readers will recognize this situation as essentially that of having no memory limit, except with more steps. Anyway, it turns out it was me who finally deleted it.

I recently disabled this test in Gentoo when I remembered that SageMath issue and how much of a headache it proved to be. I'll still submit a PR with the updated numbers though since it will avoid a PHP bug report in the future.

[andypost]

Hit it again building 8.4.0_alpha2 on Alpinelinux s390x

TEST 7381/17898 [ext/fileinfo/tests/bug78987.phpt]
========DIFF========
     131072   => ok
     262144   => ok
- 524288   => ok
+ 524288   => 12709888
     1048576  => ok
     2097152  => ok
     4194304  => ok
--
========DONE========

[nielsdos]

This test is so stupid, I vote to remove this.