Linux perfで快適に計測するためのtips - Qiita
これがあるのとないのとでは分かりやすさが全然違うので、perfを使う時は常に入れておくようにすると便利です。 2. --call-graph は fp 以外で使う 上記の問題を解決すると perf record + perf report では何が呼ばれているかおおむね分かることが多いのですが、call graphを出すために perf record -g をすると [unknown] というのが出てきてしまうことがあります。(以降の計測結果はRack::Utils::HeaderHashを使ったRuby VMのベンチをRubyのmasterで走らせたものです) Samples: 38K of event 'cycles:ppp', Event count (approx.): 271180000 Children Self Command Shared Object Symbol - 1
gdb in docker container returns "ptrace: Operation not permitted."
I've checked /proc/sys/kernel/yama/ptrace_scope in the container and on the host - both report the value as zero but when attached to pid one gdb reports Reading symbols from /opt/my-web-proxy/bin/my-web-proxy...done. Attaching to program: /opt/my-web-proxy/bin/my-web-proxy, process 1 ptrace: Operation not permitted. I've also tried attached to the container with the privileged flag docker exec --
gdbを使ってRuby(2.3.3)のライブプロセスの情報を取得する - CubicLouve
Rubyのプロセスに対して、非破壊的に中をのぞいてみたいことが時々ありますよね？？？(詰まっているプロセスとか) 今回、gdbを使ってライブプロセスにアタッチして調べてみました。 準備 今回はAWSのamazon Linux上で試しています。 # cat /etc/system-release Amazon Linux AMI release 2016.09 gccは 4.8.3、 gdbは7.6.1を使ってます。 Rubyのバージョンは2.3.3を使いました。 予めrbenvをインストールしておき、rbenvでRubyは管理しておきます。 まずは、Rubyをデバッグ用にビルドします。 ビルドオプションとして、最適化を切っておくのとgdbからデバッグ情報を使えるように指定します。 wget https://cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.
[Linux] coreファイルについて - Qiita
coreファイルとはプロセスが異常終了した時のメモリ内容をダンプしたもの。 各変数の値やスレッドの状態、終了した時のソースコードの行数などを確認することができる coreファイルを出力するには ulimitコマンドでcoreファイルの出力サイズを設定する 以下の場合、無制限の大きさのcoreファイルを出力することができる 0に設定するとcoreファイルは生成されない ulimitコマンドではシェルに適用される。ログインシェルで常に適用させたい場合は /etc/security/limits.conf に設定を入れればよい 但し、PAM認証が使われている環境であること /etc/security/limits.conf に以下の行を追加してください
![[Linux] coreファイルについて - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/7a7bd41df873e077f814eaf59fa49d30cf58cae3/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCTGludXglNUQlMjBjb3JlJUUzJTgzJTk1JUUzJTgyJUExJUUzJTgyJUE0JUUzJTgzJUFCJUUzJTgxJUFCJUUzJTgxJUE0JUUzJTgxJTg0JUUzJTgxJUE2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0yN2EyZGU2ZTAyMTIzZTE4N2UzMGQxYTM2ZDkxZjI1MQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzdXp1dHN1a2kwMjIwJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz03NzczMzAzZjkxMmNhY2JmMWVlM2JkMGIzM2M4MmRjMA%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D006bc94295cdd369ace269cd6304b413)
gdbを使ったrubyのデバッグ - クックパッド開発者ブログ
技術部の国分 (@k0kubun) です。 先日byebugの高速化を行っていた最中、変更を加えたbyebugを使っていると一定の確率でrubyがSEGVするバグを発見しました。 私はC言語のコードのデバッグの経験はなかったのですが、デバッガの使い方を調べながらSEGVの原因調査を行いパッチを送ったところ無事取り込まれ、最新の高速なbyebugが安全に使えるようになりました。 その際、ruby自体をデバッグするために必要な情報が分散していて大変だったので、まだrubyのデバッグをしたことがないけれどやってみたいという人を対象に、gdbというデバッガを使ったrubyのデバッグの方法を紹介します。 デバッグ用にrubyをビルドする デバッグ時に変数名やソースコードなどの情報を見るためには、最適化オプションをオフにしてデバッグ用にrubyをビルドしておく必要があります。 rubyのデバッグ用ビル
CoreからRubyのバックトレースを表示するgdbruby.rbを作った
gdbperl.plというスクリプトがあります。そんｋする樋口証さん作の、gdbを操作してPerlのプロセスのバックトレースを取るツールです。生きているプロセスだけではなく、coreを取っておけばそのcoreからバックトレースが取れるのが特徴です。 gcoreというコマンドが/usr/binあたりにあって、これを使えば走っているプロセスのcoreを取得することができます。よって、本番環境で気軽にcoreを取ってgdbperl.plにかけることによって、刺さっているポイントを見つけたりすることができます。超便利。 くわしくは、Perlスクリプトをgdbでデバッグを参照ください。 んで、その便利なgdbperl.plをRubyに移植してみました。その名もgdbruby.rb。単純。 gdbruby.rb 使い方とか Rubyはデバッグシンボル付きのものをご用意ください。 生きているプロセスにア
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mold/BUGS.md at main · rui314/mold · GitHub
gdb で ruby プロセスのC レベルとRubyレベルのバックトレースを表示する方法 : sonots:blog
Ruby プロセスを追いかけるツール(プロファイラとか)10選 - sonots:blog