Closed mtmorgan closed 11 months ago
I am sure that this is not the correct fix, but the following removes the segfault by forcing dynamic_storage
to be free'd early.
jsoncons/include master$ git diff
diff --git a/include/jsoncons_ext/jmespath/jmespath.hpp b/include/jsoncons_ext/jmespath/jmespath.hpp
index a091085b6..25931632c 100644
--- a/include/jsoncons_ext/jmespath/jmespath.hpp
+++ b/include/jsoncons_ext/jmespath/jmespath.hpp
@@ -3376,8 +3376,10 @@ namespace jmespath {
{
return Json::null();
}
- dynamic_resources<Json,JsonReference> dynamic_storage;
- return deep_copy(*evaluate_tokens(doc, output_stack_, dynamic_storage, ec));
+ dynamic_resources<Json,JsonReference>* dynamic_storage = new dynamic_resources<Json,JsonReference>();
+ Json copy = deep_copy(*evaluate_tokens(doc, output_stack_, *dynamic_storage, ec));
+ free(dynamic_storage);
+ return copy;
}
static jmespath_expression compile(const string_view_type& expr)
I am sure that this is not the correct fix, but the following removes the segfault by forcing
dynamic_storage
to be free'd early.
I'll have to study this a bit more, but could you also try
Json copy;
{
dynamic_resources<Json,JsonReference> dynamic_storage;
copy = deep_copy(*evaluate_tokens(doc, output_stack_, *dynamic_storage, ec);
}
return copy;
which should have the same affect?
Thanks, Daniel
That variant does not help. Actually, I used the following, without a *
before dynamic_storage
and with a second )
after ec
in the deep_copy()
line, which I think is what you meant...
Json copy;
{
dynamic_resources<Json,JsonReference> dynamic_storage;
copy = deep_copy(*evaluate_tokens(doc, output_stack_, dynamic_storage, ec));
}
return copy;
Okay, I think if you changed
free(dynamic_storage);
to
delete dynamic_storage;
in your variant, you'd see the same result as with my variant. That shouldn't happen, I'll need to investigate.
yes, changing free()
to delete
in my variant also breaks the 'fix' and the heap use after free error returns.
Could you check if you still see the segfault with the code on master?
Success!
Good. I think this is just another case of an over eager sanitizer. The "fix" was a work around that had no implications for heap memory access.
Describe the bug
This program queries a JSON document with JMESPath, using the 'ojson' type
Compiling with 'address sanitizer'
indicates a memory access violation
What compiler, architecture, and operating system?
What jsoncons library version?