investigate valgrind failure in CI coming from Nokogiri_wrap_xml_node_set

[flavorjones]

Describe the bug

CI picked up a valgrind failure that's concerning for two reasons:

• the stack walkback shows it's happening in Nokogiri code
• the rest of the stack walkback is suspiciously similar to the stacks we're suppressing, which means maybe we're getting false positives

To Reproduce

Occurrence is here: https://ci.nokogiri.org/teams/nokogiri-core/pipelines/nokogiri-pr/jobs/ruby-libxmlruby-valgrind/builds/57

Stack walkback is:

==9855== Invalid read of size 8
==9855==    at 0x49279A0: mark_locations_array (gc.c:4682)
==9855==    by 0x4930090: gc_mark_stacked_objects (gc.c:5503)
==9855==    by 0x4930090: gc_mark_stacked_objects_incremental (gc.c:5537)
==9855==    by 0x4930090: gc_marks_step (gc.c:6442)
==9855==    by 0x4930090: gc_marks_continue (gc.c:6502)
==9855==    by 0x4930090: heap_prepare (gc.c:2018)
==9855==    by 0x4930090: heap_get_freeobj_from_next_freepage (gc.c:2035)
==9855==    by 0x4930090: heap_get_freeobj (gc.c:2074)
==9855==    by 0x4930090: newobj_slowpath (gc.c:2218)
==9855==    by 0x4930090: newobj_slowpath_wb_unprotected (gc.c:2236)
==9855==    by 0xB6F02FD: Nokogiri_wrap_xml_namespace (xml_namespace.c:84)
==9855==    by 0xB6F32D3: reify_node_set_namespaces (xml_node_set.c:393)
==9855==    by 0xB6F32D3: Nokogiri_wrap_xml_node_set (xml_node_set.c:415)
==9855==    by 0xB6F7944: evaluate (xml_xpath_context.c:236)
==9855==    by 0x4AAA168: vm_call_cfunc_with_frame (vm_insnhelper.c:2514)
==9855==    by 0x4AAA168: vm_call_cfunc (vm_insnhelper.c:2539)
==9855==    by 0x4AB53C1: vm_sendish (vm_insnhelper.c:4023)
==9855==    by 0x4AB53C1: vm_exec_core (insns.def:801)
==9855==    by 0x4ABAEDB: rb_vm_exec (vm.c:1920)
==9855==    by 0x4AC6CA2: invoke_block (vm.c:1044)
==9855==    by 0x4AC6CA2: invoke_iseq_block_from_c (vm.c:1116)
==9855==    by 0x4AC6CA2: invoke_block_from_c_bh (vm.c:1134)
==9855==    by 0x4AC6CA2: vm_yield (vm.c:1179)
==9855==    by 0x4AC6CA2: rb_yield_0 (vm_eval.c:1227)
==9855==    by 0x4AC6CA2: rb_yield_1 (vm_eval.c:1233)
==9855==    by 0x4AC6CA2: rb_yield (vm_eval.c:1243)
==9855==    by 0x487C2CB: rb_ary_each (array.c:2135)
==9855==    by 0x4AAA168: vm_call_cfunc_with_frame (vm_insnhelper.c:2514)
==9855==    by 0x4AAA168: vm_call_cfunc (vm_insnhelper.c:2539)
==9855==    by 0x4AB547F: vm_sendish (vm_insnhelper.c:4023)
==9855==    by 0x4AB547F: vm_exec_core (insns.def:782)
==9855==    by 0x4ABAEDB: rb_vm_exec (vm.c:1920)
==9855==    by 0x4AC6CA2: invoke_block (vm.c:1044)
==9855==    by 0x4AC6CA2: invoke_iseq_block_from_c (vm.c:1116)
==9855==    by 0x4AC6CA2: invoke_block_from_c_bh (vm.c:1134)
==9855==    by 0x4AC6CA2: vm_yield (vm.c:1179)
==9855==    by 0x4AC6CA2: rb_yield_0 (vm_eval.c:1227)
==9855==    by 0x4AC6CA2: rb_yield_1 (vm_eval.c:1233)
==9855==    by 0x4AC6CA2: rb_yield (vm_eval.c:1243)
==9855==    by 0x4881DDB: rb_ary_collect (array.c:3065)
==9855==    by 0x4AAA168: vm_call_cfunc_with_frame (vm_insnhelper.c:2514)
==9855==    by 0x4AAA168: vm_call_cfunc (vm_insnhelper.c:2539)
==9855==    by 0x4AC2A3B: vm_call_method_each_type.part.410 (vm_insnhelper.c:2925)
==9855==    by 0x4AC31D4: vm_call_method_each_type (vm_insnhelper.c:3026)
==9855==    by 0x4AC31D4: vm_call_method (vm_insnhelper.c:3053)
==9855==    by 0x4AB547F: vm_sendish (vm_insnhelper.c:4023)
==9855==    by 0x4AB547F: vm_exec_core (insns.def:782)
==9855==    by 0x4ABAEDB: rb_vm_exec (vm.c:1920)
==9855==    by 0x4ABC5EB: invoke_iseq_block_from_c (vm.c:1116)
==9855==    by 0x4ABC5EB: invoke_block_from_c_proc (vm.c:1216)
==9855==    by 0x4ABC5EB: vm_invoke_proc (vm.c:1238)
==9855==    by 0x4ABC5EB: rb_vm_invoke_proc (vm.c:1259)
==9855==    by 0x49E071B: rb_proc_call (proc.c:971)
==9855==    by 0x491378E: exec_end_procs_chain (eval_jump.c:105)
==9855==    by 0x491378E: rb_ec_exec_end_proc (eval_jump.c:120)
==9855==    by 0x4913ABD: rb_ec_teardown (eval.c:142)
==9855==    by 0x4913CBD: rb_ec_cleanup (eval.c:209)
==9855==    by 0x4914032: ruby_run_node (eval.c:335)
==9855==    by 0x10910A: main (main.c:50)
==9855==  Address 0x1ffeffe7e0 is on thread 1's stack
==9855==  160 bytes below stack pointer
==9855== 

Environment

{"warnings"=>[],
 "nokogiri"=>"1.10.4",
 "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"=>{"source"=>"packaged",
            "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"],
            "compiled"=>"2.9.10",
            "loaded"=>"2.9.10"},
 "libxslt"=>{"source"=>"packaged",
             "patches"=>[],
             "compiled"=>"1.1.34",
             "loaded"=>"1.1.34"}
}

[flavorjones]

I believe this valgrind error was from #1952 which has been fixed by #2186 in v1.11.2.