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.

Sign up for GitHub

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

Jump to bottom

[bug] Memory is leaked when raising an exception from a custom XPath function, or from some SAX handler callbacks #2097

Open
flavorjones opened this issue Oct 13, 2020 · 1 comment
Open

[bug] Memory is leaked when raising an exception from a custom XPath function, or from some SAX handler callbacks #2097

flavorjones opened this issue Oct 13, 2020 · 1 comment
Labels
topic/error-handling topic/memory Segfaults, memory leaks, valgrind testing, etc.
Milestone
v1.17.0

Comments

@flavorjones
Copy link
Member

flavorjones commented Oct 13, 2020 •
edited
Loading

Please describe the bug

If I'm using a custom XPath function and I raise an exception within my handler, memory is leaked.

Help us reproduce what you're seeing

Run this script and watch the process's memory utilization grow:

#! /usr/bin/env ruby

require 'nokogiri'

loop do
  doc = Nokogiri::XML.parse("<foo></foo>")
  begin
    doc.xpath('//foo[exceptional()]', Class.new {
                def exceptional()
                  raise "ONOES"
                end
              }.new)
    exit 1 # should never be reached
  rescue => e
    puts e
  end
end

Expected behavior

Memory shouldn't be leaking.

Environment

# Nokogiri (1.10.10)
    ---
    warnings: []
    nokogiri: 1.10.10
    ruby:
      version: 2.7.0
      platform: x86_64-linux
      description: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]
      engine: ruby
    libxml:
      binding: extension
      source: packaged
      libxml2_path: "/home/flavorjones/.rvm/gems/ruby-2.7.0/gems/nokogiri-1.10.10/ports/x86_64-pc-linux-gnu/libxml2/2.9.10"
      libxslt_path: "/home/flavorjones/.rvm/gems/ruby-2.7.0/gems/nokogiri-1.10.10/ports/x86_64-pc-linux-gnu/libxslt/1.1.34"
      libxml2_patches:
      - 0001-Revert-Do-not-URI-escape-in-server-side-includes.patch
      - 0002-Remove-script-macro-support.patch
      - 0003-Update-entities-to-remove-handling-of-ssi.patch
      - 0004-libxml2.la-is-in-top_builddir.patch
      - 0005-Fix-infinite-loop-in-xmlStringLenDecodeEntities.patch
      libxslt_patches: []
      compiled: 2.9.10
      loaded: 2.9.10

Additional context

I discovered this while working on #1610. It's not clear to me yet (I haven't taken the time to look) whether libxml2 is leaking this memory or if it's something in Ruby-space; but I suspect it's libxml2 not being able to clean up the XPath context because we've longjmped over it.

In which case, we may need to do something more invasive to wrap the calls back into Ruby space in a rescue block.

I'd also be curious to see if the following functionality is also susceptible to the same class of issue (raising an exception from a Ruby callback):

  • SAX parsing callbacks
  • XSLT registered transformation functions
@flavorjones flavorjones added the topic/memory Segfaults, memory leaks, valgrind testing, etc. label Oct 13, 2020
@flavorjones flavorjones mentioned this issue Oct 14, 2020
Closed
2 tasks
@flavorjones flavorjones added this to the v1.17.0 milestone Jun 26, 2024
@flavorjones
Copy link
Member Author

I'd also be curious to see if the following functionality is also susceptible to the same class of issue (raising an exception from a Ruby callback):

  • SAX parsing callbacks

Yep, as part of my work on #3265, I discovered that raising from a callback like SAX::Document#characters will leak (because the C code needs to free that string!).

@flavorjones flavorjones changed the title [bug] Memory is leaked when raising an exception from a custom XPath handler [bug] Memory is leaked when raising an exception from a custom XPath function, or from some SAX handler callbacks Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic/error-handling topic/memory Segfaults, memory leaks, valgrind testing, etc.
Projects
None yet
Milestone
v1.17.0
Development

No branches or pull requests
1 participant
@flavorjones