予期せぬエラーですぐにダウン

10.2.6のComboアップデートを当て直す以外に何も思い付きませんが、Real Playerのクラッシュログにはdual processorの処理が見え(MP何とか)、固有の不具合なのかと思ったりもするので、Real側に報告するのも良いのかもしれません。
# ま、dual processor機なので、大抵のクラッシュログに出ているでしょうけど、MP何とか。
## 大抵 Thread n Crashed: と出ると思いましたが、出てませんね。
後は、何かの傾向を掘り下げて見つけて対処方法を探るとか。

＞# ま、dual processor機なので、大抵のクラッシュログに出ているでしょうけど、MP何とか。
Multiprocessing Serviceを使っているから見えているラベルとか。
シングルプロセッサなうちのマシンに残ってるクラッシュログにもありますし。
参考：Threading Architectures

> Multiprocessing Serviceを使っているから見えているラベルとか。
あ、そうですね。Processor数とは直結しませんね。

> Exception: EXC_BAD_ACCESS (0x0001)
> Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
アクセスすべきでないメモリー領域にアクセスしているように見受けられます。開発中のプログラムを動かしたりするとよくありますが、世に出回っているソフトでは起こるはずのないエラーのように見えます。アップデートがきちんとできてないとか、メモリー不良とかが思い浮かびます。

装着純正(?)メモリ合計が、Mac OS X 10.2.6 環境下で256 MB 以下でないことを想定しています。
0x700や0x900で始まる”in semaphore_wait_signal_trap”、 ”_pthread_cond_wait” は、プログラム側に問題（ファイル損傷や消失を含む）がある場合や装着RAMに問題があると、ログに今回のようなメモリアクセスの例外処理エラーが検出されるときがあります。問題未解決の場合は、以下を提案させていただきます。原因の所在が特定のアプリケーションか、正常に機能していないMac OS X 10.2.6か、メモリの不調か、あるいはHDD の論理的損傷のいずれかを見極めた上で、場合によっては最終的な手続きを取ります。マシンの保証有効期間も再確認してください。
私の場合はシングルCPUですが、このやり方でメモリーが原因でも起きるクラッシュログ（semaphore_wait_signal_trapを含む）やエラーログをメーカーに提出して、すでに４枚交換してもらいました。さらに残る１枚も近日中に交換します。物理的には故障していない永久保証付き同一メーカーの品物でした。現在は解決に至っております。容量が同じものは最新型番で同一のチップメーカーで統一してもらいました。
OS10.2を使いはじめて間もないとの事ですので；
１．必要なら重要データをバックアップしておきます。例えば、Users/HOME/以下の８フォルダ（空フォルダはBackup不要）です。/Library/Internet Plug-Ins 内のフォルダやファイル、 /private/etc/hostconfig ファイルなども損傷することがあるのでバックアップされるとよいでしょう。マシンをアップルケア修理センターで精査してもらうことも考慮して、サードパーティ製品は予め全て取り外します。
２．Mac OS 9.2.2とMac OS X 10.2（10.2.1の場合もあり）のインストールCDが梱包されていると思います。 Mac OS 9.2.2 CDでマシン起動して、「ドライブ設定」の「全データゼロ」オプションを採用して、HDD を２パーティション又はそれ以上で再初期化します。「全データゼロ」オプションは、HDD の容量により相当の時間を要します。
３． Mac OS 9.2.2を第一パーティションにインストールしたら、テスト起動します。コントロールパネルの「ソフトウェア・アップデート」が要求する場合は、アップデートします。
４．Mac OS X 10.2 CDでマシン起動して、第２パーティションにインストールします。OS X の「ソフトウェア・アップデート」で要求されるアップデータをインストールします。アップデートが終了したら、「システム環境設定」の諸設定を行い、「クラッシック環境」が正常に起動するか試します。起動を確認したら、それを終了します。
５．次に、「ユーティリティ」ホルダ内のDisk Utility （又はその日本語名）を立ち上げ、「First Aid」タブの「Disk Permissionsの修復」を実行します。引き続き、「Disk 修復」を実行します。さらに、マシン再起動の際に、Command + S キーを同時に押し下げて、シングルユーザ・モードで行います。入力待ち状態で、fsck -y をタイプしてreturnキーを押し下げます。完了したら、rebootをタイプしてreturnキー押し下げで、マシンを通常起動させます。
６．サードパーティ製アプリケーション（OS X およびOS 9）はインストールしないで、常用されたいApple 製アプリケーションを1〜３日テスト運用します。この間、コンソールは常時立ち上げて、ログ内容に異変がないかを監視します。この段階で、予期せぬエラーやクラッシュが発生しない場合は、ステップ７と８へ進みます。
７．念のため、Apple Hardware Test CD （詳細オプション採用）で、内部純正ハードウェア（HDDは検査能力外）検査をします。
８．最も多くクラッシュが起きたアプリケーションから、１つずつインストールしては、再現性をチェックします。
問題が起きなければ、HDD の論理損傷または古いMac OS X 10.2.6 のオペレーティング・システム（損傷／消失など）に原因があったと考えられます。複数のアプリケーション（最新版で完全互換性のあることが条件）で再現する場合は、装着メモリ（又はロジックボード）に問題があるということになります。メモリーモジュールは、AHT CDテストに合格しても、相性や品質の問題が存在すると、morewaterさんのトラブルは起きることがあります。G4 1GHz Dual MDD でも斯様な事例を見たことがあります。
アップルケアに修理依頼をされる時には、問題解決のために実行された説明文書の他に、コンソール（PPC Thread State:に示されるCPUレジスターのエラー記述記録を含めること）ログやsystem.log コピーも添付されるとよいでしょう。

_pthread_cond_waitの上にくるsemaphore_wait_signal_trapは、
一つのタスク内に存在するpthread(MacOSXのスレッド機構の一つ)が、
共有しているあるメモリ空間へのアクセスを条件(condition)付きのセマフォ
(ある条件が満たされると開く扉のようなもの)により
休眠状態になっているこニを示しているものであって、
RAMなどの装置に異常があるかどうかと言うような事とは
無関係に登場するシンボルです。
クラッシュログを読む時には、このような休眠状態のスレッドは
無視して読むのが普通です。
さしずめ何かの問題がこのログを吐くよりずっと前に出たために
スレッド6でシステムコールを出して自殺しているのではと思います。
自ら落ちているためCrashedが出ないのかな、と

thumb さん、Real One Playerのクラッシュログですが、こうゆう風に解釈してよいですか；
RealOne Player によって用意されたメモリへのアクセス直前、マルチプロセッシングAPI ライブラリに何らかの問題（メモリ圧迫等のバグ、損傷又は消失）があり、タスクがアプリと同期できない。セマフォ経由のシグナル処理ができずロックされ、その結果 Critical Region はもう一方のプロセッサーによって実行されてしまい、戻り値エラーを返している。RealOne Player はイベントループの中でタスクの結果をチェックするも、エラーが返され、タスクは何も生成できない。 MPWaitOnSemaphore が指定されても、エラーが返されるため、PrivateMPEntryPoint を呼び出してシステムコールに至っている。Thread 1 では、 MPEnterCriticalRegionが不適切なタイムアウト値で呼び出されているため、システムクラッシュが起きたかもしれない。いずれにしても、semaphore_wait_signal_trap は、信号処理エラーの告知責任を果たしている。 典型的な症状は、アプリケーションやシステムレベルでのクラッシュ。
それで、RealOne Player がデュアルプロセッサー環境下で正常動作できない理由を推測してみると；
* RealOne Player .app に何らかの問題がある。例：無効タイムアウト値によりタスクがブロックされる。
* 必要なライブラリーファイルのバグ、損傷または消失。又は共有ライブラリーの損傷または消失。関連キャッシュ、Prefs、/Library/Internet Plug-Ins フォルダ内のPlugin は全て健全だろうか？
* Mac OS X システム側に一時的な要因があり、MP API Libraryがロードされない。
* VM 処理がうまく行われていない場合は、HDD の論理損傷も考慮した方がよいかもしれない。
* エラーコード -108が検出されていれば、RAM の動作環境に問題がある可能性が強い。エラーコードが検出されていなくても、あるRAM の耐性速度がマシンハードウェアの要求を満たしていないかもしれない。
---
ところで、最近 Safari 1.0 のスタンドアローン版を再インストールしたら、QuickTime Player 6.3 の Plug-ins はすべて消失されてしまいした。仕方なく、QTPも再インストールでした。morewater さんの方はそれらが健在でしょうか？早い解決を優先されるのでしたら、トラブルシューティングの第一歩は、システムの再インストールから攻めるという方法もあります。
関連情報（日本語版が存在する場合は同一文書番号でTIL で検索可能）：
Web Browser Quits Unexpectedly or Stops Responding - Article ID:106874
Software Restore: How to Use Restore Discs With Mac OS X 10.2 - Article ID:42929.
Mac OS X 10.2: Directory Issue Verification or Repair Is Not Part of Installation - Article ID:25505.

>マルチプロセッシングAPI ライブラリに問題があり、タスクがアプリと同期できない。
どう言う意味でしょうか。
とりあえずまず「アプリケーション」は、演算処理のまとまりを
ユーザの目に見えるようにイメージ化した偶像です。
システムにとってはそれはどうでもいいものです。
MacOSXという世界で「タスク」はカーネルから生み出された演算処理の器で、
アプリケーションとしてユーザに見えるものと見えないものがあります。
ただし、MacOS「」の世界ではタスクは演算処理の集合で、
基本的にはアプリケーションの一部分または全部を指しますが、
その範囲は曖昧で、スレッド=タスクである場合もあります。
>Critical Region はもう一方のプロセッサーによって実行されてしまい、
CriticalRegionはMacOS「」用語です。
複数のタスク(=スレッド)が並行して処理を進めていく中で、
その中の一つしか同時に実行することが許されない実行コードの集まりです。
どのプロセッサがそれを履行するかはどうでも良いものです。
どういう順番で処理を進めていくかを決めるスケジューラの動き次第で、
前半部分と後半部分が別のプロセッサで履行される可能性もありますし、
同じプロセッサを何十回も使って履行する場合もあります。
> MPEnterCriticalRegionが不適切なタイムアウト値で呼び出されているため、
> システムクラッシュが起きたかもしれない。
タイムアウトがどのような値であれ、直接クラッシュの原因とはなり得ません。
前にも書いた様にセマフォはタスク(=スレッド)と言う侵入者を
ブロックする扉のようなものです。このときの扉の中をCriticalRegionと呼び、
この中の部屋に入ることができるのは一つのタスク(=スレッド)だけです。
関数MPEnterCriticalRegion()は、扉のしまっている、
つまり他のタスク(=スレッド)が中に入っている時に、
それが出てくるまでしばらく待機して、もし待っている間に中のタスク(スレッド)が出てくれば、
自分が入って扉をロックする、出てこなければあきらめて帰ると言う関数です。
あきらめて帰ったからといってクラッシュにはなりません。
まあともかく、このクラッシュログから推測できることは、何もありません。
問題はこのログを吐くよりもずっと前に起きていると思われます。
あと余計なお世話ですが、長い文章を書く時には一つの段落であっても
適当な文字数で改行を入れる事をおすすめします。
改行の無い長い文はブラウザが自動で改行を入れ、テーブルやウインドウから
はみ出さない様にしてくれますが、これはコンピュータに余計な処理を増やし、
回線速度が遅いとなおさらですが、画面の描画やウインドウのリサイズ時の
フィードバックを遅くします。

> トラブルシューティングの第一歩は、システムの再インストールから
> 攻めるという方法もあります。
Systemの再Installは全てをリセットする事であって、決してトラブル
シューティングの第一歩ではないと私は思います。その方が速く解決し
てすっきりとする場合があるのは確かだとは思いますが「第一歩」とする
のはリプライとしてどうかと・・・(^^;

いやいや、安食さんは、
＞早い解決を優先されるのでしたら、トラブルシューティングの第一歩は、
＞システムの再インストールから攻めるという方法もあります。
と書かれていて、条件を限定した上でのひとつの手段を示したに過ぎないと思います。「第一歩」とは、その一つの手段において「最初にやること」と言う意味では？
一部の抜き出しは誤解を招くことがあります。まあ、表現がもし誤解も招いていたのならば、発言者本人が説明すべきことで、横から私のような他人がコメントすることではないと思いますが、
ただ、私は再インストールが大嫌いなので、あまり再インストールはお勧めしません。原因を特定しないまま、再インストールをすれば、結局同じ轍を踏むこともありえるわけで、あまりスマートな方法だとは思わないですし、何よりも、面倒くさい（本音はこれか？）
私なら、再インストールに走る前に、
・周辺機器が原因になってはいないか。
・他のアカウントでも再現されるか。
・ハードウェアにトラブルは無いか。
などなど、根拠が乏しくても、とりあえず試してみます。
急がば回れ。

YMKW さんありがとう。これからusadiさんにご返事書こうかと思っていました。ここ最近病院通いで疲れ気味です。ひどい下痢で今日はおむつ着用です。笑わんで下さい。
usadii さん、過日HDDの件ありがとうね。一生忘れないと思います。
＞「第一歩」とするのはリプライとしてどうかと
usadii さん、誤読ですよ。「．．．という方法もあります。」ですから方法の一つとして紹介させてもらっている。それでは、「．．．の第一歩は、」の”は”を”に”に置換せよという咎め立てがある場合には、小生返事をしません。それに、トラブルシューティングの順番やどれを採用するかを最終的に決めるのは、提案者ではなくご本人です。
アプリケーションの継続的なクラッシュや不可解なトラブルなどにおいて、システムソフトウェア再インストールで解決された事例は、数えきれないほどあります。複数のKnowledge Base でも紹介されています。
ここにも、 Mac OS X Troubleshooting: How to Isolate an Issue - Article ID:25392の"VII. Reinstall Mac OS X"があります。
＞Systemの再Installは全てをリセットする事であって、
でもシステム設定の一部設定は前のものが継承されるのもありますけど．．．
「全データゼロ」オプションフォーマットで、HDDを再初期化すると、全てをリセットしますけど。実際は、僅かHFS Plus（で例に取ると）のFile System 情報は残るものもあったと思いました。
usadii さんの投稿名があがっていたので、どうのような解決案を示されたのだろうとワクワク開きましたら、何も提案はないので少し肩を落としてしまいました。

「なんでそーなるの」なんて冷たい事いわんで下さいよ。当方は素人で、一進一退のような感じで学習していますので。あなた方プロ／エキスパートの技術知識には及ばないことは認識しております。
ログの訳し方については、当方の間違いで、推測できるものは何も無いというthumb さんのご指導に従います。
”タスクがアプリと同期できない”という私の見方については、(Mac OS X) System Overview 概論の semaphore 以下を参照しました。
For communication within the kernel, the task parameter should be the result of a call to current_task. For synchronization with a user process, you need to determine the underlying Mach task for that process.
(Mac OS X) System Overview 概論とは別に、semaphore を英英辞書で調べると"A system of sending messages using two flags, that you hold in different postions to prevent letters and numbers." とか"A light that is used to send signals, for example on a railroad." とありましたので、信号（緑と赤のような---要求に対して結果ですか？？）検知器のような役目もするだろうと解釈していました。
その他参照したものは、semaphoresとlocksとSynchronization primitives、Multiprocessing Services を含め以下の文献です；
Tasks and Threads
Mach Kernel Abstractions
Interprocess Communication (IPC), semaphores, lock など
それで、現在混乱していますのは、タスク=スレッドや「タスク」はカーネルから生み出された演算処理の器という説明が見つかりません。それに”器”という表現が無いのです。まだ疑問があります。役立たないログを何故吐き出すようなことをしているんでしょうかね。それに、ログライン３ー５あたりは、マイクロプロセッサーのレジスタかプログラムカウンターのエラーを示しているのだと推測しますけど、そうだとすると結構大切な情報かも。
＞あと余計なお世話ですが、長い文章を書く時には一つの段落であっても
適当な文字数で改行を入れる事をおすすめします。
これは、当方では管理し得ない案件ですので、アップル社の方へフィードバックして下さい。実は当方は反対なんです。文書管理上、不都合を生じますので．．．
thumb さんの方からmorewater へ具体的な問題解決のための提案は無いのですか？
例えば、こんなのはどうでしょう； Mac OS X: 再インストール後にアプリケーションが動作しない

>>>エラーを示しているのだと推測しますけど、
エラーを示しているのだと推測したいのですけど、

YMKWさん、安食さん、こんばんは。なるほど、納得しました & 失礼しました。
> 何も提案はないので少し肩を落としてしまいました
これに関しては、きくちさん、もださん、はにさんのリプライもありますし、
それに対する元記事の方のご報告もまだないようですので(^^;　
# 増設メモリーを外してみたが駄目だったとか、あやしそうなアプリケーション
# を外してみてどーだったとか
で、安食さんの記事でふと思い出したたのですが、はにさんの指摘の他にも
HDDに不良セクタがあったして、そこを例えばスワップとしてつかってたり
した場合とか、「使っているうちにおかしくなる」ってのがありました。
てことで、駄目もとでハードウェアテストもしてみるのも良いかもしれません。

安食さんの回答では、よく全データ0の初期化やシステムの再インストール操作、
メモリやHDなどの装置の交換を勧めているように見受けられるのですが、
こういったことはやる前にデータのバックアップをしてそこから戻す作業が必要だったり
高価な装置を購入することが必要ですよね？
これは実際にそれを行うにはリスクがあったり
(バックアップのし忘れでデータの一部が復元できなかったり)
時間や資金を消費させることになるわけでして
相手によってはそれが大きな負担となり得るのですよ。
ですから、こういったことを勧めるのならば、本当にそれが必要なのか、
それ相応の根拠が無ければ相手にとってはアドバイスというよりも
場合によりむしろ損害を与える発言となり得るのです。
あなたの解説の、私の見た限りでは、どうしてもその根拠たる部分が
いくらか欠落している様に、そしてそれを繰り返していると思えるのです。
そのうえ残念なことに、貴方の解説には難しい漢字や表現、
長い英単語だとか専門用語がたびたび現れ、文章に非常に威力がありますから
あまり精通していないユーザがそれを読めば
何の疑いもせずにその通りやりそうな感じがします。
根拠がはっきりと説明できないなら、
「これをやってうまく行くかどうかは分かりませんが」とか、
情報が間違っている可能性を、どんなシロウトが読んでも
感じられるような書き方をした方がいいと、感じます。
　
きおとりなおして。
> 「タスク」はカーネルから生み出された演算処理の器という説明が見つかりません。
この 器 と言うのは勝手な喩えです。
2番目のリンクで「Tasks=The units of resource ownership」とあるように
タスクはそれぞれに専用のアドレス空間を持っていて、
その空間を巧みに使いながら様々な処理をするわけで、これをちょうど
計算機の外装のようなものだという意味合いを込めて表現したまでです。
「タスク(=スレッド)」は、あくまでかつてのMacOS「」での
あり得る一つの表現理解です。MacOS「」でタスクという言葉は
あとから生まれてきたものであって、その定義があやふやなまま
解説されている文書があって、そう言う広義で理解している人もいるので、
どちらかを選んで読めば分かる様にと書きました。
MacOSXでいうタスクの定義のデベロッパ的狭義を使うのなら、
全て「スレッド」に置き換えて読んでください。
> 役立たないログを何故吐き出す
これは、単体で役に立たないだけです。
デバッガというプログラムの動作を解析するソフトウェアを用いて
プログラム内部での処理の進行をトレースしつつ
落ちる直前でのメモリの使用状態を残しておいて、
そこでクラッシュログを読むと期待した変化とどこがどう違うか
チェックすることができます。
レジスタなどの動きはアセンブラを通じ、やはりクラッシュの
直前での期待される状態との比較を行うために使われます。
バグレポートを行うときは、クラッシュログだけでは役に立ちません。
自分のシステムの構成と開発者が同じかそれに近い状態にして、
自分がやった操作とほほ全く同じ操作をしてもらって、
その症状を100%再現させ、クラッシュの直前という
大事なタイミングを捕まえてもらってこそ意味があります。