タグ付けされた質問 「debugging」

以前はこのHP Compaq 610にFedora 14をインストールしていましたが、サスペンド機能は問題なく動作しました。Scientific Linux 6.1をインストールしたので、サスペンドが機能しなくなりました。どうすればデバッグ/修正できますか？

11 debugging  scientific-linux  suspend 

デスクトップを再起動するたびにこれらのエラーメッセージが表示されます（さらに、シャットダウン時に保持する方法がわからないが、これまでのところこの質問には関係ありません）。 [gorre@uplink ~]$ journalctl -p err..alert ... -- Reboot -- May 11 21:47:03 uplink kernel: ACPI BIOS Error (bug): Failure looking up [\_SB.PCI0.RP04.PXSX._SB.PCI0.RP05.PXSX], AE_NOT_FOUND (20180105/dswload2-194) May 11 21:47:03 uplink kernel: ACPI Error: AE_NOT_FOUND, During name lookup/catalog (20180105/psobject-252) May 11 21:47:03 uplink kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.RP04.PXSX, AE_NOT_FOUND (20180105/psparse-550) …

11 linux  arch-linux  debugging  acpi 

私printfはその仕事をするためにOSの助けが必要であることを知っています。 printfライブラリがないため、Linuxソースコードでは機能しないことも知っています。そしてprintkデバッグのためにあります。 printkOSがまだ起動している場合、どのように機能しますか？

10 kernel  linux-kernel  debugging 

USBゲームパッドを入手しました。この周辺機器が実際にPC /カーネルに送信している信号とコマンドを確認して確認したいと思います。 私は何かが cat /dev/bus/usb/006/003 十分でしたが、このコマンドはすぐに戻り、一部の読み取り不可能なエンコードされた文字を出力します。 そのようなUSBデバイスを「デバッグ」する方法はありますか？

9 linux  usb  debugging 

ラップトップの蓋を閉じると、奇妙なバグが発生します-システムがフリーズし（キーに反応せず、sshからの応答もありません）、奇妙な色の効果が表示されます。カーネルログ（再起動後）には何も表示されません。私の質問は-それをデバッグする方法は？たぶん、最後に呼び出されたカーネル関数などを追跡する方法はありますか？

9 debugging  linux-kernel  freeze 

クラッシュするバグは最も厄介なバグで、データの損失、ダウンタイム、イライラするユーザーにつながる可能性があります。アプリケーションのクラッシュが少なくなればよいでしょう。 マシンコンテキストは複雑であるため、クラッシュは通常のユーザーにとって妥当な時間内に再現できないことがよくあります。これは、バグがまれであることを意味しているわけではありません。単に、それをトリガーするものが、各ユーザー（DSTの変更など）でまれにしか発生しないことを意味している可能性があります。このようなバグは、多くのユーザーが報告しない限り、修正される見込みはありません。さらに多くのクラッシュが報告された場合、それは良いことです。 クラッシュをデバッグするには、開発者は可能な限り明確なコンテキストを必要とします。生成されたクラッシュレポートは、通常、詳細で正確であるため、優れています。ユーザーは、すべてのコンテキストを手動で熱心に観察して報告することは期待できないため、まばらで間違った情報を送信することがよくあります。 多くのアプリケーションの対象読者は、開発者やシステム管理者ではなく、自宅や職場の一般大衆です。このようなユーザーは、クラッシュ情報を手動で収集する方法や-dbgパッケージをインストールする方法を知ることはできませんが、そのようなユーザーから生成されたレポートは引き続き使用できます。一部のアプリケーションには独自のクラッシュレポートツールがありますが、私の経験ではこれらが機能することはめったになく、エラーを報告できなかったと報告された場合、手動で行う方法についての情報がないようです（私はこれを観察しましたFirefoxとFlashの両方の最新バージョン）。システム全体でのクラッシュレポートの生成は適切です。 大量の-dbgパッケージをインストールしたり、すべてのアプリケーションのドキュメントを読んだり、通常のマシンをクロールする速度を落としたりせずに、グローバルに有効化できる何らかの種類のクラッシュレポート生成*はありますか？ *ログ、コアダンプ、スタックトレースなど **必ずしも必要でinitはありませんが、少なくとも、典型的なデスクトップLinuxインストールで実行されているアプリケーションの重要なサブセットでは必要です。私の経験では、GUIアプリケーションはシェルアプリケーションよりも100倍以上頻繁にクラッシュするため、当然GUIアプリケーションが焦点になります。

9 debugging 

15の同一のLinux RH 4.7 64ビットサーバーがあります。クラスタデータベースを実行します（クラスタはアプリケーションレベルです）。時々（毎月かそこら）ランダムなボックス（決して同じではありません）がフリーズします。 私は箱にpingを送信でき、pingが機能します。ボックスでsshしようとすると、次のようになります。 ssh_exchange_identification: Connection closed by remote host SSHが正しく設定されている。 サーバールームに行ってコンソールに直接ログインしようとすると、Alt+ Fnでコンソールを切り替えたり、ユーザー名を入力したり、文字を表示したりできますが、を押した後Enter、何も起こりません。一度8時間待っても変わらなかった。 すべてをリモートホストに記録するようにsyslogを設定しましたが、それらのログには何も記録されていません。マシンを再起動すると、問題なく動作します。私はHWテストを実行しました-すべて問題なく、ログには何もありません。マシンはNAGIOSでも監視されており、フリーズする前に異常な負荷やアクティビティが発生することはありません。 アイデアが足りません。他に何ができるか、または確認できますか？

9 linux  debugging  freeze 

このパッチからコンパイルしたカスタムカーネルモジュールがlogitech G19あり、他のGシリーズデバイスの中でキーボードのサポートが追加されています。私はUbuntuのマーベリックカーネルのマスターブランチ（2.6.35）に対して問題なくコンパイルしました。 モジュールを起動してロードできますが、本当に奇妙な状況に陥っています。モジュールを（ブート時またはmodprobe経由で）ロードするとすぐに、黒い画面が表示され、コンソールがロックします。 奇妙なのは、それが私のシステムをロックしないということです。それは現在のコンソールセッションにすぎません。私は自分のボックスにSSHで接続でき、端末とセッションを提供します。そして、タイプすることができ、コマンドを実行することもでき、それによって出力が得られます。次に、次のプロンプトが表示され、すぐにロックされます。 私はで見るdmesgヌルポインタがあること、そして私は、次のスタックトレースを取得します： [ 956.215836] input: Logitech G19 Gaming Keyboard as /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.1/1-2.1.2/1-2.1.2:1.1/input/input5 [ 956.216023] hid-g19 0003:046D:C229.0004: input,hiddev97,hidraw3: USB HID v1.11 Keypad [Logitech G19 Gaming Keyboard] on usb-0000:00:1d.7-2.1.2/input1 [ 956.216065] input: Logitech G19 as /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2.1/1-2.1.2/1-2.1.2:1.1/input/input6 [ 956.216128] Registered led device: g19_97:orange:m1 [ 956.216146] Registered led device: g19_97:orange:m2 [ 956.216178] …

9 linux  kernel-modules  c  debugging  assembly 

メモリ関連の問題を追跡するときに使用する戦略は何ですか？メモリリークやメモリ破損などを特定するために、どのツール（オープンソースおよび独自仕様）を使用していますか？システムでgdb / dbxしか使用できない場合、どのようにメモリリークを追跡しますか？ 私にとって、デバッガだけでメモリリークを修正することは非常に困難です。

9 debugging  memory-leaks 

bashでは、私は書くことができます： caller 0 呼び出し元のコンテキストを受け取ります： 行番号 関数 スクリプト名 これはデバッグに非常に役立ちます。与えられた： yelp () { caller 0; } 次に、yelpどのコード行に到達しているかを確認するために書き込むことができます。 私が実装することができますcaller 0でbashのように： echo "${BASH_LINENO[0]} ${FUNCNAME[1]} ${BASH_SOURCE[1]" どのように私は同じ出力を得ることができますcaller 0ではzsh？

8 shell  zsh  function  debugging 

Linux / ARMの共有ライブラリ内の関数の呼び出しを追跡できるツールを探しています。基本的に、コマンドラインを指定し、このツールで呼び出されたライブラリ関数と渡された引数のレコードを生成できるようにしたいと考えています。このために、何らかの形の関数フッキングを使用できると思います。 私が知っているはltrace、必要な機能を正確に提供します。しかし、ltraceそれは私にとってはうまくいきません： より複雑なプログラムをトレースすると、segfaultになることがよくあります。 非常に遅いです。 より堅牢な代替手段を探しています。スピードはいいですが、私の主な関心事ではありません。主に、任意の（非回避的）プログラムを分析できるライブラリー呼び出しをトレースする手段が必要です。 SysdigもARMでは機能せず、dtraceの移植はまだNetBSDでのみベータ版で機能しています。 誰かがそのようなツールを使用可能な状態で知っていますか？

8 linux  arm  debugging  shared-library  trace 

私はstraceとltraceについて知っていますが、それはそれぞれ、プロセスが実行しているシステムコールとライブラリコールを教えてくれるだけです。プロセスが実行している命令を正確に知りたいのですが。アセンブリ、または可能であればCとアセンブリの間の何らかの中間点。バイナリがデバッグシンボルでコンパイルされていないと仮定すると、可能性が高いので、最初のオプションに傾倒します。 使用例：プロセスがハングしているように見え、straceまたはltraceからの出力がありません。プロセスが「何か」を実行しているかどうかを確認します。これは停止の問題を解決することに似ていると思うので、これを判断するのは難しいかもしれないと思います。ただし、有用なデータを収集できる可能性があります。 2番目の使用例：好奇心。アセンブリ命令のリスト全体をテキストリストにダンプすると興味深いでしょう。 私の推測では、gdbを使用してこれを行うことができますが、これは私が作成したプログラムのデバッグについてではなく、gdbを使用して実行中のプロセスの状態をチェックするためです。 OSはCentOS 6です。

8 process  debugging  strace  gdb  ltrace 

Arch Linuxでsystemdに「アップグレード」して以来、予期しないロックアップが発生するとログが失われ続けます。私はヒットと同じログ失う問題を 1ヶ月前ともう一度問題を打ちます。他にも独立した確認があります。 状況： Javaやネットワーク関連のユーティリティでいくつかのことをしているときに、KDE（クロック）がフリーズしているのを見ました。CPUファンが騒々しくなり、熱が高まっていました。ただし、マウスポインタは移動できます。 別のマシンからsshしようとした（「ホストへのルートがない」ために失敗した） 私は数分待った、おそらくNMIウォッチドッグは問題のあるタスクを殺すことができた。サイコロはありません。 Ctrl+ Alt+はF1した後でも、どちらか動作しませんでしたSysRq+R 上記の手順がうまくいかなかったので、SysRqシーケンスREIを発行することにしました。の後E、画面は黒くなりましたが、コンソールもなくなりました。SysRq+の後もK したがって、このセッションは失われたように見えます。実行できる唯一のことは、デバッグ情報を収集することです。ウィキペディアを見て、いくつかの中でSysRq+ d（保留中のロックを表示）を押すことにしました。 SysRq+ Sを押した後、少し待ってからSysRq+で再起動しましたB。 再起動してコンソールにログインした後、クラッシュの痕跡は見られませんでした。最近記録されたエントリはWiresharkの使用によるものでしたが、それでも45分のギャップがありました。 （私はLinux v3.8-rc5-218-ga56e160 btwを実行していました） では、ロックアップが原因で異常に再起動したときに、ログを確実に保持するにはどうすればよいですか？

8 systemd  logs  debugging  systemd-journald 

現在のところ、この質問は、Q＆A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 Linux / Unixユーザーとして、私たちは頻繁に問題に遭遇します。そして、長時間の問題解決の後、私たちはデバッグのスキルを身につけます。 さて、一般的なUNIXの問題をデバッグしようとするときの良い原則、方法、またはベストプラクティスは何ですか？ 問題の原因を簡単に見つけるために、平均的なユーザーとしてどのようなツールが必要ですか？

8 debugging  troubleshooting 

によるとtcpdump、私のサーバーは次のTCPパケットを受信します。 12:52:29.603233 00:19:e2:9e:df:f0 00:16:3e:6a:25:3f, ethertype IPv4 (0x0800), length 74: 10.10.10.65.38869 192.168.215.82.22: Flags [S], seq 567054335, win 5840, options [mss 1460,sackOK,TS val 2096335479 ecr 0,nop,wscale 0], length 0 上記のように、これはTCPポート22へのTCP SYNパケットであり、私の場合はをリッスンしsshdます。このTCPパケットがsshdプロセスに到達するかどうかを確認します。sshdデバッグモードでを再起動するのが1つのオプションだと思います。ただし、TCPポートでリッスンしているプロセスがメッセージを受信するかどうかを確認するための賢いツール/方法は他にありますか？TCP SYNパケットの場合、TCP SYN + ACKを送信するのはカーネルTCP / IPスタックであり、sshd？

7 process  tcp  debugging  netfilter