Closed (fixed)
Project:
Views (for Drupal 7)
Version:
6.x-3.x-dev
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
7 Jan 2011 at 04:41 UTC
Updated:
19 Feb 2011 at 00:20 UTC
Jump to comment: Most recent file
Comments
Comment #1
zhangtaihao commentedI'm not sure if this patch fixes the problem correctly, but it highlights the problematic line.
The gist of the issue is that
$storageis passed down in recursion as-is. This (along with a special child key present also in the parent storage) might have caused the algorithm to keep hitting the same part of the array.Comment #2
dawehnerDo you know when this happens exactly? Do you have a example of a option_definition to reproduce it?
Comment #3
zhangtaihao commentedI'm not sure if the following is the option_definition triggering the problem. It's the best I can do considering each request is dumping 20000 rows into watchdog every second.
Anyway, here goes:
The infinite recursion is happening in
[value].However, regardless of the problematic array structure, the code as it currently stands doesn't recurse down into the array properly anyway. For example, the
[min]and[max]keys are merely skipped because the$storagearray passed down simply doesn't contain those keys (and even if it did, the function wouldn't be crawling under the right trail). I suspect any value below the first level are never actually scanned.P.S. The only reason I haven't flagged this as critical is that it's for translatables. However, I think it deserves attention because it causes out-of-memory error for us, even at 256M.
Comment #4
merlinofchaos commentedYes, comparing the unpack_translatable call prior to that, I agree that this patch seems correct. Committed.