open-telemetry / open-telemetry/opentelemetry-cpp
Assertion `false && "i == variant_npos"' failed with -DWITH_STL=ON
@lalitb is already working on this.
Since Feb 14, 2022.
- Dominant language
- C++
- Stars
- 1.4k
- Forks
- 632
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 75
Description
Describe your environment
OS: CentOS Stream release 8
Compiler: gcc (GCC) 10.3.1 20210422 (Red Hat 10.3.1-1)
OpenTelemetry libs compiled today (2/9/2022) from main branch using following command:
cmake -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DBUILD_SHARED_LIBS=ON -DWITH_JAEGER=ON -DWITH_STL=ON ..
Steps to reproduce
Use this code:
#include <opentelemetry/exporters/jaeger/jaeger_exporter.h>
#include <opentelemetry/sdk/trace/simple_processor.h>
#include <opentelemetry/sdk/trace/tracer_provider.h>
#include <opentelemetry/trace/provider.h>
namespace sdktrace = opentelemetry::sdk::trace;
namespace nostd = opentelemetry::nostd;
namespace trace = opentelemetry::trace;
int main()
{
// Jaeger HTTP exporter
opentelemetry::exporter::jaeger::JaegerExporterOptions opts;
opts.transport_format = opentelemetry::exporter::jaeger::TransportFormat::kThriftHttp;
opts.endpoint = "localhost";
opts.server_port = 6831;
opts.headers = {{}}; // optional headers
auto jaeger_udp_exporter =
std::unique_ptr<sdktrace::SpanExporter>(new opentelemetry::exporter::jaeger::JaegerExporter(opts));
auto resource_attributes = opentelemetry::sdk::resource::ResourceAttributes
{
{"service.name", "test"},
{"service.instance.id", "test-123"}
};
auto resource = opentelemetry::sdk::resource::Resource::Create(resource_attributes);
return 0;
}
Compile using this command:
g++ -o test test.cc -O0 -g -std=c++11 -Wall -Wextra -Werror -Wno-unused-parameter -I/build/otlp/debug-stl/include -L/build/otlp/debug-stl/lib64 -Wl,-rpath,/build/otlp/debug-stl/lib64 -lopentelemetry_exporter_jaeger_trace -lopentelemetry_resources -lopentelemetry_trace
What is the expected behavior?
No crash when app is started
What is the actual behavior?
App crashes with following message:
test: /build/otlp/debug-stl/include/opentelemetry/nostd/./internal/absl/types/../types/internal/variant.h:426: absl::otel_v1::variant_internal::VisitIndicesSwitch::Run<absl::otel_v1::variant_internal::VariantStateBaseDestructorNontrivial<bool, int, unsigned int, long int, double, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::vector<bool, std::allocator >, std::vector<int, std::allocator >, std::vector<unsigned int, std::allocator >, std::vector<long int, std::allocator >, std::vector<double, std::allocator >, std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >, long unsigned int, std::vector<long unsigned int, std::allocator >, std::vector<unsigned char, std::allocator > >::Destroyer>::<lambda()>: Assertion `false && "i == variant_npos"' failed.
Additional context
valgrind --num-callers=50 --track-origins=yes ./test shows that this is caused by uninitialized heap memory access. Here are few bottom callstack frames for this allocation:
==19559== by 0x4F105F3: opentelemetry::v1::sdk::resource::Resource::Merge(opentelemetry::v1::sdk::resource::Resource const&) (in /build/otlp/debug-stl/lib64/libopentelemetry_resources.so)
==19559== by 0x4F106E8: opentelemetry::v1::sdk::resource::Resource::Create(opentelemetry::v1::sdk::common::AttributeMap const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (in /build/otlp/debug-stl/lib64/libopentelemetry_resources.so)
==19559== by 0x41E6BA: main (test.cc:26)
App does not crash when Jaeger exporter is not created, when only resource is created - this is somehow related to this exporter.
Libraries compiled with -DWITH_STL=OFF works fine.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.