-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Airbrake gem segfaults on Circle CI #204
Comments
Thanks for reporting this! Some other user complained about this bug, too. They were also using Ruby 2.1 ( Could you downgrade airbrake (or simply not load it) and show what the following prints: Thread.current.keys.map.with_object({}) { |key, h| h[key] = Thread.current[key].inspect } Maybe there's some weird IO object there that can't be "inspected". Do you know what test generates this error? |
I was able to reproduce this with ruby 2.1.2 th[:__recursive_key__] will blow this |
Looks like a bug in ruby https://bugs.ruby-lang.org/issues/10579 the way to reproduce ruby -e '{["foo"]=>nil}; p Thread.current[:__recursive_key__]' |
Not sure why but it doesn't crash when running on my dev local (also 2.1.2p95), only on circle (edit: mystery solved, actually I was using 2.0.0 version of the gem locally) |
Thanks @ilchanka, this is a very useful link. @joshuasiler I managed to reproduce it locally, so luckily it's easier to think of a fix. However, if nothing works, then we can avoid loading |
Fixes #204 (Airbrake gem segfaults on Circle CI) The main reason to use `inspect` here was to avoid a bug with IO objects in Rails apps. I stumbled upon an edge case while running the thread filter against a Rails app. The app would stuck because `io_obj.to_json` would never return. The `io_obj` was open. Closed IO objects raise IOError, which we already handle. Given that we stop using `inspect`, I think this also fixes #204.
Fixes #204 (Airbrake gem segfaults on Circle CI) The main reason to use `inspect` here was to avoid a bug with IO objects in Rails apps. I stumbled upon an edge case while running the thread filter against a Rails app. The app would stuck because `io_obj.to_json` would never return. The `io_obj` was open. Closed IO objects raise IOError, which we already handle. Given that we stop using `inspect`, I think this also fixes #204.
Fixes #204 (Airbrake gem segfaults on Circle CI) The main reason to use `inspect` here was to avoid a bug with IO objects in Rails apps. I stumbled upon an edge case while running the thread filter against a Rails app. The app would stuck because `io_obj.to_json` would never return. The `io_obj` was open. Closed IO objects raise IOError, which we already handle. Given that we stop using `inspect`, I think this also fixes #204.
Fixes #204 (Airbrake gem segfaults on Circle CI) I stumbled upon an edge case while running the thread filter against a Rails app. The app would stuck because `io_obj.to_json` would never return. The `io_obj` was open. Closed IO objects raise IOError, which we already handle. To make sure we avoid any kind of segfaults, we ignore `:__recursive_key__`, which holds data for PrettyPrint.
Fixes #204 (Airbrake gem segfaults on Circle CI) I stumbled upon an edge case while running the thread filter against a Rails app. The app would stuck because `io_obj.to_json` would never return. The `io_obj` was open. Closed IO objects raise IOError, which we already handle. To make sure we avoid any kind of segfaults, we ignore `:__recursive_key__`, which holds data for PrettyPrint.
Any idea what would cause this?
The text was updated successfully, but these errors were encountered: