「Web出版サイト」ベータ公開

Q&A集[?]

当サイトでのご質問の受付は終了しました

すべてのコンテンツを読み込み専用としたため、回答欄からも投稿できません

Apache OpenOffice/LibreOfficeのご質問はそれぞれのフォーラムへご投稿ください

質問コーナー

サイト内検索

分類メニュー

関連サイト


本日:1
昨日:0
総数:3776
現在:3


起動時に「無題1」の回復処理を繰り返す。

ページOpenOffice.org FAQの登録ページ
投稿者horimoto
分類
edit/refer
優先順位
edit/refer
状態
edit/refer
カテゴリー
edit/refer
投稿日2008-09-07 10:12:19 (日)
OSFedora8, CentOS5.2
依存するページ
バージョン
edit/refer

メッセージ

回答ページでは行末に「~」を付加する必要はありません

OOoのアップデートを行った直後でもないのし、実際に無題1などというファイルを使ったり破損させることなどしていなかったのに、起動時に(calcでもwriteでも)このファイルの回復処理を行いつづけようとします。
具体的には、
1) アプリケーションからcalcを選択してみます。~
2) ダイアログが出力されます。それには、
  予期しないエラーが発生し、OpenOffice.org がクラッシュしました。作業中のファイルはすべて保存されます。
  これらのファイルは、OpenOffice.orgの次の起動時に自動的に回復します。
  次のファイルが回復処理の対象となります(A):
しかし、ここで次のファイルは表示されていない。

3) 回復処理をしますか?というダイアログに「復元の開始」と答え、復元の終了後「次へ」を選択すると、エラーレポートツールが起動されます。~
4) エラーレポートの送信を行います。~
5) 送信が終了したら、またダイアログが出力されて、
  予期しないエラーが発生し、OpenOffice.org がクラッシュしました。作業中のファイルはすべて保存されます。
  これらのファイルは、OpenOffice.orgの次の起動時に自動的に回復します。
  次のファイルが回復処理の対象となります(A):
   無題1

と振り出しに戻った気分になるダイアログが出力されます。
ここで、「OK」を選択しても3)へ戻る事の繰り返し。
「復元の開始」ではなく、「キャンセル」を選択すると、瞬間なんらかのダイアログの枠が出力されて。 後は何事もなかったように起動しません。

さて、他の情報としては、ホームディレクトリには
 .crash_report_checksum
 .crash_report_frames
 .crash_report_preview
 .crash_report_unsent
 .crash_reportrc
ファイルが生成されています。
また、今まで
.openoffice.org2.0
だった個人別のサブディレクトリが
.openoffice.org2
として新しく別にできています。 そして、この中に .lock ファイルが当然のごとくできています。

以上、こんな感じなのですが、9月5日にCentOS5.2+GNOMEな環境で事態を目撃後、 Fedora8,Fedora9でも同様の症状に見舞われています。 これはら別々のハードウェアで構成もバラバラです。
ただ、OOo 2.4.1というのだけが一致しています。


OOoの画面や設定がおかしくなってしまいました

M.Kamataki (2008-09-07 10:36:28 (日))

というFAQ(faq/1/202)をサイドメニューの「本当によくある質問」からたどれるようにしています。

今回のケースでは、上記ページで紹介している異常終了時の修復情報である
user/registry/data/org/openoffice/Office/Recovery.xcu
というファイルをmvかrmすると良いのではないでしょうか。

ただ、RedHat系ディストリビューションのオリジナルパッケージとOpenOffice.orgサイトからリリースされた公式パッケージが混ざっているような気もします。公式パッケージは、設定ファイルとして.openoffice.org2を使います。.openoffice.org2.0は、RedHat系ディストリビューションのOpenOffice.orgパッケージが使うものではないでしょうか。

faq/1/202の改善策でもおかしな場合は、一度OpenOffice.orgのパッケージをすべて削除し、あらためてインストールしなおしてください。

RedHat系ディストリビューションのパッケージと、OpenOffice.orgサイトの公式リリースとは同じ名前のOpenOffice.orgでも異なるソースを基にビルドされていますから、両者が混ざっている状態ですとまともに動作しない恐れがあります。

openoffice.org2.0の削除や.crashファイルの削除を行いましたが、

horimoto (2008-09-07 12:06:50 (日))

.openoffice.org2がオリジナルなのですね。
2.4.1をインストールする時にRedHat系ディストリビューションのOOoをインストールせずにオリジナルパッケージのOOoをインストールしてyumのexcludeもopenoffice*としていたのですが、、、
ところでご指摘の通り、ファイルの削除を行いましたが、最初のcrash情報がなくなった部分だけが異なり、あとは同じ症状の繰り返しです。

一台だけ、同じOSバージョンで発生するならば「こういうこともあるだろう」と思うのですが、複数のOS、ハードウェア上で同様に発生するのが不思議で、また困っています。

あらためてインストールしなおしてみますが、、、エンドユーザレベルで評判が落ちるのが気がかりで。

別解ですが、

amano (2008-09-07 14:50:46 (日))

OOoベースの他のパッケージを使うと相性が良くなる場合があります。
私はOxygenOfficeを、CentOS5.2(x86_64)にて利用しています。

それと、関係無いとは思いますが、念のため、OOoを起動する際、
kernel.exec-shieldを0、selinuxのモードをPermissiveに設定してみてください。

全てを削除後、再インストールするが、、、

horimoto (2008-09-08 00:46:35 (月))

yum remove openoffice* としてrpmでインストールされたファイル群を一切合切削除して、新しくダウンロードしたOOo_2.4.1をrpmコマンドでインストールした。

結果はやはり繰り返しであった。
例えばcalcを選択起動した場合、約20〜30秒間calcの無題画面を表示する。
放置しておくとファイルを修復するというメッセージがでて最初の記事にある内容のごとく修復を聞いてくる。

CentOS5.2,Fedora8,Fedora9のOS側にOOoと相容れないアップデートがあったのだろうか?

IssueTrackerの似た報告

M.Kamataki (2008-09-08 10:53:27 (月))

Fedora9とOOo2.4.1の組み合わせで以下の報告があります。回答されている開発の方はバグ報告(おそらくクラッシュレポート)やクラッシュが再現するファイルを添付するよう求めています。OpenOffice.orgをコマンドラインから起動し、Issueと同じようなメッセージが標準出力画面に表示されていたら、このIssueに報告されてみたらどうでしょう。

open office spreadsheet crashes :
http://ja.openoffice.org/issues/show_bug.cgi?id=90678

気になるIssue

M.Kamataki (2008-09-08 11:18:54 (月))

IssueTrackerで、今回ご報告のケースと同じかどうかわかりませんが、気になるものもありました。こちらもご覧になっていただけますか。

Segmentation fault when opening Writer 2.4.1 in 16-bit display :
http://ja.openoffice.org/issues/show_bug.cgi?id=90670

yum remove だと残存してるかも

Kuma (2008-09-08 16:10:02 (月))

Fedora8のOOo-2.3パッケージがすべて削除出来ず、何か残っていて、公式版OOo-2.4.1のインストールパッケージに悪さしているのではないですか?

以前に「# yum remove 」でFedora版のパッケージを全削除したつもりが、1個残されていて、公式版のインストールがうまくいかない事がありました(horimotoさんの現象ではなかったが)。

「$ rpm -qa | grep openoffice」で、本当に残存ファイルが無いか否かを確認されてはどうでしょう。

調査

Tora (2008-09-08 18:11:13 (月))

まず、「アプリケーション」「アクセサリ」「Gnome端末」などで、ターミナルエミュレーターソフトを起動していただけませんでしょうか。

調査A
A1. 以下のコマンドで、OpenOffice.org のプロセスの有無の確認
 ps -ef -w -w | grep soffice | grep -v grep

A2. 上記の調査1にて、soffice もしくは soffice.bin が動作していた場合、以下のコマンドにて、それ(それら)を強制終了。
 pkill -9 soffice

A3. 以下のコマンドで、OpenOffice.org を起動し、回復処理がまだ繰り返されてしまうか確認する。
 /opt/openoffice.org2.4.1/program/soffice

A4. ダイアログなどを表示することもできずにいきなり異常終了するような場合、多くの場合、ターミナルエミュレーター上に、一行もしくは複数行のエラーメッセージを出力するようにソースコードが記述されています。
何らしかのメッセージが出力されていますでしょうか。そのメッセージはどのような内容でしょうか。

調査B
B1. 以下のコマンドで、何らしかのファイル名が出力されますでしょうか。ファイルの所有者が自アカウントではない(rootや他人)などのファイルがあれば報告してくれます。
 find ~/.openoffice.org2 \! -uid `id -u` -ls
 find ~/.openoffice.org2.0 \! -uid `id -u` -ls

B2. もし、何かしらのファイルが出力されましたら、以下のようなコマンドなどでディレクトリ名を変更するなどして、削除したと同じような状況を作り出し、再び OpenOffice.org を起動してみます。
 mv ~/.openoffice.org2 ~/.openoffice.org2-backup-01
 /opt/openoffice.org2.4.1/program/soffice

調査C
それでもまだおかしいようでしたら、
C1. OpenOffice.org が起動している状況で、以下のコマンドにて環境変数 HOME ディレクトリの設定値を確認してみると、自身のホームディレクトリを示していますでしょうか。
 strings /proc/`pgrep -x soffice.bin`/environ | grep HOME

C2. もしも、自身のホームディレクトリを示していないようでしたら、その理由を検討してみてください。
OpenOffice.org 2.4.1 版は、$HOME/.openoffice.org2 配下に、各種の設定ファイルを作成します。
もしも、その $HOME が root ユーザーなどの他人のホームディレクトリを示していますと、各種設定ファイルの読み出しや書き込みができないので、OpenOffice.org は、即座に異常終了するよう作られています。

調査D
それでもまだおかしいようでしたら、
D1. ホームディレクトリ上に作成されている以下のファイルの内容を拝見できませんでしょうか。えっとつまり、こちらのページに添付いただけませんでしょうか。
 .crash_report_preview (エラーレポートとして開発側へ送信する場合のその内容のプレビュー。システムに関する情報(OS名、OSのバージョン、OpenOffice.org のビルド番号、クラッシュしたときのシグナル値、など)に加えて、以下の二つのファイルの内容を含んでいます)

上記のファイルの内容を確認し、途中部分には以下のファイル .crash_report_frames がそっくりとコピーされているはずです。さらに、その後半部分には以下のファイル .crash_report_checksum の内容がそっくりとコピーされているはずです。
クラッシュすると、まず以下の二つのファイルが作成されます。その後、それらの内容を元にして上記のファイルを作成するように作られています。
通常は、上記のファイルひとつあれば、問題箇所の絞込みが可能です。が、今回のように回復処理を繰り返しているような不安定な状況では、上記のファイルの内容と以下のファイルの内容が一致していない場合もあるかと思います。もしそのような状況でしたら、以下のファイルについても、こちらのページへ添付いただけませんでしょうか。
 .crash_report_frames (クラッシュしたときのスタックトレース情報)
 .crash_report_checksum (各スタックのフレームが所属している .so ファイルの md5 チェックサム値)

「更新のチェック」機能

Tora (2008-09-08 21:31:12 (月))

>以上、こんな感じなのですが、9月5日にCentOS5.2+GNOMEな環境で事態を目撃後、 Fedora8,Fedora9でも同様の症状に見舞われています。これはら別々のハードウェアで構成もバラバラです。
>ただ、OOo 2.4.1というのだけが一致しています。

という、ある日を境にして問題が複数のコンピュータ上で発生するようになったというような状況から、ひとつ気になる点としては、「更新のチェック」機能があげられるかと思います。

現在の自身のバージョン情報を OpenOffice.org の Web サーバーに送信し、さらに新しいバージョンの OpenOffice.org の有無を問い合わせるという機能です。
その仕組みについて詳しくは、
faq/4/1081 OpenOffice.org本体のオンライン更新について

そのオンライン更新のシステムに関連して、OpenOffiec.org 3.0 のリリースまでにはと、Bouncer と呼ばれる、ダウンロードサイトを自動的に紹介するシステムについて、現在開発側で機能追加の作業が行われているようでして、、、その作業の影響の余波を受けているとか。

その他にも、何か気になる点は、ありますでしょうか。

「更新のチェック」機能

horimoto (2008-09-09 01:11:49 (火))

これは、ONにしています。
CentOSなどで付随してくる2.3.xの場合には今回の症状が出ていないようなので、もしかしたら、こういう問題もあるのかもしれませんね。

調査の結果

horimoto (2008-09-09 01:36:14 (火))

詳細な調査方法の紹介ありがとうございます。
Fedora8+GNOME+OOo2.4.1(クリーンインストール済み)
で調査を行った結果を報告致します。

調査Aの結果:
なんらメッセージは表示されませんでした。
なお、Screenshotを添付いたします。これらの繰り返しになります。

調査Bの結果:
.openoffice.org2のみが存在し(2.0は無い)、このディレクトリの中に該当するファイルは存在しませんでした。

調査Cの結果:
$ strings /proc/`pgrep -x soffice.bin`/environ | grep HOME
OPENOFFICE_MOZILLA_FIVE_HOME=/opt/openoffice.org2.4/program
HOME=/home/horimoto
正常な期待通りの結果と思われます。

調査Dの結果:
添付致します。

よろしくお願い致します。

解析結果

Tora (2008-09-09 05:26:16 (火))

調査結果、ありがとうございます。

以下に解析結果を示します。

解析A
file_crash_report_preview が含んでいる内容が、file_crash_report_frames および file_crash_report_checksum の内容と一致していることを確認。
 sdiff _crash_report_frames _crash_report_preview | less
 sdiff _crash_report_checksum _crash_report_preview | less

結果良好。

解析B
ファイルの md5 チェックサム値の確認
 <errormail:Checksum sum="0xDD5E51C3EC35A9E7B8CD6B004F213E14" bytes="1789824" file="libuno_sal.so.3"/>
 <errormail:Checksum sum="0xDAAD8D6331E4B68BFF0E2A4D07E98A16" bytes="1483552" file="libucpdav1.so"/>

OpenOffice.org のコミュニティからリリースされた OpenOffice.org 2.4.1 Linux 版の同ファイルの md5sum 値と一致していることを確認。

結果良好。

解析C
クラッシュの原因を示している値を確認
 <officeinfo:officeinfo xmlns:officeinfo="http://openoffice.org/2002/officeinfo" build="680m17(Build:9310)" platform="unxlngi6.pro" language="" exceptiontype="11" product="OpenOffice.org 2.4" procpath="/opt/o
penoffice.org2.4/program/"/>

exceptiontype="11" は、man -s 7 signal によると、"SIGSEGV 11 Core Invalid memory reference" であることを確認。

結果良好。

解析D
スタックトレースの内容の確認
 <errormail:StackInfo pos="0" ip="0xcb0a24" rel="0x1fa24" name="libuno_sal.so.3" path="/opt/openoffice.org2.4/program/"/>
 <errormail:StackInfo pos="1" ip="0xcb1308" rel="0x20308" name="libuno_sal.so.3" path="/opt/openoffice.org2.4/program/"/>
 <errormail:StackInfo pos="2" ip="0x110400" rel="0x400" name="" ordinal="__kernel_sigreturn+0x0"/>
 <errormail:StackInfo pos="3" ip="0x112b91b" rel="0x2491b" name="libc.so.6" path="/lib/"/>
 <errormail:StackInfo pos="4" ip="0x112a753" rel="0x23753" name="libc.so.6" path="/lib/" ordinal="dcgettext+0x43"/>
 <errormail:StackInfo pos="5" ip="0x1177119" rel="0x70119" name="libc.so.6" path="/lib/" ordinal="__strerror_r+0x119"/>
 <errormail:StackInfo pos="6" ip="0x1176f75" rel="0x6ff75" name="libc.so.6" path="/lib/" ordinal="strerror+0x35"/>
 <errormail:StackInfo pos="7" ip="0x41997cd" rel="0x9b7cd" name="libucpdav1.so" path="/opt/openoffice.org2.4/program/"/>

解析結果E
libucpdav1.so 内において、何かしらのシステムコールの呼び出しに対してエラー値が返され、そのエラー値に対応するエラーメッセージを取得するために strerror() 関数を呼び出し、それがマルチスレッドセーフ版の strerror_r を呼び出し、それが、 /usr/lib/locale/ja_JP.utf8/LC_* に含まれている日本語メッセージの文字列の取得を試みたところで、メモリアクセス違反 SIGSEGV が発生し、カーネルに飛び、シグナルハンドラとしてあらかじめ登録しておいてある libuno_sal.so.3 内のハンドラを呼び出し、それが、このスタックトレースの内容を生成した。

libucpdav1.so は、ucb というプロジェクトに所属していて、WEBDAV および http:// のアクセスを司っている。
http://ucb.openoffice.org/docs/ucp-ref/webdav-ucp.html

解析結果からわかったこと
・libucpdav1.so 内のどの関数におけるどのシステムコールにてどのようなエラーが発生したのか、確認が必要。
・strerror は Linux のディストリビューション側から提供されている機能であり、その strerror(int 数値) 関数の呼び出しによって SIGSEGV が発生してしまう、つまりクラッシュしてしまうというのは、通常では考えられません。もしかしたら、ここの処理に来るよりも前の別の箇所においてメモリ上のデータを破壊してしまっているなどして、その破壊されたデータを信じて動作して、メモリアクセス違反などとしての症状となっているのかもしれません。
・$HOME/.openoffice.org2 の削除後に OpenOffice.org を起動すると、ライセンス認証などを行った後、数秒後に「更新のチェック」を行っているようです。この「更新のチェック」の動作が引き金になっている可能性が考えられます。

「更新のチェック」関連の調査

Tora (2008-09-09 06:06:28 (火))

調査F
OpenOffice.org 2.x では、「更新のチェック」の動作の一番最初に、以下のような GET アクセスを行います。その動作がお使いの環境においてはどのように動くのか確認してみましょう。
User-Agent: ヘッダで自身のバージョンなどを示し、http://update24.services.openoffice.org/ProductUpdateService/check.Update へアクセスしています。

1. プロキシーサーバーの IP アドレスおよびポート番号を以下のような環境変数にて設定します。
 export http_proxy="http://192.168.1.1:8080"

2. tcpdump コマンドにて、通信内容を取得するように仕掛けておきます。port の次の数値 8080 についてはお使いの HTTP プロキシーサーバーのポート番号を指定します。-s 1500 は、MTU 値が通常 1500 オクテットですので、パケットの内容を全部ログに記録してね。という意味で付けてみました。

/usr/sbin/tcpdump -w tcpdump.log -s 1500 port 8080


3. 問題が発生する Linux 上で、以下のようなコマンドにて模倣してみます。以下の User-Agent の内容では、OpenOffice.org 英語版を模倣しています。
以下の行にコピー&貼り付けのミスがありました。こちらのコマンド行ではなく、後述のコマンド行をご参照くださいますようお願いいたします。
 wget -O output_240.dat '--header=User-Agent: OpenOffice.org 2.4 (680m12(Build:9286); Linux; x86; BundledLanguages=en-US)' %%'http://update24.services.openoffice.org/ProductUpdateService/check.Up2008-09-09pkgfmt=rpm'%%
 wget -O output_241.dat '--header=User-Agent: OpenOffice.org 2.4 (680m17(Build:9310); Linux; x86; BundledLanguages=en-US)' %%'http://update24.services.openoffice.org/ProductUpdateService/check.Up2008-09-09pkgfmt=rpm'%%

4. 手順3 にて取得したログの内容は、どのようになっていますでしょうか。
 gunzip -dc output_240.dat | perl -pe 's{><}{>\n<}g; END{print "\n"}'
 gunzip -dc output_241.dat | perl -pe 's{><}{>\n<}g; END{print "\n"}'
 
それぞれ、以下のような内容が表示されるでしょうか。以下の内容は、OpenOffice.org 英語版において実行した出力です。

OpenOffice.org 2.4.0 のふりをして実行すると、新しいバージョンがありますよ。というような回答が届く。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-US">
<title>Product Update Feed</title>
<link rel="alternate" type="text/html" href="http://update.services.openoffice.org/ooo/snapshot.html"/>
<updated>2008-06-02 09:31:17.0</updated>
<author>
<name>The OpenOffice Project</name>
<uri>http://openoffice.org</uri>
<email>updatefeed@openoffice.org</email>
</author>
<id>urn:uuid:dca7ee97-a62d-4724-b18f-866e28e87fad</id>
<entry>
<title>Update available</title>
<link rel="alternate" type="text/html" href="http://update.services.openoffice.org/ooo/snapshot.html"/>
<id>urn:uuid:c460138e-e466-476b-ab95-2a9970f9ab73</id>
<category term="OpenOffice.org_2_en-US" label="OpenOffice.org_2_ update" />
<updated>2008-06-02 09:31:17.0</updated>
<summary>
</summary>
<content type="application/xml">
<inst:description xmlns:inst="http://installation.openoffice.org/description">
<inst:id>OpenOffice.org_2_en-US</inst:id>
<inst:version>2.4.1</inst:version>
<inst:buildid>9310</inst:buildid>
<inst:os>Linux</inst:os>
<inst:arch>x86</inst:arch>
<inst:update type="application/octet-stream" src="http://openoffice.bouncer.osuosl.org/?product=OpenOffice.org&amp;os=linuxintel&amp;lang=en-US&amp;version=2.4.1"/>
<inst:relnote pos="4" src="http://update.services.openoffice.org/ooo/index.html?cid=920900" />
</inst:description>
</content>
</entry>
</feed>


OpenOffice.org 2.4.1 のふりをして実行すると、新しいバージョンはありませんよ。というような回答が届く。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-US"/>


5. 手順2 の tcpdump コマンドについては、Ctrl-C キーにて、終了させます。

6. 以下のコマンドなどにて、手順2 で取得しておいた通信内容のログを表示してみます。
 /usr/sbin/tcpdump -w tcpdump.log -X


調査G
もし、上記の調査F 手順4 のような結果にならない場合は、貴社のネットワーク管理部門などに対して、HTTP のプロキシーサーバーなどで、どのような制限などを行っているのか、問い合わせてみるとよいかと思います。

それはそれとして、プロキシーサーバーなどから返される内容が OpenOffice.org が期待している内容ではない場合に OpenOffice.org がクラッシュしてしまうというのは、それはそれで問題であると思います。
プロキシーサーバー関連の不具合であると絞り込めた場合は、今度は OpenOffice.org 側にてどのよう改善するべきか、検討してみたいと思います。

「自動的に更新をチェック」を停止させるには

Tora (2008-09-09 06:41:18 (火))

調査H
「ツール」「オプション」「OpenOffice.org」「オンライン更新」の「自動的に更新をチェック」(規定値ではオン)をオフにするには、

1. ファイル $HOME/.openoffice.org2/user/registry/data/org/openoffice/Office/Jobs.xcu をコピーするなどして、原本を取っておく

2. 同ファイルをエディタなどで開き、以下の項目 AutoCheckEnabled の値 <value>true</value> を <value>false</value> に書き直す。

3. OpenOffice.org を起動する。

参考: Jobs.xcu の内容の例

<?xml version="1.0" encoding="UTF-8"?>
<oor:component-data xmlns:oor="http://openoffice.org/2001/registry" xmlns:xs="http://www.w3.org/2001/XMLSchema" oor:name="Jobs" oor:package="org.openoffice.Office">
 <node oor:name="Jobs">
  ...(中略)...
  <node oor:name="UpdateCheck">
   <node oor:name="Arguments">
    <prop oor:name="AutoCheckEnabled" oor:type="xs:boolean">
     <value>true</value>
    </prop>
  ...(後略)...

解析結果

horimoto (2008-09-09 21:55:47 (火))

詳細な解析結果の紹介をありがとうございました。
大変勉強になりました。さて、その結果をもとに自動更新関係の調査Fなのですが、こちらではproxyを使用していないので、直接80番を監視することにしました。

しかしながら、wgetの方ですでにタイムアウトだったり404エラーだったり。

$ wget -O output_240.dat '--header=User-Agent: OpenOffice.org 2.4 (680m12(Build:9286);Linux; x86; BundledLanguages=en-US)' 'http://update24.services.openoffice.org/ProductUpdateService/check.Up2008-09-09pkgfmt=rpm'
--21:43:15--  
http://update24.services.openoffice.org/ProductUpdateService/check.Up2008-09-09pkgfmt=rpm~
          => `output_240.dat'
update24.services.openoffice.org をDNSに問いあわせています... 192.18.197.109~
update24.services.openoffice.org|192.18.197.109|:80 に接続しています... 接続しました。~
HTTP による接続要求を送信しました、応答を待っています... 404  /ProductUpdateService/check.Up2008-09-09pkgfmt=rpm ~
21:43:29 エラー 404: /ProductUpdateService/check.Up2008-09-09pkgfmt=rpm。~


これは404エラーの状態。
もちろん、この書き込みをしているくらいだからネットワークへは接続できているはずです。

コマンド行の訂正

Tora (2008-09-09 22:20:12 (火))

すみません。wget コマンドのパラメーターについて、コピー&貼り付けに誤りがありました。正しくは、以下のコマンドをご参照お願いいたします。

wget -O output_240.dat '--header=User-Agent: OpenOffice.org 2.4 (680m12(Build:9286); Linux; x86; BundledLanguages=en-US)' 'http://update24.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm'
wget -O output_241.dat '--header=User-Agent: OpenOffice.org 2.4 (680m17(Build:9310); Linux; x86; BundledLanguages=en-US)' 'http://update24.services.openoffice.org/ProductUpdateService/check.Update?pkgfmt=rpm'


gunzip -dc output_240.dat | perl -pe 's{><}{>\n<}g; END{print "\n"}'
gunzip -dc output_241.dat | perl -pe 's{><}{>\n<}g; END{print "\n"}'

別の要因かもしれませんね。

Tora (2008-09-09 22:36:17 (火))

proxyを使われていないということですので、別の要因かもしれませんね。

・そちらの環境において、複数のコンピューター CentOS5.2、Fedora8、Fedora9 上で問題が発生している。
・他の多くの人達からは同様な問題は今のところ報告されていないようだ。

共通点は、OpenOffice.org 2.4.1、RedHat の流れの Linux ディストリビューション、インストールなどの作業をされているのが horimoto さん。ということでしょうか。

インストールを行ったのは

horimoto (2008-09-09 22:47:51 (火))

私だけじゃないのです。
自宅の分と会社のデスクの分は自分なのですが、会社で他の人たちは自身でインストールを行っています。もちろん、概ねの方法は雛形(文章ではないですが)があるのですが、細かい部分は十人十色で行っています。OOoは公式サイトからダウンロードしてくる。とか。

コマンド行の訂正の結果

horimoto (2008-09-09 23:10:08 (火))

output_240.datの出力は空白。
output_241.datの出力は、

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-US"/>


と、なりました。

Re: コマンド行の訂正の結果

Tora (2008-09-09 23:23:55 (火))

ありがとうございます。

結果は正常のようです。

出力が空白になることが、たまにあるようです。Web サーバー側が全世界中からのアクセスにあっぷあっぷしているなどで、とりあえず、内容無し、その空っぽの内容を gzip した結果の 20バイト程度を返してくるという場合が、よく見掛けられます。再度アクセスすれば、何回かに一回は有意義な情報が戻ってくることがあるようですから。

というわけで、「出力が空白」については、サーバー側の話であって、こちら側に不具合があるというわけではないと思います。

デバッグ用の .so ファイルをビルドしてみました。

Tora (2008-09-09 23:24:22 (火))

調査I
上記の解析Dでは、libucpdav1.so については、関数名が取得できていません。それは、他の .so ファイルなどから呼び出される関数ではなく、この .so ファイルの中だけで呼び出される関数だからだと思います。

<errormail:StackInfo pos="4" ip="0x112a753" rel="0x23753" name="libc.so.6" path="/lib/" ordinal="dcgettext+0x43"/>
<errormail:StackInfo pos="5" ip="0x1177119" rel="0x70119" name="libc.so.6" path="/lib/" ordinal="__strerror_r+0x119"/>
<errormail:StackInfo pos="6" ip="0x1176f75" rel="0x6ff75" name="libc.so.6" path="/lib/" ordinal="strerror+0x35"/>
<errormail:StackInfo pos="7" ip="0x41997cd" rel="0x9b7cd" name="libucpdav1.so" path="/opt/openoffice.org2.4/program/"/>


つまり、その関数名(シンボル名)が .so ファイル中に含まれていないということです。他の .so ファイルなどから呼び出されないのであれば、ディスク容量削減、実行時のシンボル名解決に要する検索時間の短縮などのために、製品出荷時にはそのような「内輪」のシンボルについては .so には含めないようにするわけです。

では、このようなエラーレポートでは解析が手詰まりしてしまうのか、というとそうでもないのです。相対番地である rel="0x9b7cd" はわかりますので、マップファイルというシンボル名と相対番地の一覧表と照らし合わせることによって対象の関数名を把握できます。そのマップファイルはビルド作業をすると自動的に作成されます。ですので、OpenOffice.org の公式版をビルドしている開発側ではそのマップファイルを使って解析を行えるわけです。

しかしながら、そのマップファイルは一般には公開されていません。そのため、その番地がどの関数に所属しているのか、こちらではわかりかねるというわけです。

そこで、デバッグ用に同 .so ファイルをこちらでビルドしてみました。
本ページに添付いたします。

#ref(): File not found: "libucpdav1.so.1.1" at page "faq/4/1226"


1. 上記の同名のファイルを差し替える。
2. OpenOffice.org を起動する。
3. 本問題が発生してクラッシュする。
4. ホームディレクトリ内に作成される .crash_report_preview のスタックトレースの libucpdav1.so の行には、今度は ordinal="関数名+相対アドレス" が記録される、はず。

差し替える手順
どのような方法でも良いですから、同名の原本ファイルを退避しておいて、上記のファイルをそこに置きます。
例えば以下のような方法で。
1. cd /opt/openoffice.org2.4.1/program
2. mkdir ORIGINAL
3. mv libucpdav1.so.1.1 ORIGINAL
4. cp ダウンロードしたディレクトリ/libucpdav1.so.1.1 .

元に戻す手順
5. rm libucpdav1.so.1.1
6. mv ORIGINAL/libucpdav1.so.1.1 .

さて、上述のように、関数名を取得できるように細工を掛けておいて、OpenOffice.org を起動してみると、関数名などの情報が取得できましたでしょうか。

ファイルの復元方法

Tora (2008-09-09 23:41:29 (火))

libucpdav1.so.1.1 のファイルサイズがファイル添付できる上限サイズであります 1MB を超えてしまっていましたので、そのままではファイル添付できませんでした。

そこで、ZIP圧縮し、さらに、二つのファイルに分割し、ファイル添付いたしました。

元に戻すには、
1. 次の二つのファイルをダウンロードします。libucpdav1.so.1.1.zip_aa libucpdav1.so.1.1.zip_ab 
2. cat コマンドでそれらのファイルを結合します。
 cat libucpdav1.so.1.1.zip_aa libucpdav1.so.1.1.zip_ab > libucpdav1.so.1.1.zip
3. unzip します。
 unzip libucpdav1.so.1.1.zip
4. md5sum値を確認します。
 md5sum libucpdav1.so.1.1
 9d4bbf68bf4f2c11bb37247662dac5fc libucpdav1.so.1.1
5. ファイルサイズを確認します。4590267 バイトです。
 ls -lL libucpdav1.so.1.1

デバッグ用libucpdav1.so.1.1を使ってみました。

horimoto (2008-09-10 00:02:17 (水))

そして、AutoCheckEnabledをtrueにして起動してみました。
エラーがでました。その時の.crash_report_*なファイルを添付します。
前のと混ざるとわからなくなるので、最後に2をつけておきます。

デバッガで情報収集

Tora (2008-09-10 02:19:00 (水))

ありがとうございます。

拝見いたしました。ところ、あらら、取得できませんでしたね。すみませんでした。

お手数ですが、その .so ファイルを差し替えたままの状態で、一般ユーザーにてデバッガを仕掛けておいて、以下の手順などで情報収集してみていただけませんでしょうか。

1. gdb /opt/openoffice.org2.4/program/soffice.bin
2. (gdb) というプロンプトに対して、 run リターン。すると、OpenOffice.org が起動しはじめます。
3. 今回の不具合では、シグナルの 11 番である SIGSEGV というメモリアクセス違反が発生している状況ですから、たぶん、以下のような雰囲気のメッセージとともに、デバッガ(gdb)が、異常発生したことを通知してコマンド待ちになるかと思います。

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208915184 (LWP 2687)]
0x00f05402 in __kernel_vsyscall ()

4. ここで、bt リターン (bt とは、backtrace の省略形です)と入力すると、以下のような雰囲気のスタックトレース情報が表示されるかと思います。

(gdb) bt
#0  0x00f05402 in __kernel_vsyscall ()
#1  0x04946f01 in ___newselect_nocancel () from /lib/libc.so.6
#2  0x01ddd8af in SalXLib::Yield () from /opt/openoffice.org2.4/program/libvclplug_gen680li.so
#3  0x01deb29e in X11SalInstance::Yield () from /opt/openoffice.org2.4/program/libvclplug_gen680li.so
#4  0x00a508a3 in Application::Yield () from /opt/openoffice.org2.4/program/libvcl680li.so
#5  0x00a508f5 in Application::Execute () from /opt/openoffice.org2.4/program/libvcl680li.so
#6  0x08077add in desktop::Desktop::Main ()
...(省略)...

5. cont リターン。で、処理を続けさせる。すると、以下のような雰囲気のメッセージとともに、OpenOffice.org が終了したことが通知されるかと思います。ここの code の後ろの数値は何番になっていますでしょうか。

Program exited with code 0117.
(gdb) 

6. quit リターン。で、デバッガを終了します。

というわけで、今度こそ、異常が発生している関数名が表示されるかと思います。

さらに、以下のコマンドで、システムコールのログも別途取得してみていただけませんでしょうか。
7. strace -f -o strace.log /bin/sh /opt/openoffice.org2.4/program/soffice
8. もし、strace コマンドが終了してこないようでしたら、Ctrl-C キーで終了を試みてください。

gdb実施してみました。

horimoto (2008-09-10 08:28:20 (水))

シンボル情報が無いためのメッセージが大量に出力されましたが、それらも含めて、OOo-1-gdb.logに納めておきました。
しかし、パッとみる限り期待される情報があるのか疑問です。関数名が出ないです。libucpdav1.so.1.1は入れ替えたんですけれどね。libucpdav1.so内のいくつかの関数名が出力されているので多分入れ替えは成功していると思うのですが。。。

sh: crash_report: command not found

というのが気になります。しかし、これは問題が起こった後の問題ですから、今は目をつぶっていていいのかな。

それから、straceの方は、Ctrl-Cで終わらず、Ctrl-Zでkill %1してみましたが、それでも終わりませんでしたので、rebootしてログを固定しました。
4.3Mバイトほど有りましたので、圧縮してあります。(strace.log.bz2)

デバッグ用の新しい .so ファイル

Tora (2008-09-10 14:04:27 (水))

>しかし、パッとみる限り期待される情報があるのか疑問です。関数名が出ないです。libucpdav1.so.1.1は入れ替えたんですけれどね。libucpdav1.so内のいくつかの関数名が出力されているので多分入れ替えは成功していると思うのですが。。。

はい。そのようですね。
調べてみたところ、libucpdav1.so.1.1 には、 neon というソフトウェアが提供している libneon.a が、静的にリンクされていました。その neon 側のシンボル名がデバッガ上には表示されなかったというようなことではないかと考えられます。

そこで、neon についてもデバッグ用にビルドし直し、あらためて、libucpdav1.so.1.1 を作成してみました。
libucpdav1.so.1.1.bz2_no2_aa および libucpdav1.so.1.1.bz2_no2_aa です。復元の方法は、Tora (2008-09-09 23:41:29 (火)) と同様です。
md5sum は、964ccc511a35cbf425252c22263cb836 libucpdav1.so.1.1

neon
http://www.webdav.org/neon/

追加情報

Tora (2008-09-10 14:21:24 (水))

> sh: crash_report: command not found

については、上述の手順どおりにすると、そのように、command not found になります。

通常では、/opt/openoffice.org2.4/program/soffice という Shell スクリプトが環境変数 PATH に /opt/openoffice.org2.4/program などを加えてから、同ディレクトリ内の soffice.bin を起動しています。
そこのところを、今回は PATH 環境変数などを設定せずにいきなり soffice.bin を gdb 上で起動していますから、外部コマンドであります crash_report が見つからなかったというわけです。

gdb を起動する前に、PATH=${PATH}:/opt/openoffice.org2.4/program などとして PATH 環境変数に crash_report が含まれているそのディレクトリ名を追加しておくと、今度はそのようなエラー( system() 関数から出てきていると思います。 ) はでなくなると思います。

soffice.bin が、SIGSEGV などのシグナルを受けると、そのシグナルハンドラの中で、スタックトレース情報を .crash_report_frames および .crash_report_checksum に書き出しています。それら二つのファイルを open() しておいて、フレーム一つにつき、両方のファイルにそれぞれ一行ずつ書き出しています。

その後、system() 関数にて crash_report をこれらのファイル名をコマンドパラメータとして与えて起動し、 crash_report は、前述の二つのファイルの中身をつなげて .crash_report_preview に書き出しています。

soffice.bin が、SIGSEGV などのシグナルを受けると、そのシグナルハンドラの中で、スタックトレースなどの情報を /tmp/crxmlXXXXXX (XML形式のスタックトレース情報)、 /tmp/crstkXXXXXX (単純なテキスト形式のスタックトレース情報)、/tmp/crchkXXXXXX (そのフレームが属している共有ライブラリの md5 チェックサム値)、に書き出しています。それら三つのファイルを open() しておいて、フレーム一つにつき、それぞれのファイルにそれぞれ一行ずつ書き出しているわけです。

その後、system() 関数にて crash_report をそれらのファイル名をコマンドパラメータとして与えて起動します。

crash_report は、上述のファイルをコピーしたり、中身をつなげてたりして、ホームディレクトリ上に .crash_report_preview などのファイルを作成しています。

その後、soffice.bin は、exit(79) (10進数の 79 は、8進数で 0117) で終了し、soffice は、終了コードが 79 だったので、再び soffice.bin を起動します。

起動してきたときに、別途記録されている user/registry/data/org/openoffice/Office/Recovery.xcu 内の情報に沿って、ファイルの復元や、上記の .crash_report_preview を開発側へ送信するか、などの処理が行われます。

というような仕組みになっています。

少々誤記を訂正

Tora (2008-09-10 14:37:25 (水))

Tora (2008-09-10 14:21:24 (水)) の誤記を打ち消し線で消し、訂正いたしました。

strace.log の解析結果

Tora (2008-09-10 14:46:52 (水))

strace.log を拝見いたしました。less -N strace.log で見ています。左端の数値が行番号です。

/opt/openoffice.org2.4/program/versionrc の内容を読んでいますね。
このファイルには、自身のバージョン番号、ビルド番号などに加えて、「更新のチェック」の問い合わせ先の URL や、User-Agent: ヘッダの元ネタなどの情報も含まれています。
詳細は、faq/4/1081 OpenOffice.org本体のオンライン更新について

 4557 2963  open("/opt/openoffice.org2.4/program/versionrc", O_RDONLY|O_LARGEFILE) = 15
 4558 2963  read(15, "[Version]\nAllLanguages=ja\nbuildi"..., 79) = 79
 ...(中略)...


/opt/openoffice.org2.4/program/versionrc の修正日時を調べていますね。

 12581 2972  lstat64("/opt/openoffice.org2.4/program/versionrc", {st_mode=S_IFREG|0444, st_size=561, ...}) = 0
 12582 2972  access("/opt/openoffice.org2.4/program/versionrc", F_OK) = 0


/opt/openoffice.org2.4/program/libucpdav1.so が読み込まれました。

 12583 2972  open("/opt/openoffice.org2.4/program/libucpdav1.so", O_RDONLY) = 45
 ...(中略)...


/opt/openoffice.org2.4/share/registry/modules/org/openoffice/Inet を読んでいますね。
このファイルには、プロキシーサーバーに関する情報などが記録されています。

 12594 2972  open("/opt/openoffice.org2.4/share/registry/modules/org/openoffice/Inet", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = -1 ENOENT (No such file or directory)
 ...(中略)...


ソケットを IPv6 で作成しようと試みて、EAFNOSUPPORT で失敗していますね。

 12618 2972  socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)


そして、SIGSEGV (メモリのセグメンテーションに関する違反) が発生しました。

 12619 2972  --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 ...(中略)...


スタックトレース情報を書き出しています。

 12622 2972  open("/tmp/crxmltKbFeA", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 45
 12623 2972  open("/tmp/crstk8HG93v", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 46
 12624 2972  open("/tmp/crchkp70ETr", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 47


というわけで、IPv6 関連で、何か思い当たるふしはありますでしょうか。

strace の止め方

Tora (2008-09-10 16:15:46 (水))

strace のログについては、今のところ、十分な情報がとれたので、再び行う必要はありませんが、一応、念のため、、、

>それから、straceの方は、Ctrl-Cで終わらず、Ctrl-Zでkill %1してみましたが、それでも終わりませんでしたので、rebootしてログを固定しました。

はい。たまに状況によっては、そのようになったりします。すみません。詳しく書かなかったために、リブートまでさせてしまって。

strace が Ctrl-C で終了しなかった場合、多くの場合、そのトレース対象のプロセスを終了させると、strace も終了してくるようです。

strace を Ctrl-Z で一時停止し、kill -9 %1 を何回実行しても、strace が終了してくれなかったりします。そのような場合、今回では、soffice.bin や soffice シェルスクリプトを実行している /bin/sh などを kill -9 し、fg で strace をフォアグランドに戻すと、ほっ、終わった。となるかと思います。

つまるところ、以下のように、トレース対象を先に kill し、続いてトレーサー starce を kill すると、たいていの場合、両プロセスとも終了してくれるかと思います。
pkill -9 soffice
pkill -9 strace

IPv6

horimoto (2008-09-10 17:48:24 (水))

いわゆる、disableというか、まったく存在していません。
ifconfigででも微塵も表れないようにしています。
net-pf-10 offって感じです。

Re: IPv6

Tora (2008-09-10 19:55:13 (水))

>いわゆる、disableというか、まったく存在していません。

それが引き金かなぁ。

こちら(Fedora Core 6上)で、strace 経由で OpenOffice.org 2.4.1 を起動し、「ヘルプ」「更新のチェック」を行わせてみたところ、PF_INET6 については、以下のようになりました。

32395 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 35
32395 close(35)                         = 0


一方、添付してくださいました strace.log には、同様なシステムコールに対して、以下のようにエラーが発生したことが記録されています。

2972  socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = -1 EAFNOSUPPORT (Address family not supported by protocol)


以下の Issue で、neon が IPv6 をサポートするようにと、OpenOffice.org 2.0 の頃に機能追加が行われているようです。
OOo's HTTP/WebDAV implementation does not support IPv6
http://qa.openoffice.org/issues/show_bug.cgi?id=33615

まあ、IPv6 に関する機能を全面的に抑止しているとのことですから、上記のようにシステムコールがエラーなるのはいいとしまして、
さて、そのエラーに対応するメッセージを取得しようと、strerror() を呼びにいき、そして SIGSEGV となってクラッシュするというのは、納得がいきませんねぇ。

デバッガの操作ログ OOo-1-gdb.log によると、なにやら、怪しいメッセージが gdb から報告されていますね。

(gdb) bt
...(中略)...
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


デバッグ情報入りの libneon.a をリンクしたデバッグ用 libucpdav1.so.1.1 を使った gdb による解析待ちでしょうか。

バックトレース(スタックトレース)
(gdb) bt

に加えて、組み込まれている共有ライブラリファイルに関する情報についても、取得してみていただけませんでしょうか。
(gdb) info sharedlibrary

ちょっと待っててください。

horimoto (2008-09-11 02:34:00 (木))

現在、本業のトラブルで手が一杯になっております。11日中には調査を再開できると思います。

Re: ちょっと待っててください。

Tora (2008-09-11 13:49:14 (木))

お手すきのときで、ぜんぜん構いませんので、あまりお気になさらないでください。

とりあえず、AutoCheckEnabledを false に書き換えておけば、問題は発生しなくなっていることでしょうから。

ところで、どのようにすると、IPv6 を完全に葬り去ることができますでしょうか。インストール時の選択肢などでチェックを外すなどの手順でよろしいのでしょうか。もし、その手順が簡単そうでしたら、こちらで VMware 上で再現用の環境を作ってみようかとも思いますが・・・

我流IPv6取外し

horimoto (2008-09-12 00:16:37 (金))

正確なものかどうかはわかりません。また、OSの中ではヒソヒソとうごめいているかもしれません。
私は、

  • /etc/modules.conf で net-pf-10をoffにする。
  • ip6tablesをdisableにする。
  • /etc/sysconfig/network で NETWORKING_IPV6=no にする。
  • dhcpv6-clientをけす。

    程度のことですかね。

デバッグ用 libucpdav1.so.1.1のmd5sumが不一致

horimoto (2008-09-19 01:10:52 (金))

題名どおりなのですが、libneon.aを組み込んだlibucpdav1のmd5sumが

md5sum libucpdav1.so.1.1
81ff5085cf7255715a1737a0374f9da9  libucpdav1.so.1.1


こんな感じで違っています。当然、catでつなげてからbzip2 -dしています。

Re: デバッグ用 libucpdav1.so.1.1のmd5sumが不一致

Tora (2008-09-19 17:55:35 (金))

すみませんでした。Tora (2008-09-10 14:04:27 (水)) にて私がコピー&貼り付けしたファイルのその値は、誤っていたようです。

手元のファイルにて今一度確認してみたところ、horimoto (2008-09-19 01:10:52 (金)) さんの md5sum 値と、手元のファイルのそれとが一致しています。

よって、そのファイルをお使いになってくださって問題ありません。

>もし、その手順が簡単そうでしたら、こちらで VMware 上で再現用の環境を作ってみようかとも思いますが・・・

といいつつ、こちらでは、まだ、手をつけておりませんでした。

neonライブラリによるgdb結果

horimoto (2008-09-19 23:29:53 (金))

動作結果に変化はなく(予定どおり)btとinfo sharedlibraryの結果をOOo-2-gdb.logを添付しておきます。

お名前:
題名:


添付ファイル: fileOOo-2-gdb.log 435件 [詳細] filelibucpdav1.so.1.1.bz2_no2_ab 422件 [詳細] filelibucpdav1.so.1.1.bz2_no2_aa 386件 [詳細] filestrace.log.bz2 413件 [詳細] fileOOo-1-gdb.log 443件 [詳細] file_crash_report_preview2 429件 [詳細] file_crash_report_frames2 405件 [詳細] file_crash_report_checksum2 415件 [詳細] filelibucpdav1.so.1.1.zip_ab 433件 [詳細] filelibucpdav1.so.1.1.zip_aa 408件 [詳細] file_crash_report_preview 441件 [詳細] file_crash_report_frames 423件 [詳細] file_crash_report_checksum 438件 [詳細] fileScreenshot-OpenOffice.org 2.4-1.png 303件 [詳細] fileScreenshot-OpenOffice.org 2.4.png 264件 [詳細]