Fixed bug #61828 Memleak when calling Directory(Recursive)Iterator/Spl(T... #71

wants to merge 2 commits into


None yet

6 participants


This memory leak is the same as felipe ever fixed one:

commit af2fc62
Author: Felipe Pena
Date: Sun Mar 11 15:42:57 2012 +0000

- Fixed memory leak when calling SplFileInfo's constructor twice

The bug affect those SPL classes:

  • DirectoryIterator(".");
  • RecursiveDirectoryIterator(".");
  • FilesystemIterator(".");
  • GlobIterator(".");
  • SplFileObject('.');
  • SplTempFileObject(1);

Hi, @felipensp will you take a look at this pull request?

Thank you.


but any instance can be construct any times like:


so does other magic methods, should we forbid user-land magic method calling?


It seems that constructor did create new instance when calling __constuct();

$x = new DirectoryIterator(".");
$y = $x;

var_dump($x === $y); // true


You should not call __construct() directly, you should use new for that.


It more likely state changing but not feature changing eg: $x->setProp($value)
what do you think?

"you didn't understand my point, I mean, a object should be a
instance of a class(like a person to people), and it should not
change its features(like a sex of a person, yeah, I know there is
transsexual operation in our world, but please.)."

@smalyshev yes it's wrong to do that, but users can do that way, so a simple check would be fine to prevent memleak.
or like @php-pulls (I don't know your id, sorry) said: prevent user do that is another way to prevent it.


I agree with @reeze that this should be fixed. PHP does not prevent anyone from explicitly calling the constructor after the object was already created. Sure, you probably should not do it, but doing it should not leave you with a memleak.


In user land script. he can do some work like db connection initialization in __constructor.
if he call constructor explicitly, the programmer himself is responsible for resource free.

But in SPL, SPL should responsible for it and free the resource .


I've tested all PHP classes with direct constructor calls (using my fuzzer) and just got those memleaks from some SPL classes at the moment. So I guess it's ok to fix that case, just like I did for other class.



this patch makes sense.

Internal classes should be as robust as possible, they should not rely on "best-usage" principles from userland code.



thanks. this patch need to be improved to handle certain cases provided by laruence, I will update it later.


Hi, guys:
I've udpated the patch. add test case udpated too.
the commit fixed: string convertion will segfault when the second construct failed by thrown exception(catched) and other memleaks.


@reeze reeze closed this Sep 6, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment