| < 2007年4月 > | ||||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
次の月: 2007年5月
先に言っておきますが、これはApple のセキュリティパッチに問題があることを示すものではありません。使い方っていうか、運用を間違えてなったものです。
今日、luna に最新のセキュリティパッチ (Security Update 2007-004) を当てたら起動しなくなって焦った。
起動開始直後の、Apple ロゴのしたでインジケータがくーるくーる回りっぱなしというもの。Cmd+V を押しながら起動させて、ログを見ると、
kextd_watch_volumes: couldn't set up diskarb sessions
diskarb isn't ready yet; we'll try again soon
だそうで。以下、約2時間の奮闘記録。
mkdir /insttmpで、展開されたファイル群に変なのがないのを確認してから、
cd /insttmp
cp /SecUpd2007-004Univ.pkg/Contents/Archive.pax.gz .
gunzip -d Archive.pax.gz
pax -r -f Archive.pax
cd /
pax -r -f Archive.pax
このあと reboot して、無事起動成功。1回目の起動はめっちゃ重くて焦ったけど、あとはいつも通りに。ふぅー。
さて、今回は Security Update を当てたあと、再起動の要求を強制終了、さらにスリープ2回くらいを含みつつ半日稼動、smbfs のマウントでエラーが出て渋々再起動したら〜、という、なんとも自業自得な流れでした。
しかしまぁ、最低限のユーティリティさえ動けば復帰も可能なことがわかって安心。hdiutil とか installer が動かないのはちょと困るけど、まぁ、今回はちょっとダメージでかかったってことで。
ちなみに、この作業のあと、また smbfs のマウントでエラーが出たんだけど、これは pax で解凍したせいで setuid/setgid フラグが mount_smbfs から消えたのが原因だった模様。DiskUtility のアクセス権限検査&修復で一発。初めてこの機能が役に立ちました(笑
だったら苦労ないですね。
CGI でアップローダを作ったら、最後に 0x0D 0x0A とかゴミがついたり、0x0D 0x0A が 0x0A に変換されたりで、イライラする昨日でした。
結局、MIME::Parser を使わずに書き直したらあっさり。ブラックボックスはこれだから(ぇ
緑が少ないので、ちょっと観葉植物なんか買ってきちゃいました。
ウチには既にでかいパキラの鉢植えがあるわけですが、どうにも机の上が寂しい。今だってレーズンサンドの空っぽになった袋とインスタントコーヒーのビンと、急須とかしかない。
というわけで、先に整理しろって感じもしますが、かわいい観葉植物です。
実は前にも買ったことがあって、そのときは即死したんですがネー。今回は枯れないといいなぁ。
i386 だの IA-32 だの、Intel のアーキテクチャ名としてどれが正しいのかイマイチ分かってない子です、こんばんわ。
GNU autoconf とかが i386 とか吐いてるのを見ると、実質アーキテクチャ名なのかなーとか。あ、gcc も -argc i386 って指定してるか。
Rosetta に addi の山とか nop の山とか、rlwinm の山とか、いろいろ食わせてみたけど、どうにもキャッシュがクリアされた感じがしない。面倒なのであきらめて i386 ネイティブの実装をすることにしました。
現時点で分かっている課題はこんな感じ。
とりあえず、命令コードを生成する関数群まで完成したので、コンパイラの再設計と実装を開始。レジスタが少ないから、PowerPC でやってたような最適化処理を書かなくていいのは楽かも。つまんないけど。
旧コンパイラの外部インターフェースを維持するためにヘッダとかを読んでると、Created by 2510 on Sat Apr 26 2003 とか書いてある。あぁ、もう 4 年前なのか…。
順調に開発日記に戻ってる気がする。実にいいことだ。
引き続きデバッグ進捗報告。FS を実行→FS をリセット→実行すると、落ちたり内部でクラッシュしたりする。原因は不明。
テスト用のコードを食わせてコンパイルさせてみたところ、実行しているコードと結果が違う…。Rosetta 上のアプリケーションを gdb でデバッグしてるんだけど、例えば stepi で見ると、lwz r26, 20(r31) を実行してるのに計算と違う値が r26 に格納されたりしてる。キャッシュがクリアされてない…ような気がする。
命令キャッシュの flush には vm_machine_attribute を使ってるんだけど、もしかして Rosetta には効かなかったりするんだろうか。それとも、ただ単にほかのミスなんだろうか。困った。
とりあえず、flush のときに Rosetta に nop の山でも実行させて動作が変わるか、様子を見てみよう…。
カルドセプト (正確にはカルドセプト エキスパンション・プラス) が動かないバグ、実に素敵なバグでした…。
FS2 は PS の BIOS を自力で実装してるわけですが、今回のバグはここでした。(今更コンパイラにバグがあったらすごく凹みますが)
PS にはスレッドの概念があって、BIOS でサポートがされています。当然、あるものは実装しなければならないので、根性で実装してあります。ちなみに、協調型なのかプリエンプティブ型なのかは知りません。知らなくても、こちらの実装には関係ありません。(タイマ割り込みで順番にスレッドを切り替えさせれば、事実上プリエンプティブ型にできるわけですしね)
で、一応 BIOS の関数というかシステムコールなので、返り値が存在します。この辺は全部、勝手に CPU のレジスタをいじって設定するわけですが、ここが素敵なことになってました。
void thread_ChangeTh(plugin_systemservices *context,int class_code,int function_code)
{
thread_descriptor *threads;
unsigned index;
(中略)
thread_switch(context,psx_load_word(context,0x110) + index * sizeof(thread_descriptor));
context->execution_data->reg[PSRegIndexCPU + PSRegV0] = 0;
とりあえず、返り値 0 がセットされてます。スレッドを切り替えた後に。返り値を戻す先は ChangeTh を 呼び出した側のスレッド(のコンテキスト)なので、これだと切り替えた先の CPU レジスタを壊してしまいます。
というわけで、逆にしたらここは通過。こんな単純で怖いバグが残っててびっくり…。
ちなみに、まだステージ開始時に本体ごと SIGSEGV で落ちる問題が残ってます。今度は誰だぁー。
Intel Mac だと rosetta 上のプロセスはデバッグできないのかな?gdb が落ちちゃう…。この辺は PowerPC な Mac に頼るしかないのかなぁ。
あ、あと WindowMode プラグインには、なんか NewGWorld とか素敵なレガシー関数が山ほど書いてありました。誰だ、こんなの書いたの。
どうやら表示がおかしくなるのは、この辺が悪いっぽい。104 でコンパイルしたら、Deprecated って怒られたし。
もーあちこち凄いことになってますね。みんな気合い入れ過ぎです。
luna で FlareStorm がやっとビルドできるように。ユニバーサルだのなんだのと混沌とした世界にやっと仲間入り。
ネイティブターゲットとやらに変換しないと ppc バイナリすら生成できないらしく、半日くらい悩みました。あと、開発マシンの移行のおかげで、ライブラリとかの依存関係や怪しいパス設定も全部修正できそう。あぁ、Universal Binary 云々より、FS のプロジェクト構成のほうがよっぽど混沌としてるじゃないか…。
とりあえず、隣の紅茶と砂糖とカードゲームが大好きな変態さん偉い人からカルドセプトという素敵ゲームを紹介してもらい、見事に嵌ってしまったので、コレを対象にしてデバッグ中です。
ePSXe だと動くんですけど、FS は対戦画面オープン時にカーネルメモリが吹っ飛んでお亡くなり。実にデバッグしがいのあるバグです。とっても美味しそうです。
タイトルが日付とかに関係してても、ちーっとも内容はそんなんじゃないですね。まぁ、仕様なんであきらめてください(ぇ
luna の MacOS X Mail が寝ぼけてくれました。
「メッセージはサーバからダウンロードされませんでした」とか言うんですが、これがオンラインにしても何してもダウンロードされない。
まぁ、当然クライアント側が寝ぼけてるわけで、とりあえずなった原因は不明。serenia の Thunderbird でも同じのを受信してるから、まぁ、それほどは困らないけど…やっぱり許せない。さぁどうするか。
Apple の記事によれば、メールボックスの再構築をしろとか、Enveloper Index ファイルを消せとか書いてある。しかし、私の環境ではこれはむしろ悪く働いて…。再構築したら、存在だけは分かっていたメールは消失、既存のメールが2つとかに増殖。orz
んで、いろいろファイルを開けてみたりすると、どうやら受信はできていて、表示とインデックスの生成ができていない模様。壊れたファイルが .mbox ディレクトリに混ざってるとダメらしい。
直せると分かればやる。突貫工事には perl が適任。check-broken-mail.pl.gz と delete-same-mail.pl.gz。使う人いるのかなぁ??
前者は ~/Library/Mail/Mailboxes 以下を検索、正常なヘッダを持たないメールを探す。後者は、再構築とかで増殖したメールの削除用。どちらも、ちゃんとバックアップを取った上でご使用ください。
これですっきり〜って思って Mail を開くと、なぜかアカウント設定の画面が。あれー…って思いつつ、ごまかして起動。ちゃんと動いてます。これで一件落着。
と思ったら、作業中に ~/Library/Preferences フォルダ(Windows でいうレジストリのもっと大事じゃないやつ)を吹っ飛ばしちゃったらしい。ゴミ箱を空にするときにやたらファイルが多いと思ったら… orz