-
-
Notifications
You must be signed in to change notification settings - Fork 896
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] valgrind errors spotted in gumbo parser #2276
Comments
I spent some time looking at this today. I think I understand the warning, but want to verify with someone who understands GC better than me, maybe @tenderlove or @rubys. Let's focus on this section of gumbo.c's function Lines 357 to 365 in 2bb0084
This code creates a Ruby object that wraps a struct located on the stack, which is used to pass arguments into I'm not sure I understand why If that's what's happening, wrapping a stack-located struct seems like an unsafe idiom and we should convert to using a struct that's allocated on the heap. Is there a preferable idiom that we could use to avoid an additional memory allocation? Side note: this is extremely hard to reproduce. |
🤔 Can we just pass a pointer to this struct (cast as |
This should avoid the stack-address valgrind warning from #2276
I submitted a PR at #2290 to use the struct pointer directly. |
I wrote a response to this but GitHub appears to have lost it. I don't think that the approach in #2290 works. If the Ruby runtime is calling I can't think of a reason why the runtime would be holding on to it after it has returned from Maybe my code is misusing |
I suspect the best thing to do is to use |
With any luck, #2291 will solve the issue. |
The second and fourth argument to So I think #2290 is correct. The only issue is about Also #2291 is correct, but it is overkill IMHO. There's no need to use heap memory in this case.
It's still an option to use a registered DATA_PTR(parse_args) = NULL; and checking for NULL of
Yes they are deprecated, but there's nothing in the new API that helps for this particular issue. Use of the new API is an open issue: #2107 . With the new API recoupling can be done per: RTYPEDDATA_DATA(parse_args) = NULL; |
Makes sense.
Great. That's much simpler since it avoids having to create a new Ruby object (the heap allocation isn't a big deal either way given how many other heap allocations are going to be happening here). |
Thanks @larskanis and @stevecheckoway for the great conversation here. I'm glad we were able to discuss asynchronously, because I now understand this a bit more deeply (particularly Lars's explanation). Will merge #2290. |
Closed by #2290 |
Please describe the bug
A CI test run caught some memory errors in gumbo.
The build log is at https://github.com/sparklemotion/nokogiri/pull/2272/checks?check_run_id=2862967128
Here's the relevant snippet:
The text was updated successfully, but these errors were encountered: