https://bugzilla.wikimedia.org/show_bug.cgi?id=20036
Juliano F. Ravasi <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from Juliano F. Ravasi <[email protected]> 2009-09-04 03:06:22 UTC --- I was discussing this yesterday with Tim on IRC. The "fix" is much simpler than that (and much more secure) the real problem is in Parser::__destruct(): 154 function __destruct() { 155 if ( isset( $this->mLinkHolders ) ) { 156 $this->mLinkHolders->__destruct(); 157 } 158 foreach ( $this as $name => $value ) { 159 unset( $this->$name ); 160 } 161 } There is no need to call LinkHolderArray::__destruct() in line 156, since it will be unset() anyways in the following loop. In fact, probably the whole function is needless, but the doc comment says something about circular references... so I dunno. PHP does reference counting and its garbage collector also handles cycles. It will call __destruct() automatically if, and only if, the reference count drops to zero. In fact, this code will call LinkHolderArray::__destruct() twice under almost all conditions. If lines 155-157 above are erased, this specific issue will be solved. The problem is that when the cloned parser dies, the call in line 156 destroys the LinkHolderArray that was shared between both the clone and the original. I suggest these lines be removed (which will also resolve this bug), but not intending to promote cloned Parser usage (that as Tim explained, it is deprecated), instead because the code is really really unnecessary, and does something hardly justifiable, PHP documentation says that __destruct() is a magic method that is called automatically, and doesn't endorse manually calling it: http://br2.php.net/manual/en/language.oop5.decon.php#language.oop5.decon.destructor So, would it be possible to reconsider this bug, but with this different fix above? In my case, I fixed my extension to use Parser::recursiveTagParse() conditionally (when included) and the global $wgParser when not including and it is known to be safe. I also had to avoid and work around some MW functions that destroys the state of the global parser (wfMsgWikiHtml(), wfMsgExt() with 'parse' option, etc.). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
