-
-
Notifications
You must be signed in to change notification settings - Fork 897
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
[bug] Crash while acquiring the memsize of nodes #2923
Comments
On x86-64 linux with this patch, I get a different crash. I get one in
Full stderr output
I looked at the code in question and the only thing it's doing is walking the tree and calling I suspect that's what is happening here. I wasn't able to confirm that with this test case, however require 'nokogiri'
at_exit do
require 'objspace'
GC.start
ObjectSpace.dump_all(output: :stdout)
end
depth = 100000
html = '<!DOCTYPE html>' + ('<span>' * depth) + ('</span>' * depth)
doc = Nokogiri::HTML5.parse(html, max_tree_depth: -1) I get a similar result with |
No, my analysis is wrong. I believe I've isolated the problem and putting together a PR now. |
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
**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: #2923 (cherry picked from commit 81762fa)
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 (cherry picked from commit 81762fa)
Please describe the bug
When acquiring the memsize of nodes, nokogiri crashes with the following stack trace:
Help us reproduce what you're seeing
The issue can be reproduced by applying the following patch:
Expected behavior
There are no crashes.
Environment
Ruby 3.2.2 on x86 Linux.
Nokogiri on commit 2edbbef.
Additional context
N/A.
The text was updated successfully, but these errors were encountered: