-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Adding unit tests showing #3037 #7407
Conversation
All tests are passing, except the one related to code coverage (it appears to be stuck). It is possible this dirty fix is implying a few quirks on performances (It's keep ALL entities, ever tracked), so it is possible this array is pretty big and the coverage is not very happy. |
$this->_em->flush(); | ||
|
||
$articles = []; | ||
for($i=0;$i<100;$i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we reproduce this with just two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is the underlying GC implementation. With PHP 5.6, it is triggering the assert at the 85th entity. With PHP7, it's at the 100th. I think the problem is based on how the internal implementation of PHP is choosing among the available memory slots. When I try with 2, nothing happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PHP 5.6 is generally not relevant - what's important is to verify PHP 7. The fact that it acts on the very last iteration, yet we can't reduce the iteration count to just 2 means that we don't fully understand the problem yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, we're talking about how PHP is recycling memory. What if PHP is storing available memory slots into an hashmap? It would result into something more or less random, this is why having a lot of slots having the same size being available (due to recycling) is making this error to happens more frequently. This unit tests is just showing the problem, but there's too much random factor in this bug. Keep in mind that this is happening, and why: the documentation about spl_object_hash is clear: ids are recycled, thus not unique in time. My fix is pretty simple, it just ensure the UOW is still holding a reference on managed entities to avoid this pitfall. To be honest, I don't understand why we need a unit tests for this case, this is part of the way PHP is handling memory. And we DO have a unit test that is showing the issue, what a chance :). I think we do understand what is happening here, this is why the unit test is "statically working". I think this unit test should NOT be merged into the core as PHP might change the way it handles memory in the future. This fix is important as long as the UOW is using spl_object_hash (and spl_object_id for PHP7).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that object hashes are being recycled, but writing a test that relies on random optimisations is incorrect.
A better test would then be to check all array keys of all UnitOfWork
properties to make sure the object hash is gone for good from anywhere, because this particular test is otherwise too fragile.
$this->_em->flush(); | ||
|
||
$articles = []; | ||
for($i=0;$i<100;$i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is the underlying GC implementation. With PHP 5.6, it is triggering the assert at the 85th entity. With PHP7, it's at the 100th. I think the problem is based on how the internal implementation of PHP is choosing among the available memory slots. When I try with 2, nothing happen.
lib/Doctrine/ORM/UnitOfWork.php
Outdated
@@ -1622,9 +1633,10 @@ public function removeFromIdentityMap($entity) | |||
|
|||
$className = $classMetadata->rootEntityName; | |||
|
|||
unset($this->oidMap[$oid]); | |||
unset($this->readOnlyObjects[$oid]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's exactly the same issue with the read only objects: they can points at dead entities. We have to clear the oid even if the entity is not found into the identityMap.
I don't understand why the code coverage is stuck with my implementation. Is there something asserting (when using coverage only) something on the object layout of the UOW? |
Fix config template for PHPUnit >= 7.2
Update homepage
Update chat link from Gitter to Slack.
[2.7] CI: Test against PHP 7.4snapshot instead of nightly (8.0)
@Ocramius a build failed on travis because of this:
Do you want to restart the build, because as a project maintainer, I'm pretty sure you have this button, or should I bump the PR with a fake commit? |
@sandvige I've restarted the build. Could you please rebase this branch on top of |
@lcobucci Done. |
Are there any news on this? |
Yes, that would be helpful I think! I need to read the comments on this PR to see what's missing, but let's try this 👍 |
e531738
to
66c95a6
Compare
#3037