Skip to content

lexbor: Fix the allocation and move sizes of lexbor_array_obj_t - #25431

Open
nicolas-grekas wants to merge 1 commit into
php:masterfrom
nicolas-grekas:lexbor-array-obj
Open

nicolas-grekas wants to merge 1 commit into
php:masterfrom
nicolas-grekas:lexbor-array-obj

Conversation

@nicolas-grekas

Copy link
Copy Markdown
Contributor

Split from #23949.

lexbor_array_obj_t allocates 8 times the memory it uses. ext/dom uses such an array as its work list when it converts the parsed tree to libxml2. The waste grows with the number of sibling nodes. Parsing '<main>' . str_repeat('<i></i>', 100000) . '</main>' with Dom\HTMLDocument::createFromString() now peaks at 25.6MB instead of 52.4MB.

The fix is lexbor/lexbor@f4cbbcd, already merged upstream. This PR adds it as patch 0025.

gh25118.phpt relied on the oversized work list to reach its 32MB memory_limit during the conversion. I lowered the limit to 26M so that the test still fails there. It's now skipped when the Zend allocator is disabled, because the limit is then reached at another point. The test still crashes when the fix for GH-25118 is reverted. @devnexen please tell me if you prefer another way.

lexbor_array_obj_init() and lexbor_array_obj_expand() allocated 8 times
the memory they need on 64-bit platforms, and lexbor_array_obj_delete()
moved 8 times the bytes of the remaining entries. This is patch 0025,
merged upstream as lexbor/lexbor@f4cbbcd.

ext/dom uses such an array as its work list when it converts the parsed
tree to libxml2, so gh25118.phpt needs a lower memory_limit to still
fail during that conversion.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant