write_range_entry fails writing non-utf8 string

[stevenzzzz]

there seems to be a bug in "Inline auto write_range_entry(OutputIt out, const std::T& t)" would cause ASAN error if the string is a invalid-utf8 string.

using example: "\xf0\x28", it will cause an ASAN error.

[vitaut]

Could you provide a self-contained repro (ideally on godbolt)?

[stevenzzzz]

hmm, not sure if godbolt vm supports the asan sanitizer.

Could you try this?

#include <fmt/core.h>
#include <fmt/format.h>
#include <unordered_map>

int main(){

std::string invalid_utf8="\xf0\x28";

fmt::print("Foo Map: {}", invalid_utf8);

}

I actually got here from Envoy, which uses spdlog --> libfmt.

I have synced to 9.0.0, and "bazel test" on logging the afore mentioned string would end up with:

external/com_github_fmtlib_fmt/include/fmt/core.h:426: assertion failed: negative valuelibc++abi: terminating [2022-08-16 17:57:43.537][16][critical][backtrace] [./source/server/backtrace.h:104] Caught Aborted, suspect faulting address 0xfffe00000010
[2022-08-16 17:57:43.538][16][critical][backtrace] [./source/server/backtrace.h:91] Backtrace (use tools/stack_decode.py to get line numbers):
[2022-08-16 17:57:43.538][16][critical][backtrace] [./source/server/backtrace.h:92] Envoy version: 0/1.24.0-dev/test/DEBUG/BoringSSL
[2022-08-16 17:57:43.551][16][critical][backtrace] [./source/server/backtrace.h:96] #0: Envoy::SignalAction::sigHandler() [0x1517d9c]
[2022-08-16 17:57:43.551][16][critical][backtrace] [./source/server/backtrace.h:96] #1: _restore_rt [0x7f6475ecc420]
[2022-08-16 17:57:43.563][16][critical][backtrace] [./source/server/backtrace.h:96] #2: fmt::v8::detail::to_unsigned<>() [0xf4dbd4]
[2022-08-16 17:57:43.573][16][critical][backtrace] [./source/server/backtrace.h:96] #3: fmt::v8::detail::find_escape() [0xf6f2a7]
[2022-08-16 17:57:43.584][16][critical][backtrace] [./source/server/backtrace.h:96] #4: fmt::v8::detail::write_range_entry<>() [0xf6e757]
[2022-08-16 17:57:43.595][16][critical][backtrace] [./source/server/backtrace.h:96] #5: fmt::v8::detail::write_range_entry<>() [0xf6e65b]
[2022-08-16 17:57:43.606][16][critical][backtrace] [./source/server/backtrace.h:96] #6: fmt::v8::formatter<>::format<>() [0xf6e519]
[2022-08-16 17:57:43.617][16][critical][backtrace] [./source/server/backtrace.h:96] #7: fmt::v8::detail::value<>::format_custom_arg<>() [0xf6e367]
[2022-08-16 17:57:43.628][16][critical][backtrace] [./source/server/backtrace.h:96] #8: fmt::v8::basic_format_arg<>::handle::format() [0xf60a29]
[2022-08-16 17:57:43.639][16][critical][backtrace] [./source/server/backtrace.h:96] #9: fmt::v8::detail::default_arg_formatter<>::operator()() [0xf4d2ca]
[2022-08-16 17:57:43.650][16][critical][backtrace] [./source/server/backtrace.h:96] #10: fmt::v8::detail::parse_replacement_field<>() [0xf60fab]
[2022-08-16 17:57:43.661][16][critical][backtrace] [./source/server/backtrace.h:96] #11: fmt::v8::detail::vformat_to<>() [0xf4bc63]
[2022-08-16 17:57:43.672][16][critical][backtrace] [./source/server/backtrace.h:96] #12: spdlog::logger::log<>() [0xf4b22c]
[2022-08-16 17:57:43.683][16][critical][backtrace] [./source/server/backtrace.h:96] #13: spdlog::logger::log<>() [0xf401ff]

[vitaut]

Did you mean to use map in your example? Strings don't go through ranges.

[stevenzzzz]

Sorry, here is some more context: envoyproxy/envoy#22609

yes, it's actually when formatting a map, the detail::write_range_entry is called on every item, and the item.second value in our case contains an invalid string, like the one I pasted earlier.

that would cause an ASAN error.

I saw that in the most recent version there is quite a bit refactoring around detail::write_range_entry, I am not sure if that solved the issue, but I have synced to 9.0.0, and seems it didn't.

[dyfrgi]

Here is a repro on godbolt, showing the crash. I made this pretty similarly to the way spdlog uses fmt, thus the use of fmt::detail::vformat_to and fmt::make_format_args. This triggers the assert in to_unsigned when built without -DNDEBUG.

https://godbolt.org/z/zx4d4KTvE

[phprus]

@stevenzzzz @dyfrgi
Please check PR #3044

[vitaut]

Fixed in #3044 (thanks @phprus).