Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix memsize_node when called on xmlAttrs #2924

Merged
merged 3 commits into from
Jul 8, 2023

Conversation

stevecheckoway
Copy link
Contributor

@stevecheckoway stevecheckoway commented Jul 6, 2023

What problem is this PR intended to solve?

The properties field of an xmlNode element points to an xmlAttr.
The first few fields of xmlAttr are in common with xmlNode, but not
the properties field which doesn't exist in an xmlAttr.

The memsize_node function was passing an xmlAttr to a recursive call
and then trying to do the same with the properties of that.

This led to type confusion and subsequent crashes.

Fixes: #2923

Have you included adequate test coverage?

Yes.

Does this change affect the behavior of either the C or the Java
implementations?

It fixes a crash in the C implementation of an ObjectSpace method that is not implemented in JRuby.

The `properties` field of an `xmlNode` element points to an `xmlAttr`.
The first few fields of `xmlAttr` are in common with `xmlNode`, but not
the `properties` field which doesn't exist in an `xmlAttr`.

The `memsize_node` function was passing an `xmlAttr` to a
recursive call and then trying to do the same with the properties of
that.

This led to type confusion and subsequent crashes.

Fixes: sparklemotion#2923
@flavorjones
Copy link
Member

cc @peterzhu2118 Can you kick the tires on this when you get a moment?

@peterzhu2118
Copy link
Contributor

Thank you for finding the fix so quickly! I can confirm that it no longer crashes with this patch.

@flavorjones
Copy link
Member

I'd really like to have a narrow test case that fails (even if it's just in valgrind). Going to play with this a bit before merging.

@flavorjones
Copy link
Member

flavorjones commented Jul 8, 2023

OK, inspecting the crash in the debugger shows it's because either there's an xmlDTD node, or an xmlEntity node within the DTD. xmlDTD has attributes where xmlNode has properties; and xmlEntity has length.

Anyway. I added a test that creates a DTD with an attribute just to demonstrate the bug, and prevent the unlikely regression.

which turns out to be because xmlDTD has "attributes" where xmlNode
has "properties"
@flavorjones flavorjones merged commit deadef9 into sparklemotion:main Jul 8, 2023
123 checks passed
@stevecheckoway stevecheckoway deleted the fix-memsize_node branch July 8, 2023 16:45
flavorjones added a commit that referenced this pull request Aug 11, 2023
**What problem is this PR intended to solve?**

Backporting changes from:

- #2927
- #2924
- #2951
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[bug] Crash while acquiring the memsize of nodes
3 participants