Describe the bug

While upgrading the Ruby profiler to use libdatadog 0.8.0, I ran into the following issue:

In file included from /usr/local/bundle/gems/libdatadog-0.8.0.1.0-x86_64-linux/vendor/libdatadog-0.8.0/x86_64-linux/libdatadog-x86_64-unknown-linux-gnu/lib/pkgconfig/../../include/datadog/profiling.h:11:0,
                 from ../../../../ext/ddtrace_profiling_native_extension/collectors_stack.h:3,
                 from ../../../../ext/ddtrace_profiling_native_extension/collectors_cpu_and_wall_time.c:4:
/usr/local/bundle/gems/libdatadog-0.8.0.1.0-x86_64-linux/vendor/libdatadog-0.8.0/x86_64-linux/libdatadog-x86_64-unknown-linux-gnu/lib/pkgconfig/../../include/datadog/common.h:24:52: error: missing binary operator before token "("
 #elif (defined(__has_attribute) && (__has_attribute(warn_unused_result))) || \
                                                    ^
Makefile:237: recipe for target 'collectors_cpu_and_wall_time.o' failed
make: *** [collectors_cpu_and_wall_time.o] Error 1

Looking through the gcc docs this issue seems to be documented in https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html and we seem to be using defined(__has_atribute) incorrectly.

This issue seems to be introduced in #24

To Reproduce

Steps to reproduce the behavior:

Use the ivoanjo/docker-library:ddtrace_rb_2_2_10 docker image to get a suitable old version of gcc:

$ docker run --network=host -ti -v `pwd`:/working ivoanjo/docker-library:ddtrace_rb_2_2_10 /bin/bash
root@docker-desktop:/app# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10+deb8u1)

and try to compile anything that includes that header.

Expected behavior

Compiling libdatadog on this gcc version should ideally still be possible.

Errors or warnings received

(See above)

How does libdatadog help you?

There's quite a lot of code on the Ruby profiler that I'll be able to delete soon ;)

          Should the `additional_stacktraces` go in here as well?

Originally posted by @danielsn in #285 (comment)

If we cleanup the builder slightly, we can avoid this unnecessary roundtrip

Describe the bug
After updating ddtrace to 1.21.0 which updated libdatadog to 6.0.0.2.0 and then visiting a route that has a constraint on it and when the session does not match that constraint, a NoMethodError gets thrown.

To Reproduce
Steps to reproduce the behavior:

1. Have datadog tracing enabled
2. Create a route with a constraint that won't match
3. Start your rails server
4. Visit the route
5. See error

Simple example:

routes.rb

  constraints -> { false } do
    get "/test_path", to: redirect("/404.html")
  end

Then visit that path with datadog tracing enabled

Expected behavior
An ActionController::RoutingError should be thrown causing a 404 status instead of the NoMethodError which causes a 500 status to be returned.

Errors or warnings received

     NoMethodError:
       undefined method `[]' for #<ActionDispatch::Journey::Route

Thrown from:

.rvm/gems/ruby-3.2.2/gems/ddtrace-1.21.0/lib/datadog/tracing/contrib/rails/patcher.rb:18:in `find_routes'

In this code:

integration_route = result.first[2].path.spec.to_s.gsub(/\(\.:format\)/, '') if result.any?

          I actually wonder if we should get rid of the units and take the memory savings that come with that -- I'm not sure any of our profilers ever sets the units.

Originally posted by @ivoanjo in #202 (comment)

Minor: Not sure this is something we want to care about, but one thing we could do when the function is called is to check that our signal handlers are still active, e.g. because something else on the system may have overwritten them.

(I'm thinking of this, because there may be a situation where someone starts the crash tracker, and then discovers that the VM overwrites their signal handlers after X, and then calls register_crash_handlers again expecting libdatadog to be restored but isn't. Maybe too farfetched?)

Originally posted by @ivoanjo in #297 (comment)

          One thing that occurred to me while reviewing the PR is -- should we have something protecting `handle_posix_signal_impl` so that it can't get called multiple times in the same process?

Afaik if a thread is handling a signal (e.g. SIGSEGV), no other SIGSEGVs can be delivered. But I... don't think that applies to other threads in the same process.

May be worth giving it a try?

Originally posted by @ivoanjo in #297 (comment)

Describe the bug

Libdatadog error messages repeat the error message multiple times. For instance, I've started the Ruby profiler without a Datadog agent, and this is the libdatadog error message I see:

failed ddog_prof_Exporter_send: error trying to connect: tcp connect error: Connection refused (os error 111): tcp connect error: Connection refused (os error 111): Connection refused (os error 111)

Since these are user-visible error messages, it's not great to have them be somewhat confusing.

To Reproduce
Steps to reproduce the behavior:

1. Try to report a profile with the exporter, and do not start the agent
2. Observe the error message from the exporter

Expected behavior

An error message that's not repeated.

Describe the bug:

As reported by @nsavoire via slack:

I observe a strange behaviour with libdatadog where ddprof_ffi_Profile_add is getting slower and slower even after resetting the profile.
At start it takes around ~100us per call (stacks are ~200 frames deep), and after it slowly increase up to ~125us per call.

If I force a restart of our worker process that collect profiles, then this behaviour disappears.
Could this be explained by memory allocator performance degrading with time ?

and @r1viollet also added

We discussed this. Memory fragmentation was mentioned using different allocators could help
We also mentioned that we need to re-engineer part of the aggregation regardless.

Expected behavior:

Performance should not degrade with a new or newly reset profile.

Description

When building libraries in libdatadog, we want to ensure that it is easy to add in or remove modules.
Any logics associated to a module should be within the associated folder.

This means that shell scripts with embedded build logics should be removed.

Example of logics to migrate
https://github.com/DataDog/libdatadog/blob/main/build-telemetry-ffi.sh
https://github.com/DataDog/libdatadog/blob/main/build-profiling-ffi.sh

Package config generation:
https://github.com/DataDog/libdatadog/blob/main/profiling-ffi/datadog_profiling.pc.in

Associated FFI examples:
https://github.com/DataDog/libdatadog/tree/main/examples/ffi

Describe the goal of the feature

The goal of the feature is to be able to do:

cargo build --feature crash-tracking,telemetry,profiling
cargo build --feature trace-pipeline,profiling

Which would produce the expected deliverable.
The associated test commands should work.

Describe alternatives you've considered

We can review the RFC.
The aim is to have a single build for Rust features.

Additional context

As we are looking to add tracing features in the build, we want a clean build system.