bashが信号11、分割エラーで終了する理由を見つける方法

bashが信号11、分割エラーで終了する理由を見つける方法

Red Hat Linux(V6)を実行している本番サーバーでは、bashからコアダンプを頻繁に受け取ります。このようなことが一日にも数回、何十回も起こります。

全長TR

解決する: コアから詳細情報を取得し、競合を引き起こしたステートメントを見つけるには、bash-debuginfo をインストールします。

理由:この場合、以前のバージョンのbashで修正されていないバグが原因でした。lists.gnu.org/archive/html/bug-bash/2010-04/msg00038.html4.1について2010年4月に報告され、4.2で修正されました(2011年初頭リリース)。

詳細
このサーバーは、単一のWebアプリケーション(apache + cgi-bin)と複数のデプロイメントを実行します。 webapp cgi(Cプログラム)はしばしばシステムコールを実行します。

シェルのやり取りがあまりないため、一部のサービスやWebアプリケーションがコアダンプを引き起こす可能性があり、このエラーの原因を知る必要があります。

コアダンプのバックトレースは少し退屈です(下記参照)。

このエラーの詳細についてはどうすればよいですか?親プロセスチェーンが何であるか(詳細)、現在の変数と環境が何であるか、どのスクリプトおよび/またはコマンドが実行されたかを知りたいです。

仲裁システムを有効にしましたが、それに対する仲裁スレッドも少し退屈です。例は次のとおりです。

type=ANOM_ABEND msg=audit(1516626710.805:413350): auid=1313 uid=1313 gid=22107 ses=64579 pid=8655 comm="bash" sig=11

コアトレースは次のとおりです。

    Core was generated by `bash'.
Program terminated with signal 11, Segmentation fault.
#0  0x000000370487b8ec in free () from /lib64/libc.so.6
#0  0x000000370487b8ec in free () from /lib64/libc.so.6
#1  0x000000000044f0b0 in hash_flush ()
#2  0x0000000000458870 in assoc_dispose ()
#3  0x0000000000434f55 in dispose_variable ()
#4  0x000000000044f0a7 in hash_flush ()
#5  0x0000000000433ef3 in pop_var_context ()
#6  0x0000000000434375 in pop_context ()
#7  0x0000000000451fb1 in ?? ()
#8  0x0000000000451c84 in run_unwind_frame ()
#9  0x000000000043200f in ?? ()
#10 0x000000000042fa18 in ?? ()
#11 0x0000000000430463 in execute_command_internal ()
#12 0x000000000046b86b in parse_and_execute ()
#13 0x0000000000444a01 in command_substitute ()
#14 0x000000000044e38e in ?? ()
#15 0x0000000000448d4e in ?? ()
#16 0x000000000044a1b7 in ?? ()
#17 0x0000000000457ac8 in expand_compound_array_assignment ()
#18 0x0000000000445e79 in ?? ()
#19 0x000000000044a264 in ?? ()
#20 0x000000000042ee9f in ?? ()
#21 0x0000000000430463 in execute_command_internal ()
#22 0x000000000043110e in execute_command ()
#23 0x000000000043357e in ?? ()
#24 0x00000000004303bd in execute_command_internal ()
#25 0x0000000000430362 in execute_command_internal ()
#26 0x0000000000432169 in ?? ()
#27 0x000000000042fa18 in ?? ()
#28 0x0000000000430463 in execute_command_internal ()
#29 0x000000000043110e in execute_command ()
#30 0x000000000041d6d6 in reader_loop ()
#31 0x000000000041cebc in main ()
~

修正する:システムがVMWareで処理されている仮想マシンで実行されています。

  • バッシュのバージョンは何ですか? GNU bash、バージョン 4.1.2(1)-リリース(x86_64-redhat-linux-gnu)

  • どのバージョンのlibcや他のライブラリがbashにリンクされていますか?

ldd(GNU libc) 2.12

(Bashには他のどのライブラリがリンクされていますか?詳細を持続的に取得するコマンドはありますか?

  • スクリプト、インタラクティブシェル、またはその両方を実行すると、これは起こりますか?スクリプトの場合、1つのスクリプトでのみ発生しますか、複数のスクリプトで発生しますか、それともすべてのスクリプトで発生しますか?通常、bashスクリプトはどのような種類の操作を実行しますか?他のプロセスでセグメントエラーが発生しますか?サーバーでメモリテストを実行しましたか? ECC RAMはありますか?

私の質問に記載されているように:よくわかりません。ただし、スケジュールされたスクリプトまたは対話型Webアプリケーション内の一部のシステムコールが原因で発生する必要があります。次の構造のように、「スクリプト内のスクリプト」でもあります。

myVar=$($(some command here ($and here too))

しかし、この問題はRAMの物理的な問題ではないかもしれないと思います。他のランダムな競合はなく、この競合のみが発生し、2つの別々の物理マシンで実行されている2つの別々の仮想マシンでもこの問題が発生しました。

アップデート2:

スタックでは、問題が連想配列に関連している可能性があると思います。

#1  0x000000000044f0b0 in hash_flush ()
#2  0x0000000000458870 in assoc_dispose ()
#3  0x0000000000434f55 in dispose_variable ()
#4  0x000000000044f0a7 in hash_flush ()

これらの変数は、ほぼすべてのカスタムスクリプトに存在します。システムでよく使用される変数と機能を含むライブラリを使用する基本スクリプトがあります。

私たちが持っているほとんどすべてのスクリプトはそのスクリプトから来ています。

ベストアンサー1

gdbが提案したようにdebuginfoツールをインストールし、競合を引き起こした式を得ました。

#20 0x0000000000457ac8 in expand_compound_array_assignment (
    var=<value optimized out>, 
    value=0x150c660 "$(logPath \"$@\")", flags=<value optimized out>
)

これで問題が何であるか、どこにあるのかがわかります。私の場合は.bashrcの関数にあり、根本的な原因はBashでマッピングされた変数を誤ってオーバーライドしたことでした。

declare -A myMap
local myMap=""

...
for key in "${!myMap[@]}"; do 
  echo ${myMap[$key]}
done    

この関数はサブシェル内で呼び出され、「セグメントエラー」エラー出力が非表示になります。

おすすめ記事