Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tests for function/class declared in a file included repeatedly #7563

Closed
wants to merge 1 commit into from

Conversation

mvorisek
Copy link
Contributor

@mvorisek mvorisek commented Oct 6, 2021

Memory leaks are fixed in PHP 8.1 /w opcache.

Add tests to check if memory does not increase on repeated include so code can rely on it.

@cmb69
Copy link
Member

cmb69 commented Oct 6, 2021

Memory leaks are fixed in PHP 8.1 /w opcache.

So the tests need to be skipped if OPcache is not enabled.

@mvorisek
Copy link
Contributor Author

mvorisek commented Oct 6, 2021

Memory leaks are fixed in PHP 8.1 /w opcache.

So the tests need to be skipped if OPcache is not enabled.

yes

@cmb69
Copy link
Member

cmb69 commented Oct 6, 2021

Even if the extension is loaded, it may not be enabled.

@mvorisek mvorisek force-pushed the include_repeat_leak branch 2 times, most recently from 08aed71 to 1fc627a Compare October 6, 2021 12:00
@mvorisek mvorisek force-pushed the include_repeat_leak branch 2 times, most recently from 84e0695 to 2f0d35c Compare October 6, 2021 14:20
@mvorisek mvorisek requested a review from cmb69 October 6, 2021 16:49
Copy link
Member

@cmb69 cmb69 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! Frankly, I'm not sure whether it makes sense to have these tests, but they don't seem to hurt either.

Zend/tests/repeated_include/anonymous_class.phpt Outdated Show resolved Hide resolved
Copy link
Member

@cmb69 cmb69 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is okay for me.

Copy link
Member

@nikic nikic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Including files more than twice is unnecessary.

@mvorisek
Copy link
Contributor Author

mvorisek commented Oct 8, 2021

Including files more than twice is unnecessary.

This is not true, for ex. in PHP 7.4 /w opcache I needed 82 iterations for anonymous_class.phpt (on other platform, I needed 143 iterations), full test output:

--TEST--
Repeated include must not increase memory - anonymous class
--SKIPIF--
--FILE--
Increased memory detected: 65536 B (82 iteration)

I belive this is because some hashmap resize was needed and these tests accounts for that. On linux, the tests are fast, on Windows, include is slower but the tests accounts for that to keep them fast.

@mvorisek mvorisek requested a review from nikic October 8, 2021 18:12
@mvorisek
Copy link
Contributor Author

@nikic is the iteration count in the test with this reasoning enoughly justified?

@mvorisek
Copy link
Contributor Author

mvorisek commented Feb 1, 2022

@cmb69 can these tests be merged?

@cmb69
Copy link
Member

cmb69 commented Feb 1, 2022

I think @nikic is referring to our builds using MSan (and similar) which should be able to detect the memory leaks. As such, neither including more than twice should be necessary, nor checking the memory usage manually.

@mvorisek
Copy link
Contributor Author

mvorisek commented Feb 1, 2022

I do not think so, this is not related to memory leak of an object instance, but instead of a anonymous class DEFINITION. Correct me if I am wrong, but I do not think this is checked in MSan.

Also, as the used memory increase can be observed with much higher include count only, I belive the only way to test it reliably is to test is with reasonable count which caused issues in the prePHP8.1 versions.

@mvorisek
Copy link
Contributor Author

The importance of more than several iterations can be seen in #8078 to detect memory leaks such op_array arena allocation.

@mvorisek mvorisek force-pushed the include_repeat_leak branch 2 times, most recently from d66436c to 2cf0a67 Compare April 12, 2022 12:30
@Girgias
Copy link
Member

Girgias commented Apr 27, 2022

Why is this targeting 8.1 and not master?

@mvorisek
Copy link
Contributor Author

Why is this targeting 8.1 and not master?

because the memory leakage was fixed in PHP 8.1 /w opcache, thus I target the lowest possible branch to assert that behaviour since this version

@mvorisek
Copy link
Contributor Author

Can this PR be merged? It asserts no memory leaking which is quite important feature user may rely on.

@mvorisek
Copy link
Contributor Author

I would like to summarize this PR:

  • /w opcache repeatedly included file does not leak (since PHP 8.1, hence the target branch)
  • /wo opcache there are some leaks (as @Girgias advised above, dynamic xfail is emit)
  • originally the memory leak was detectable with tens or several hundreds iterations, so the tests test many iterations, but they are fast, they complete below 1 second (@nikic originally said 2 iterations are enough, but many iterations are needed)

Given these facts, I would like to have this PR merged as I belive all feedback was addressed.

@mvorisek
Copy link
Contributor Author

@nielsdos @iluuu1994 are you ok to merge these tests? And can they target PHP-8.1?

@nielsdos
Copy link
Member

I don't know if all the variants are truely necessary, since it is unrelated to dynamic definitions. Other than that I guess testing that opcache doesn't leak this probably makes sense.
Since there is no fix here I believe the policy is to put it in master.
Idk what Ilija thinks.

Copy link
Member

@iluuu1994 iluuu1994 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's too little context to this PR. It's unclear what fix this is trying to test, and whether that's already covered by the tests added at the time.

$m = -1;
$mDiff = -1;
$mPrev = 0;
for ($i = 0; $i < (PHP_OS_FAMILY === 'Windows' ? 1_000 /* include is slow on Windows */ : 20_000); $i++) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If 1,000 iterations are enough for Windows, why use 20,000 on others?

Copy link
Contributor Author

@mvorisek mvorisek Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On some systems I needed several hundreds iterations to trigger a memory increase. So I figured 20k is good count to test this extensively and keep it still fast (<1 second), in Windows, the repeated include is quite costly, so on Windows, only 1k iterations are tested in hope it will be enough and to keep the test/CI still fast.

Zend/tests/repeated_include/anonymous_class.phpt Outdated Show resolved Hide resolved
@iluuu1994
Copy link
Member

@mvorisek

There's too little context to this PR. It's unclear what fix this is trying to test, and whether that's already covered by the tests added at the time.

This hasn't been answered yet. Do you have a link to the original commit that fixes what we're testing here?

@mvorisek
Copy link
Contributor Author

The explamation is in the tests titles. I do not think this is tested now, thus this PR to assert no memory increase on repeated include with opcache. Once fixed for /wo opcache, SKIPIF should be removed.

@mvorisek
Copy link
Contributor Author

I hope we can agree memory leaks are not wanted. The current impl. with opcache does not leak, so we test/assert it. For non-opcache we xfail the tests now. I hope this makes sense.

@mvorisek
Copy link
Contributor Author

@iluuu1994 can this PR be merged please? It asserts the expected behaviour - currently with opcache only - discussed in #11975

@derickr
Copy link
Member

derickr commented Sep 28, 2023

I'm closing this as there is no reason this should target PHP-8.1. The requested information and changes have also not been addressed.

@derickr derickr closed this Sep 28, 2023
@mvorisek
Copy link
Contributor Author

Folks, could you please tell me what I could do so that this PR gets merged? Let me know if you have any concerns

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants