getsentry/sentry-rust

Official Sentry SDK for Rust

Sentry SDK for Rust

This workspace contains various crates that provide support for logging events and errors / panics to the Sentry error logging service.

• sentry

  The main sentry crate aimed at application users that want to log events to sentry.

• sentry-actix

  An integration for the actix-web (3.0+) framework.

• sentry-anyhow

  An integration for anyhow errors.

• sentry-backtrace

  A utility crate that creates and processes backtraces.

• sentry-contexts

  An integration that provides os, device and rust contexts.

• sentry-core

  The core of sentry, which can be used to instrument code, and to write integrations that generate events or hook into event processing.

• sentry-debug-images

  An integration that adds a list of loaded libraries to events.

• sentry-log

  An integration for the log and env_logger crate.

• sentry-panic

  An integration for capturing and logging panics.

• sentry-slog

  An integration for the slog crate.

• sentry-tracing

  An integration for the tracing crate.

• sentry-types

  Contains types for the Sentry v7 protocol as well as other common types.

Note: Until the 1.0 release, the crates in this repository are considered work in progress and do not follow semver semantics. Between minor releases, we might occasionally introduce breaking changes while we are exploring the best API and adding new features.

Requirements

We currently only verify this crate against a recent version of Sentry hosted on sentry.io but it should work with on-prem Sentry versions 20.6 and later.

The Minimum Supported Rust Version is currently at 1.73.0. The Sentry crates tries to support a 6 months old Rust version at time of release, and the MSRV will be increased in accordance with its dependencies.

Resources

• Discord server for project discussions.
• Follow @getsentry on Twitter for updates

sentry-rust's Issues

Breaking (integration) as of actix-web 0.7.x

A cursory glance indicates the 'static lifetime for the middleware definition doesn't sit well with actix-web <= 0.7. I took a quick stab at fixing it but didn't wanna mess around with the hub stuff, since that's pretty far out of my understanding of the library 5000 feet level.

Unused dependency serde (and serde_json)

sentry-rust builds fine if you throw serde and serde_json out, is there a specific reason to keep it or can you throw it overboard?

Memory usage constantly increasing in plain scenario using a background actor

I managed to reduce the reproduction code to the following:

use actix::prelude::*;
use actix_web::{server, App, HttpRequest};
use sentry_actix::SentryMiddleware;
use std::env;


pub struct AppState {}

impl AppState {
    pub fn init() -> AppState {
        AppState {}
    }
}


pub struct SampleActor {}

impl SampleActor {
    pub fn init() -> SampleActor {
        SampleActor {}
    }
}

impl Actor for SampleActor {
    type Context = Context<Self>;
}

pub fn render(_req: &HttpRequest<AppState>) -> String {
    "Hello there!".into()
}


fn main() {
    let _guard = sentry::init(env::var("SENTRY_DSN").ok());
    env::set_var("RUST_BACKTRACE", "1");
    sentry::integrations::panic::register_panic_handler();

    let system = System::new("system");

    let _actor = SampleActor::init().start();

    let server = server::new(move || {
        App::with_state(AppState::init())
            .middleware(SentryMiddleware::new())
            .resource("/metrics", |r| {
                r.get().f(render);
            })
    })
    .bind(("0.0.0.0", 8888))
    .expect("Cannot bind listening port");

    server.system_exit().start();
    system.run();
}

Running this and hammering the /metrics route causes memory to keep bloating with no apparent end.

I'm not sure the problem is actually sentry-rust, but when I remove it the bloat stops...

Actix middleware causes tests to panic

When I add the sentry middleware to an actix web app the tests start panicking.

Here is a sample app reproduction: https://github.com/OutThereLabs/actix-sentry-example

Running RUST_BACKTRACE=1 cargo test on stable rust gives the following backtrace:

(running the app normally works, and commenting out the .middleware(SentryMiddleware::new()) line makes the tests pass)

thread '<unnamed>' panicked at 'cannot access a TLS value during or after it is destroyed: AccessError', libcore/result.rs:945:5

   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:207
   3: std::panicking::default_hook
             at libstd/panicking.rs:223
   4: std::panicking::begin_panic
             at libstd/panicking.rs:402
   5: std::panicking::try::do_call
             at libstd/panicking.rs:349
   6: std::panicking::try::do_call
             at libstd/panicking.rs:325
   7: core::ptr::drop_in_place
             at libcore/panicking.rs:72
   8: core::result::unwrap_failed
             at /Users/travis/build/rust-lang/rust/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at /Users/travis/build/rust-lang/rust/src/libcore/result.rs:809
  10: <std::thread::local::LocalKey<T>>::with
             at /Users/travis/build/rust-lang/rust/src/libstd/thread/local.rs:244
  11: <fragile::sticky::Sticky<T> as core::ops::drop::Drop>::drop
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/fragile-0.2.1/src/sticky.rs:99
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/fragile-0.2.1/src/sticky.rs:47
  12: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  13: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  14: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  15: <alloc::vec::Vec<T> as core::ops::drop::Drop>::drop
             at /Users/travis/build/rust-lang/rust/src/liballoc/vec.rs:2106
  16: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  17: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  18: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  19: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  20: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  21: <alloc::arc::Arc<T>>::drop_slow
             at /Users/travis/build/rust-lang/rust/src/liballoc/arc.rs:520
  22: <alloc::arc::Arc<T> as core::ops::drop::Drop>::drop
             at /Users/travis/build/rust-lang/rust/src/liballoc/arc.rs:971
  23: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  24: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  25: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  26: <std::collections::hash::table::Drain<'a, K, V> as core::ops::drop::Drop>::drop
             at /Users/travis/build/rust-lang/rust/src/libstd/collections/hash/table.rs:1158
  27: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  28: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  29: <std::collections::hash::map::HashMap<K, V, S>>::clear
             at /Users/travis/build/rust-lang/rust/src/libstd/collections/hash/map.rs:1197
  30: http::extensions::Extensions::clear
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/http-0.1.7/src/extensions.rs:128
  31: actix_web::httprequest::HttpInnerMessage::reset
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-0.6.14/src/httprequest.rs:87
  32: actix_web::server::helpers::SharedMessagePool::release
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-0.6.14/src/server/helpers.rs:31
  33: actix_web::server::helpers::SharedMessagePool::release
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/actix-web-0.6.14/src/server/helpers.rs:47
  34: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  35: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  36: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  37: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  38: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  39: core::mem::drop
             at /Users/travis/build/rust-lang/rust/src/libcore/mem.rs:787
  40: <fragile::sticky::Sticky<T>>::new::{{closure}}::{{closure}}
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/fragile-0.2.1/src/sticky.rs:71
  41: <core::mem::ManuallyDrop<T> as core::ops::deref::DerefMut>::deref_mut
             at /Users/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/fragile-0.2.1/src/sticky.rs:21
  42: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  43: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  44: core::ptr::drop_in_place
             at /Users/travis/build/rust-lang/rust/src/libcore/ptr.rs:59
  45: std::thread::local::fast::destroy_value
             at /Users/travis/build/rust-lang/rust/src/libstd/thread/local.rs:363
  46: tlv_finalize
  47: _pthread_tsd_cleanup
  48: _pthread_exit
  49: _pthread_body
  50: _pthread_start

Automatically inherit scopes

Currently you have to explicitly bind scopes into new threads. This makes a sentry integration quite intrusive: I'd prefer to be able to bind once at the start of the program and have new threads inherit their scope automatically.

`register_panic_handler` not sending anything

I tried using the register_panic_handler function, but it doesn't seem to send any events, and provides no feedback.

I tested it with an induced panic of panic!("Something went wrong"). Logging a normal info or similar works without problems.

Copying the body of the function into my own crate with some some modification (sending less info) works:

        let sentry = self.sentry.clone();
        std::panic::set_hook(Box::new(move |info: &std::panic::PanicInfo| {
            let location = info.location()
                .map(|l| format!("{}: {}", l.file(), l.line()))
                .unwrap_or("NA".to_string());
            let msg = match info.payload().downcast_ref::<&'static str>() {
                Some(s) => *s,
                None => {
                    match info.payload().downcast_ref::<String>() {
                        Some(s) => &s[..],
                        None => "Box<Any>",
                    }
                }
            };

            let device = Device::default();
            let e = Event::new("panic",
                               "fatal",
                               msg,
                               &device,
                               Some(&location),
                               None,
                               None,
                               None,
                               Some(VERSION),
                               None);
            sentry.log_event(e);
        }));

Hub Introduction and API changes

This is a meta issue for people that upgrade from earlier sentry rust versions. We introduced an explicit hub concept which manages the scopes now. As a result some apis changed quite a bit:

• with_client_and_scope -> Hub::with_active / Hub::current
• push_scope -> Hub::current().push_scope()

environment should be set to the value of SENTRY_ENVIRONMENT by default

RIght now, it's set to release or debug which is a build environment, not a "run" environment like production or test

Breadcrumbs are computed even when disabled

Hi, I'm debugging Sentry code and I have just noticed that a breadcrumb is computed, added to scope and immediately removed when the breadcrumbs are disabled. This is quite ineffective, there can be a simple condition at the very beginning to prevent all that unnecessary work. We are using sentry = "~0.13" (0.13.0) and log integration, I found the same code in the current master branch.

This is our config.

use std::borrow::Cow;

use failure::Error;
use sentry;
use sentry::integrations::log::{Logger, LoggerOptions};
pub use sentry::internals::ClientInitGuard;

use crate::configuration;

pub(crate) fn init(cfg: &configuration::Sentry) -> Result<ClientInitGuard, Error> {
    let sentry_guard = sentry::init(sentry::ClientOptions {
        dsn: Some(cfg.dsn.parse()?),
        environment: Some(Cow::from(cfg.environment.clone())),

        // It was tracking last 100 log messages to have a context, fully disable.
        max_breadcrumbs: 0,     // <<<<< THE ONLY ACTIVE CONFIG
        attach_stacktrace: false,

        // Show what exactly sentry client is doing.
        // debug: true,
        ..Default::default()
    });

    Ok(sentry_guard)
}

/// Build a new Sentry logger.
pub(crate) fn new_sentry_logger() -> Logger {
    let options = LoggerOptions {
        global_filter: Some(log::LevelFilter::Warn),
        filter: log::LevelFilter::Warn,
        emit_breadcrumbs: false,    // <<<<< DEAD STORE, NEVER READ
        emit_error_events: true,
        emit_warning_events: true,
    };

    Logger::new(None, options)
}

Field LoggerOptions::emit_breadcrumbs is defined but never read so the only effective config is ClientOptions::max_breadcrumbs. Setting it to zero causes the described behavior that is visible the code below.

    /// Adds a new breadcrumb to the current scope.
    ///
    /// This is equivalent to the global [`sentry::add_breadcrumb`](fn.add_breadcrumb.html) but
    /// sends the breadcrumb into the hub instead.
    pub fn add_breadcrumb<B: IntoBreadcrumbs>(&self, breadcrumb: B) {
        with_client_impl! {{
            self.inner.with_mut(|stack| {
                let top = stack.top_mut();
                if let Some(ref client) = top.client {
                    let scope = Arc::make_mut(&mut top.scope);
                    let options = client.options();
                    for breadcrumb in breadcrumb.into_breadcrumbs() {
                        let breadcrumb_opt = match options.before_breadcrumb {
                            Some(ref callback) => callback(breadcrumb),
                            None => Some(breadcrumb)
                        };
                        if let Some(breadcrumb) = breadcrumb_opt {
                            scope.breadcrumbs.push_back(breadcrumb);
                        }
                        while scope.breadcrumbs.len() > options.max_breadcrumbs {  // <<<<< INEFFECTIVE, TOO LATE
                            scope.breadcrumbs.pop_front();
                        }
                    }
                }
            })
        }}
    }

Move internals out of root namespace

The parts of #99 should be salvaged that move things like parse errors and others into the sentry::internals namespace because it pollutes the root namespace with rarely used things.

Update README

The README references Rust 1.10 (released July 2016) and therefore makes me think this project might be defunct:

Rust 1.10 should include register_panic_handler and btw bring more value to this lib ;)

Issue with openssl 1.1.1, update sentry to use reqwest 0.9?

I'm running into this issue:

error: failed to run custom build command for `openssl v0.9.23`
process didn't exit successfully: `/home/me/dev/thom/fruitone-server/target/debug/build/openssl-b944ee3fa9daf4e1/build-script-build` (exit code: 101)
--- stderr
thread 'main' panicked at 'Unable to detect OpenSSL version', /home/me/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.23/build.rs:16:14
note: Run with `RUST_BACKTRACE=1` for a backtrace.
 
warning: build failed, waiting for other jobs to finish...
error: build failed

because sentry uses reqwest 0.8.8 which uses native-tls 0.1.5 which uses openssl 0.9.23 which fails to build because it's less than 0.10.x and I have openssl 1.1.1 (on antergos).

Could you maybe update sentry to use reqwest 0.9? It uses native-tls ^0.2 which uses openssl ^0.10.11.

log4rs handle support

I'd like to be able to use sentry with log4rs while still being able to change the log4rs config. Currently I'm using log4rs and I dynamically reload the config whenever the file changes using inotify. To do this, the init function of log4rs returns a handle that I keep in a static mut. After looking at the examples and the code, I don't see how that's possible right now since the init call doesn't return anything. I'm happy to use any workarounds that might be available.

#[must_use] for sentry::init?

sentry::init returns a guard and is pointless if it’s not used…ask me how I found out. ;)

ISTM like the 1.27 feature of #[must_use] would be ideal for it. I’d cook up a PR but looking at Travis it seems like y’all are checking against old rustc versions and I’m not sure if there’s a backward-compatible way to use it?

Default title for Sentry events differs from integrations in other languages

I've noticed that when sending events from Sentry's log integration (v0.3.1), the title of the event is set to the name of the Rust application, whereas with other Sentry languages (e.g. Java/Python), the title of the event is the error message (or Exception class) itself.

E.g. if I log a message that's sent to Sentry (via the log integration) from a Rust binary named sentrynew, then the issue in Rust looks like:

Whereas issues in Sentry sent from other languages contain the error message in the title (or the Exception class in Java's case).

E.g.

Add more border frame markers

Currently there are not enough. Might even make sense to treat entire crates as border frames.

High memory utilization when using sentry-actix

When creating a sample actix integration according to the docs, I see big increase of the memory utilization of the process.

This is the sample code:

extern crate actix_web;
use actix_web::{server, App, HttpRequest, Responder};
use sentry;
use sentry_actix;

fn greet(_: &HttpRequest) -> impl Responder {
    let mut r = String::new();
    for _ in 0..100_000_000 {
        r.push('0');
    }
    r
}

fn main() {
    server::new(|| {
        App::new()
            .middleware(sentry_actix::SentryMiddleware::new())
            .resource("/", |r| r.f(greet))
    })
    .keep_alive(0)
    .bind("127.0.0.1:8000")
    .expect("Can not bind to port 8000")
    .run();
}

The memory utilization seems to grow on each request, and it grows with the size of the response topping off at around 400MB

e.g.:

 ~  %  while true; do ps xuww -p $(pgrep sentry-actix-leak); curl -o /dev/null -s http://localhost:8000; done
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712   0.0  0.1  4345104   9588 s008  S+   10:02AM   0:00.62 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  88.5  0.6  4452628 108556 s008  S+   10:02AM   0:08.25 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  81.8  1.2  4550932 206436 s008  S+   10:02AM   0:15.91 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  77.2  1.8  4649236 304308 s008  S+   10:02AM   0:23.52 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  69.9  2.4  4747540 402176 s008  S+   10:02AM   0:31.15 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  97.0  2.4  4747540 402192 s008  S+   10:02AM   0:38.85 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  94.0  2.4  4747540 402204 s008  S+   10:02AM   0:46.51 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712 100.0  2.4  4747540 402216 s008  S+   10:02AM   0:54.26 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712  86.4  2.4  4747540 402228 s008  S+   10:02AM   1:02.02 target/debug/sentry-actix-leak
USER      PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
nikolay 77712 100.0  2.4  4747540 402236 s008  S+   10:02AM   1:09.75 target/debug/sentry-actix-leak

Current versions I use are:

• actix 0.7.9
• actix-web 0.7.16
• sentry 0.12.0
• sentry-actix 0.12.0
• rustc 1.31.0 (abe02cefd 2018-12-04)

This is all running on a OS X Mojave (but seeing the same on Linux statically compiled (musl) binary).

Any ideas how I can limit the memory utilization of the sentry-actix middleware?

Unable to get example in README working

I'm trying out sentry-rust for a project at work and have added the example code from the README.md to our application.

When I call sentry.info("test.logger", "Test Message", None); or .error in my code, I don't see anything in the Sentry dashboard. I expect to see something show up in the dashboard.

As I'm not too familiar with Sentry it might be that I'm doing something obviously wrong.

Code

As you can see, I'm not doing anything different from the example in the README.md.

    let core = Core::new().expect("failed to initialise event loop");
    let handle = core.handle();
    let creds = "{street_cred}"
        .parse::<SentryCredential>()
        .unwrap();

    let sentry = Sentry::from_settings(handle, Default::default(), creds);
    sentry.info("test.logger", "Test Message", None);

Questions

• Am I doing something obviously wrong here?
  • If I am, could the docs be improved to avoid someone getting into a similar trap?
  • If I'm not, how do I debug this?

Environment

rustc: 1.22.0-nightly 
sentry: 0.2.0
tokio-core: 0.1.10

StackGuard assumes thread bound hub

Internally the stack guard uses Hub::with to pop the scope. This does not work for hubs not bound to the thread. We need some sort of internal reference to the stack.

Fails to build on windows with default features

The uname crate does not compile on windows. This crate should build "out of the box" on windows.

Device model includes a terminating zero byte

The device model context currently ends with an additional zero byte, which should be stripped:

{
  "contexts": {
    "device": {
      "model": "MacBookPro12,1\u0000"
    }
}

sentry only shows error!() msgs, not lower

Any idea why sentry only shows my error!() msgs in the dashboard, not warn!() or info!()?
Even though I configured it with level Info:

#[macro_use] extern crate log;
extern crate env_logger;
#[macro_use] extern crate sentry;

use sentry::integrations::panic::register_panic_handler;

fn main() {
	let _guard = sentry::init(("...", sentry::ClientOptions {
		release: sentry_crate_release!(),
		..Default::default()
	}));
	register_panic_handler();
	let mut log_builder = env_logger::Builder::new();
	log_builder.parse("info");
	let logger_options = sentry::integrations::log::LoggerOptions {
		filter: log::LevelFilter::Info, ..Default::default()
	};
	sentry::integrations::log::init(Some(Box::new(log_builder.build())), logger_options);
	warn!("test run warn");
}

Btw, do I have to use the same log level for the logger and sentry?

Allow any string in the ClientOptions release

We are using Sentry to track errors in several services, written in various languages like JavaScript and Python. In every service we set the release as the commit from which the the deployed package was built. It works fine in every project except the ones implemented in Rust.

The web page tells that it's ignoring an invalid value in the release field:

Again this works as expected with the python client:

Could you relax the constraints for the Rust client so we can get the same experience across all projects?

Documentation doesn't build (and the link from crates.io is broken)

According to docs.rs, setry fails to build and therefore it is missing the documentation.

https://docs.rs/crate/sentry/0.12.0

Incorrect backtrace in Windows.

I've been testing Sentry in Linux and Windows and in Windows I receive a completely different backtrace than the one I should receive. This is what I got when my program crashes on Linux:

And this is what I got on Windows:

Both versions use the exact same code, and both have debug symbols included. Also, RUST_BACKTRACE=1 is set in both operating systems. Is there something special that has to be done on Windows to get it working in the same way as on Linux?

EDIT: In case it helps, this is the entire sentry code of my program:

    // Initialize sentry, so we can get CTD and thread errors reports.
    let _guard = sentry::init((SENTRY_DSN, sentry::ClientOptions {
        release: sentry_crate_release!(),
        ..Default::default()
    }));

    // If this is a release, register Sentry's Panic Handler, so we get reports on CTD.
    if !cfg!(debug_assertions) { register_panic_handler(); }

Wait for event draining

Because the client is leaking when its attached to the scope there is currently no way for events to be sent right before shutdown unless something sleeps.

One way to deal with this would be to return a scope guard or similar:

fn main() {
    let _guard = sentry::init("...");
}

Allow specifying custom tags

Since tags is a private member of Event, and since Event::new doesn't have a tags argument, the only way to use custom tags is to manually create an instance of Event.

Use backtrace-parser?

Hi there!

I recently had to solve the problem of parsing backtraces to offer a good integration with failure for error reporting (context is my project over at https://github.com/srijs/rust-aws-lambda).

Your workaround here served as inspiration for me to write a pest-based parser for backtraces, which should not only be faster but also results in smaller binary sizes by removing the regex dependency (something that was important for my lambda use-case).

This is more or less just a heads-up that I published that as backtrace-parser, and was wondering whether that's something you'd be interested in as well.

I'm aware that the longer-term story here is to move backtrace support into std (the start of which is boats RFC to fix the error trait), so please feel free to close this if you feel it's not worth doing!

Backtraces skip frames with no symbols

This means that stripped binaries do not generate backtraces, and so server-side symbolification does not work. I have a fix for this which I will be adding to my PR.

License

I see the Apache 2.0 license mentioned in Cargo.toml, but no actual license text file in the repository. (Cf. mitsuhiko/fragile#5.)

Memory usage increases massively after first panic

We're using sentry's panic handler in our applications, and we're experiencing a problem where the memory usage (resident set size) increases to anywhere from ~100MB to ~600MB after a panic occurs. (A panic kills the current request/work item, but not the whole application).

Unfortunately I haven't been able to fully determine the cause yet, but I know this much:

• The memory usage only increases when sentry is configured with a valid DSN. Just having the panic handler installed is not enough.
• The memory usage does not seem to increase further after additional panics.
• Generating a backtrace manually with backtrace-rs does not cause any noticeable increase in memory usage.
• The issue occurs in all of our services using sentry, and the amount of memory used seems to vary by service, but is fairly consistent within each type of service.
• The issue occurs on linux, for both musl and non-musl targets.
• The issue occurs with all possible sentry features disabled other than those needed to support the panic handler and the client.

I'm still working to identify where the allocation is coming from.

Update README with new function signatures

Sentry::new() and Sentry::from_settings() had their call signatures changed in commit 5bb4255 upgrading hyper and adding tokio to require a tokio_core::reactor::Handle. This usage is not present in the README examples and the current README examples won't compile.

This could be off-putting to a newcomer to Rust who may dig into the crate to find they need a tokio reactor, but now have to learn asynchronous networking in Rust just send a test Sentry message.

(I'm in this boat and am happy to submit a PR once I figure out if and how I want to integrate a tokio reactor into the project I was hoping to instrument with Sentry)

Idea: allow using custom reqwest client for transport

The reqwest client that is used by default starts something like 5 background threads. That's quite a lot, considering sentry just sits there doing nothing most of the time (at least if there are no errors to report, which should be the case).

However, if the application already has a reqwest client around, it could be shared ‒ cloning the client only creates another handle to the background handle. Would it be possible to create another transport factory that creates the RequestTransport, but with the provided client?

Thank you

env_logger is outdated

0.6 is out

Feature: separate debug symbols

Enabling debug symbols massively increases the binary size, and also results in very high memory usage to load in those symbols when generating a backtrace (600MB in some cases). It would be useful there was a way to upload debug symbols separately, directly to sentry, and then have sentry do the symbol resolution.

Sentry not sending events when using HTTPS

I have an ARM Linux device that I'm using Sentry on. I've previously used the Python sentry client on it with no issues, and the Rust client also works correctly when testing from my local Arch Linux desktop. However, the Rust client isn't sending any events when running the device and using the HTTPS DSN. I've switched the DSN to HTTP and it works fine.

Here's my test case:

extern crate sentry;
extern crate env_logger;

fn main() {
    env_logger::init();

    let _guard = sentry::init("MY_DSN");
    sentry::capture_message("Hello World!", sentry::Level::Info);
    // when the guard goes out of scope here, the client will wait up to two
    // seconds to send remaining events to the service.
}

Here's the output I get with RUST_LOG=trace:

TRACE 2018-07-18T20:36:05Z: mio::poll: registering with poller
TRACE 2018-07-18T20:36:05Z: tokio_threadpool::builder: build; num-workers=1
DEBUG 2018-07-18T20:36:05Z: tokio_reactor::background: starting background reactor
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: consuming notification queue
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 649023 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop time - Instant { tv_sec: 3825, tv_nsec: 37692312 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop process, Duration { secs: 0, nanos: 620355 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 21620413 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop time - Instant { tv_sec: 3825, tv_nsec: 60312426 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop process, Duration { secs: 0, nanos: 742693 }
TRACE 2018-07-18T20:36:05Z: hyper::client::pool: park; waiting for idle connection: "https://sentry.io"
TRACE 2018-07-18T20:36:05Z: hyper::client::connect: Http::connect("https://sentry.io/api/236130/store/")
DEBUG 2018-07-18T20:36:05Z: hyper::client::dns: resolving host="sentry.io", port=443
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 5037174 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop time - Instant { tv_sec: 3825, tv_nsec: 68405706 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop process, Duration { secs: 0, nanos: 730692 }
DEBUG 2018-07-18T20:36:05Z: hyper::client::connect: connecting to 35.188.42.15:443
TRACE 2018-07-18T20:36:05Z: mio::poll: registering with poller
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 31713762 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop time - Instant { tv_sec: 3825, tv_nsec: 101252507 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop process, Duration { secs: 0, nanos: 661356 }
TRACE 2018-07-18T20:36:05Z: tokio_reactor: event Writable Token(0)
DEBUG 2018-07-18T20:36:05Z: tokio_reactor: loop process - 1 events, 0.000s
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop poll - Duration { secs: 0, nanos: 84162906 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop time - Instant { tv_sec: 3825, tv_nsec: 186465449 }
DEBUG 2018-07-18T20:36:05Z: tokio_core::reactor: loop process, Duration { secs: 0, nanos: 725692 }
TRACE 2018-07-18T20:36:05Z: tokio_reactor: event Readable | Writable Token(0)
DEBUG 2018-07-18T20:36:05Z: tokio_reactor: loop process - 1 events, 0.000s
TRACE 2018-07-18T20:36:05Z: mio::poll: deregistering handle with poller
DEBUG 2018-07-18T20:36:05Z: tokio_reactor: dropping I/O source: 0

`with_debug_meta` *might* work on osx, but not any other platform including linux

The findshlibs library on which it depends only supports linux and osx, and on linux the id method is hardcoded to always return None.

See gimli-rs/findshlibs#28

README seems to incorrectly indicate this crate is not on crates.io yet

The README says:

This is a new work in progress Sentry library. It will eventually be published to crates.io as sentry. At the moment the crate on creates.io is an older and incompatible version of this crate.

However, the sentry crate, appears to be a recent version from this repository, with the latest update a couple of days ago.

Feature names, follow the guideline

It will be a breaking change if you update features names but the guideline doesn't like the names you used 😄

https://rust-lang-nursery.github.io/api-guidelines/naming.html#c-feature

Support for custom hosts

It seems like currently the default sentry host is hardcoded here: https://github.com/aagahi/rust-sentry/blob/master/src/lib.rs#L330

That should be an optional option 👍

Client should implement `RefUnwindSafe`

All types implementing Sync should also implement RefUnwindSafe (because Sync types must inherently be unwind safe).

The sentry client is not currently unwind safe, because it stores a trait object of type Fn(Breadcrumb) -> Option<Breadcrumb> + Sync + 'static (note the lack of a RefUnwindSafe bound).

Any trait object with a Sync bound should also have the RefUnwindSafe bound, which (assuming the client doesn't store any other unwind-unsafe things) should make it automatically gain the RefUnwindSafe implementation.

Is it possible to hide stacktraces?

Hi, thanks for the great product!

In order to integrate the Sentry Rust SDK with our existing Rust app, I created a custom Appender (for the fork of log4rs we're on) that filters Warnings / Errors to Sentry. Unfortunately this adds 5-6 lines of identical stacktraces for every message that is reported, which I believe is the cause of bad grouping (unrelated events) for our issues.

The stacktraces look like:

...
0x563390102148
...::logging::sentry_appender::event_from_record sentry_appender.rs:38
<unknown>
0x563390102148
<...::logging::sentry_appender::SentryAppender as log4rs::append::Append>::append sentry_appender.rs:19
log4rs
0x563390332cc6
log4rs::Appender::append lib.rs:249
log4rs
0x563390332cc6
log4rs::ConfiguredLogger::log lib.rs:226
<unknown>
0x563390332cc6
<log4rs::Logger as log::Log>::log lib.rs:345
log
0x563390729fbb
log::__log lib.rs:968

I noticed in the documentation that it was possible to hide irrelevant stacktraces to improve the grouping, see: https://docs.sentry.io/data-management/rollups/?platform=rust.

If you modify your stacktrace by introducing a new level through the use of decorators, your stacktrace will change and so will the grouping. For this matter many SDKs support hiding irrelevant stack trace frames. For instance the Python SDK will skip all stack frames with a local variable called __traceback_hide__ set to True).

Is this possible with the Rust SDK? Additionally, if you have any alternative suggestions, that would be helpful.

Different filter level for log integration and Sentry?

Not 100% sure if this is a bug or whether my configuration is incorrect in this case.

I'm trying to set up Sentry with the log integration (and the env_logger crate), with warn and above sent to Sentry, and debug and above logged using env_logger.

I'm using something like the following:

#[macro_use] extern crate log;
extern crate env_logger;
extern crate sentry;  // version 0.3.1

fn main() {
    let _sentry = sentry::init(());

    let mut log_builder = env_logger::Builder::from_default_env();
    let logger_options = sentry::integrations::log::LoggerOptions {
        filter: log::LevelFilter::Warn, ..Default::default()
    };
    sentry::integrations::log::init(Some(Box::new(log_builder.build())), logger_options);

    debug!("debug message");
    info!("info message");
    warn!("warning message");
    error!("error message");
}

Then executing with:

$ RUST_LOG=debug SENTRY_DSN=XXX ./target/debug/myapp

This outputs:

WARN 2018-04-19T11:01:38Z: myapp: warning message
ERROR 2018-04-19T11:01:38Z: myapp: error message

So it looks like the filter in the log options are being applied to both Sentry and the env_logger - from the docs I thought that this should just apply to Sentry's logger, with the global_filter setting being used if I wanted it to apply to both, but my understanding might be wrong here.

panic! prevent crate to send events

I tried several way to enable panics to be sent to sentry, without success.
If I do something wrong, please point it to me.

simple panic

    let credential: SentryCredential = SENTRY_KEY.parse().unwrap();
    let sentry_client = Sentry::new("machine_name".to_owned(), "version".to_owned(), "env".to_owned(), credential);
    sentry_client.debug("", "panic handler NOT pluged", None);
    println!("before panic");
    panic!("bim panic");

output:

before panic
thread 'main' panicked at 'bim panic', src/bin/kragle.rs:89

and nothing is sent to sentry

with panic handler

I tried with a panic handler, no luck either:

    let credential: SentryCredential = SENTRY_KEY.parse().unwrap();
    let sentry_client = Sentry::new("machine_name".to_owned(), "version".to_owned(), "env".to_owned(), credential);
    sentry_client.register_panic_handler(Some(|panic_info: &PanicInfo| -> () {
        println!("je PANIC");
    }));
    sentry_client.debug("", "panic handler pluged", None);
    println!("before panic");
    panic!("bim panic");

outputs:

before panic
je PANIC

still nothing sent to sentry

without panic

of course, if i simply start sentry and send something, everything is fine:

    let credential: SentryCredential = SENTRY_KEY.parse().unwrap();
    let sentry_client = Sentry::new("machine_name".to_owned(), "version".to_owned(), "env".to_owned(), credential);
    sentry_client.error("", "panic handler NOT pluged", None);
    println!("no panic");

outputs

no panic

and in sentry I get the correct event "panic handler NOT pluged"

"Documentation" link on crates.io links to repo

Is there a trick to use integrations::env_logger and sentry_actix together?

In some programs I do stuff outside actix-web so I would like to also log error leveled log messages but I get duplicates when I get errors in actix-web.

Is there a trick to exclude "actix_web" from integrations::env_logger?

Is it possible to catch errors in main?

Now that we can use '?' in main is there a way to catch those errors? Maybe with something like exitfailure.

Add support for systems without supported versions of OpenSSL

This issue is related to #88 and would prevent issues like it when openssl 1.2 comes out.

Currently, sentry-rust depends on reqwest with default feature flags, which pulls in native-tls and openssl.

This causes multiple issues:

1. On systems without openssl header packages installed, openssl-sys won't build.
2. If distributions like arch linux update to newer versions of openssl, issues like #88 will arise
3. Systems that don't support openssl are not supported (although targeting embedded systems with non-unix OSes is probably not a goal in this project)

Stacktrace parsing in the `failure` integration is outdated

Line display seems to have changed in the failure.backtrace formatting (or at least doesnt't work in my case with ACTIX integration).

• It should be updated. (I'm working on it, PR incoming.)

It would have been nice if Backtrace provided methods to access internal representation without having to go Backtrace->String->Regex->Sentry... ^^

In order to ensure this will not happen again :

• Shouldn't the api::protocol::Stacktrace::from_frames_reversed call not silent-fail by returning an option when the vector is empty ? (asking for advice)

• A test should be added to ensure any similar format change would be detected.

change backtrace_support to public

In info report we need backtrace information. but default is close.

sentry::capture_event(Event {
        message: Some("Hello test!".into()),
        level: Level::Info,
        stacktrace: current_stacktrace(),
        ..Default::default()
    });

so, I can't write like it.