I tried older version of XAMPP (1.6.8) with:
Apache 2.2.9
MySQL 5.0.67
PHP 5.2.6
And everything was installed OK - so I guess somebody should post a PHP bug report..
MODX Staff
The problem with comparing experiences in these configurations is that it’s not just the versions of the main applications that matter, but it could be something as simple as a missing configuration switch or that the setup was compiled with some unstable or incompatible dependencies.
LOL. That’s exactly the setup that’s crashing on install for me. Actually, it’s been crashing periodically for some time, usually when I save something in the Manager.
There was definitely a nesting issue with xPDOCacheManager’s writeFile()/writeTree() functions calling xPDO->log() while xPDO->log() called writeTree() when using file-based log targets. Under certain circumstances, the writeFile() function was failing (due to file permissions and/or other potential unidentified issues), trying to log the error, and you have yourself a race condition. This was fixed this afternoon; see #XPDO-23 and #MODX-604.
I’ll be glad to be proven wrong, but I think there’s an infinite loop in the code somewhere. Both the 255 error and the MODx log contents suggest that to me.
MODX Staff
I appreciate your concern on that, but no, no infinite loops there, as every call has a maximum iterations, and generally all nested calls have the tag that called them as a parameter to prevent re-evaluating the same tag. That logic is absolutely required to implement true source order parsing.
[Update] Looked again -- processElementTags() calls processTag() and processTag() calls processElementTags().
The call in processTag() is unconditional. The call in processElementTags() depends on collectElementTags returning true. I wonder if a malformed tag might lead to an infinite loop there.
Quote from: BobRay at Jan 19, 2009, 10:30 PMI appreciate your concern on that, but no, no infinite loops there, as every call has a maximum iterations, and generally all nested calls have the tag that called them as a parameter to prevent re-evaluating the same tag. That logic is absolutely required to implement true source order parsing.
[Update] Looked again -- processElementTags() calls processTag() and processTag() calls processElementTags().
The call in processTag() is unconditional. The call in processElementTags() depends on collectElementTags returning true. I wonder if a malformed tag might lead to an infinite loop there.
MODX Staff
A negative depth argument being passed would be the same as passing the default of 0, always; this is the second line of the function:
Code like that always makes me nervous since it’s complex and appears to depend somewhat on the good behavior of processes it doesn’t control. That said, I tried and I couldn’t make it misbehave. I’d still feel better, though, if it had a test for ($depth < 0) at the top of processElementTags() since a negative maximum iterations number would just keep decrementing (though I concede that the odds of a negative $depth argument being passed are extremely slim).
$depth = $depth > 0 ? $depth - 1 : 0;
Quote from: BobRay at Jan 20, 2009, 03:17 PMA negative depth argument being passed would be the same as passing the default of 0, always; this is the second line of the function:
Code like that always makes me nervous since it’s complex and appears to depend somewhat on the good behavior of processes it doesn’t control. That said, I tried and I couldn’t make it misbehave. I’d still feel better, though, if it had a test for ($depth < 0) at the top of processElementTags() since a negative maximum iterations number would just keep decrementing (though I concede that the odds of a negative $depth argument being passed are extremely slim).
$depth = $depth > 0 ? $depth - 1 : 0;
Also, the call to processElementTags within processTag is working on the tag string itself so that you can properly nest tags and rely on the order they are being processed in. Between the recursive depth protection and parentTag protection in the processElementTags() function, you can certainly pack a lot of processing into a single request by nesting tags and returning tags from scripts, but I do not think you will ever encounter a race condition. In fact, you should be able to reliably increase the maximum iterations for really complex scenarios (perhaps in a particular context-i.e. web app), and still not run into a problem.
$maxIterations= isset ($this->xpdo->config['parser_max_iterations']) ? intval($this->xpdo->config['parser_max_iterations']) : 10;
MODX Staff
It’s not hard-coded per se; I chose a default of 10 unless you provide a configuration setting with the key parser_max_iterations.
After my blunder on the $depth code, let me save face by pointing out the parser_max_iterations default hard-coded in over 30 places throughout the code.
$maxIterations= isset ($this->xpdo->config['parser_max_iterations']) ? intval($this->xpdo->config['parser_max_iterations']) : 10;
Quote from: BobRay at Jan 20, 2009, 06:01 PMIt’s not hard-coded per se; I chose a default of 10 unless you provide a configuration setting with the key parser_max_iterations.
After my blunder on the $depth code, let me save face by pointing out the parser_max_iterations default hard-coded in over 30 places throughout the code.
$maxIterations= isset ($this->xpdo->config['parser_max_iterations']) ? intval($this->xpdo->config['parser_max_iterations']) : 10;