雨。 整形外科へは車で。
ついでに車でバイク屋さんに寄って、任意保険の更新手続きをする。 クレジットカードの期限はブランドによって自動更新の場合とそうでない場合があるらしく、イオンの VISA は更新されていた。 バイク屋さんの店長、iQ を見て珍しい車だと興味津々だったw 車好きでもこの車は知らない人多いよねw そうそう、また新しいバイクが出たみたいで。
V とついているけど並列 2 気筒エンジン。 アドベンチャーツアラーと言っていて見た目もなんかそれっぽいが、使い勝手的には GSR250S の後継といったところか。 エンジンは同系統だし車重も近いしメインスタンドまで付いている。
夜は、西田あい 7 周年記念コンサート @ 有楽町よみうりホール。2 階の関係者席あたり、ライトがまぶしい。 いろんなカバー曲もあって 2 時間ちょっとのコンサートだった。 アンコールで客席を回ってタッチ。 手は冷えていた。 で、しゃべりは、声だけ聞いていると柏木由紀なんかを思い出すトーンで、東京アクセントを意識してはいると思うのだが、結構な頻度で節々に鹿児島アクセントが現れる。 歌声は曲によってちょっと雰囲気が違うように思ったが、低めのトーンで歌っている時はどこか中島美嘉っぽかった。 歌手のコンサートだから、演奏の人達は脇役というか、あまり見えないんだけど、あの人達はすごいよなぁ。 ドラムとかベースとか、歌以上にミスれないし、プロの仕事って感じがする。 ベースの低音が良い感じに響いて楽しかった。 あ、西田あいも楽しそうに歌っていたので、これからも楽しく歌っていってほしい。 鹿児島アクセントが適度に混ざっているのも、同郷の人間は喜ぶのでぜひそのままで... (^^;
謎の call だと思われていたところのデータ構造を突き止めた。
(gdb) p *(struct obstack *)0x0000000001b0f4d0
$1 = {chunk_size = 4064, chunk = 0x2493dc0, object_base = 0x1b0f508 "",
next_free = 0x1b0f508 "", chunk_limit = 0x0, temp = {tempint = 0,
tempptr = 0x0}, alignment_mask = 48, chunkfun = 0x0, freefun = 0x0,
extra_arg = 0x0, use_extra_arg = 0, maybe_empty_object = 0, alloc_failed = 0}
この chunkfun というのを呼び出そうとして落ちている。 これは初期化の際にセットされているはずであり、おかしい。 他にも freefun もおかしいし、alignment_mask は文字通りビットマスクのはずでたぶん 7 が入っていないといけないはずなのに、48 が入っているのもおかしい。chunk_limit もよく見てないけどたぶんポインターが入っていなきゃいけないのに NULL である。 逆に chunk_size の 4064 は正常値だ。
そんなわけで例の 64 バイトズレ問題で初期化ルーチンが正常に動かなかった可能性を検討したけど、いくらなんでもこんな動きにはならないと思うんだよなぁ。 どこかでぶっ壊した可能性のほうが高そうな感じが。 これはわからん。
よく寝た日。
東京都議会議員選挙投票日。
そうそう、きのうは有楽町に行くのに神田で乗り換えようとしていたけど、たくさんの人が降りるのを見て気が変わり、東京駅丸の内口から有楽町駅前まで歩いた。 はとバス乗り場? の先に「JR 東京駅」ってあるから何かと思えば京葉線の出入り口だった。 帰りは東京駅に向かわず、品川に行って、駅の中の TOKYO 豚骨 BASE という店で夕食をとり (さすがにきれいにしている店でスープもそんなに臭く無かった)、そこから山手線で新宿に出て、中央線快速に乗り換えようと思っていたのに目の前の各駅停車につられて乗り換えてしまい、その後、次の乗換駅で待ち時間が長くなる可能性に気づいて、中野で快速に乗り換えるという謎パターンの帰宅であった。
AMD は交換対応をしているそうだが、交換品でも問題解決していないという話があるらしく盛り上がりそうな気配。 うちのは交換をお願いしていない。 発生頻度が低く動画エンコード程度だと影響はなさそうだし、何より謎解きパズルは楽しいので。
現状わかっているのは、%rip の 64 バイト手前の命令が唐突に実行され始めるケースがあることと、その状態で call 命令があれば %rip の位置 (call 命令の 64 バイト後ろ) をベースにスタックに戻り番地が積まれ、相対番地指定であれば呼び出し先も 64 バイトずれる (%rip そのものがズレる、%rip と実行される命令の対応としては元に戻る)、そんな感じ。 自分の考えでは、あらゆるトラブルをこの現象だけで説明できるのではないかと思って、調べているのだがなかなか難しいパターンが多い。 何度もやっていると、もう分析済みのものが何度も出てきて、うっとうしいのでこれもちょっと cc1 をハックしてみた:
3054169,3054173c3054171,3054174 < 113f539: 48 83 ea 01 sub $0x1,%rdx < 113f53d: 49 89 55 00 mov %rdx,0x0(%r13) < 113f541: e9 b8 fc ff ff jmpq 113f1fe < 113f546: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) < 113f54d: 00 00 00 --- > 113f539: 48 81 ea 01 00 00 00 sub $0x1,%rdx > 113f540: 49 89 55 00 mov %rdx,0x0(%r13) > 113f544: e9 b5 fc ff ff jmpq 113f1fe > 113f549: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
これは、%rip=0x113f57d の時に 113f53d の命令が実行されたように見える問題の話で、ちょうどいい具合に 64 バイト手前に命令があるからそんなことになるのでは、という思いから、わざと違う機械語に変えて命令の位置をずらしてみたものである。 即値のビット数を変えただけで、命令そのものの並びは変わっていないので、マイクロコードになったらもはや同じなのではないかな。 そうでもないのかな。 これで出なくなるんならおもしろいというか、もちろんマイクロコードキャッシュの観点で言えばそんな変なアドレスはキャッシュにのらないわけだから、マイクロコードキャッシュの問題なのであればこれで出なくなって正しいような気もする。
全体的には cc1 の bitmap という処理に絡む部分でトラブルが起きている頻度が非常に高そうな感じはする。 今は VMM 無しで見ているので、分岐情報は取れていないし、割り込みのタイミングも不明。 そのため、%rip がズレたところから、割り込みをきっかけにして元に戻った、というパターンがあるとしても、そこは推測でしかない。
bash segfault on Ryzen - GitHub
他人様の segfault 分析の様子である。bash らしい。%rip は 0x00000000004370d0、ページフォールトのアクセス先が 0x6dfb44 だという。 命令の通りのスタックポインターは全然違うところを指しており、何か違う命令を実行しているかのようだ。 じゃあ 64 バイト手前か? と言えば、64 バイト手前のちょうどいい位置に命令はなく、何か違うようだ。
じゃ、どの命令かと言えば、レジスターの一覧を見ても、それらしきアドレスはない。 ふむ。 他に疑わしいのは %rip 相対指定か。%rip を引けば 0x6dfb44 - 0x00000000004370d0 = 0x2a8a74 で、何かそれっぽいアドレスはないだろうか? と探すと、0x0000000000465ef0 のあたり。 ちょうど、直前の call 命令が呼び出しているサブルーチンの中だ。 ただし、0x0000000000465ef0 の命令であれば 8 バイト命令で 0x2a8a78(%rip) なので、0x00000000004370d0 + 8 + 0x2a8a78 = 0x6dfb50 で計算が合わない。 見ていくと 0x0000000000465f10 の命令なら 6 バイト命令で 0x2a8a6e(%rip) なので、0x00000000004370d0 + 6 + 0x2a8a6e = 0x6dfb44 でぴったりである。
スタックの内容も含めて見れば、0x00000000004370cb の call 命令を実行、0x465ef0 番地から順に命令を実行していき、0x0000000000465f0b の call 命令も実行し、普通に ret したところで、%rip は正しく 0x00000000004370d0 に移ったが、実際に実行しようとした命令は 0x0000000000465f10 だった、ということになる。64 バイトズレだけじゃないんだな、という、新たな発見であった。
なお、手元に残っている core は、ここに載せていないものも含め何種類も 64 バイトズレで説明できそうなものがある。 きのうの深夜に起きていた segfault は mv コマンドの中だったが、それも 64 バイトズレとそのまま jmp を実行して機械語命令の途中に飛んでしまったということで説明できそう。 あと、きのうの夜中に回した内容では、きのうわざと命令位置をずらした件については一度もその周辺での問題は残っていなかった。 やはり、命令境界がちょうど 64 バイト手前に来るかどうかというのがポイントになるようだ。 ただし上述の他人様の Ryzen での分析もあるので、話はやっかいだ。 後は発生箇所が何パターンか偏っているのが説明できればいいんだけどなぁ。
天気予報に出てきた数字は最高気温 35 度。 気象庁アメダスによれば府中市幸町の今日の最高気温は 33.5 度 (15:04)。 そうでもない? いやいや、19 時に 30.9 度、21 時に 30.0 度というのがこの暑さを語る数字である。 さすがに 30 度台ってのは、直射日光無くてもバイクで暑さを感じるような気温である。
朝は山手線でブレーキ故障のためダイヤ乱れという情報を Twitter で眺めて、新宿駅ホームの大混雑で巻き添えを食って中央線も遅れているとのことだったので、迷わずバスで行ったら明らかに定刻の列車が駅に進入するのが見えて、とっくにダイヤは回復していたということだ。
夜は台風襲来。 帰宅時間帯にはまだ強風域にすら入っていなかったけど、雨はそれなりに降り出していた。
じゃがいも消費作戦につき、豚軟骨とタマネギとじゃがいもとおでんの素をスロークッカーに放り込んで煮込んだ。 料理が美味いというよりは、素材が美味い... 歯ごたえすらもなくなったとろっとろの軟骨に新タマネギに新じゃがいも、まー美味いよね。 豚軟骨はその安さもうれしい。 近所のスーパーで 100g 100 円ちょっとくらいだった。 問題はいつも売っているわけじゃないところか。
Skype は今月から旧バージョンのクライアントが使えないことになっているはずなのだが、サインインしっぱなしの手元の Skype は引き続きそれらしき表示をしている。 オンライン中の人数は 59M 人あたりと出ているし、ユーザーのステータスも更新されているように見える。 どうなっているのだろう。 この PC は CPU が Atom Z530 なので 64bit に移行できず、32bit 版の Skype for Linux の提供が終わった今となってはもう Skype を動かしておくことはできないのだが (qemu-user を使う手はあるのか?)、サインアウトするまでは使えるのだろうか?
暑い。
夜はまたざーっと雨が降った。 九州北部はなんだかやばいことになっているらしい。 数年前の鬼怒川みたいにならなければいいが...
温度はちゃんと測っていないが、Seek Thermal で見てみたところ、RAM の下のほうにあるマザーボードのヒートシンクが、負荷を掛けると熱々 (65 度くらい) になる様子が観察できた。 あと CPU の後ろ側、背面パネルとの間の空間もやはり熱々になっていた。CPU の上側は 43 度あたりでそうでもなく、電源装置の冷却ファンによる排熱効果だろうか。 排気ケースファンをつけていないので、CPU の排熱がたまってしまうのかも知れない。
まーでも CPU より怪しいのはマザーボードについているヒートシンクのほうかな。 あれは何用なのかな、電源まわり? 電源が不安定になればそれは当然 CPU にとっても致命的なので、そのへんもちゃんと冷却したほうがいいんだろうな。 とはいえ、segfault トラブルに関して言えば、温度が悪いというよりは、何らかの設計上のしきい値みたいなものが甘かったというようなところが少しありそうな気はする。
なにやら SOC 電圧とやらを上げたらどうかという話を見かけたので、意味もわからず試しに +0.2V 上げてみたのだが、普通に segfault は起きた。 今まで起きたことのないアドレスではあったが、すぐにいつも通りの 64 バイトズレ問題のひとつであることがわかった。 ページフォールト時点での %rip の指す命令がページフォールトを起こす命令でなく、64 バイト手前に原因となる命令があるという極めてわかりやすいパターン。
Skype が使えなくなるといわれつつまだ使えているっぽいけど、そういう 64bit アプリしか提供されなくなったものが QEMU User Emulator で動かせるかと思ったら、どうもこれは致命的な問題を抱えているようだ。 試しに busybox を動かしてみたらこの通りである:
$ file busybox busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically l inked, for GNU/Linux 2.6.32, BuildID[sha1]=45ccabb327ad2416d72b467d491dbc83d5eb e97d, stripped $ uname -m i686 $ qemu-x86_64 ./busybox ls -l / total 1 drwxr-xr-x 25 root root 696 Mar 2 2007 drwxr-xr-x 25 root root 696 Mar 2 2007
ls すらまともに動かないとは、絶望感漂う挙動である。 これは Debian GNU/Linux jessie (oldstable) の QEMU だが、jessie-backports から引っ張ってきてもだめみたいなのでバージョンのせいではなさそうだ。64 ビット環境上では大丈夫なので、システムコールの変換にまつわる問題かとも思ったが (getdents(2) で使われる unsigned long 型の大きさが 32 ビットと 64 ビットで違うため変換が必要)、それなら反対に 64 ビット環境で 32 ビットバイナリーを qemu-i386 で動かすのもうまくいかないはずだ。 しかしなぜかそれはうまくいくのであった。
$ file busybox busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=bd18da7da6195be9b099237b15d183b07b7 f908b, stripped $ uname -m x86_64 $ qemu-i386 ./busybox ls -l /etc/systemd total 8 -rw-r--r-- 1 root root 823 May 10 2014 logind.conf drwxr-xr-x 5 root root 4096 Apr 19 2014 system
2017 年 7 月九州北部豪雨はだいぶ被害が出ているらしい... 2 年弱前の平成 27 年 9 月関東・東北豪雨の被害を見てしまった記憶がよみがえる。 っていうか、平成 26 年 8 月豪雨というのもあったし、去年は熊本地震があったし、日本全国災害続きだな...
昨日の夜ちょっと変な風に寝てしまってまたちょっと痛みがアレ。 ひどくはないけど痛みが出ている感じがする。
DAZN で Formula One フリー走行を珍しく見てみた。 なんか動きがなめらかになっている気がするぞ!? と思って調べたら 50fps になったとのうわさ。 前回のレースでは気づかなかったが、まだだったのかどうか。 サッカーは先月の途中からそうなっていたみたいだ。 ディスプレイのリフレッシュレートとの差は気になるところではあるが、設定を確認したら 85Hz にしてあったw 75Hz のほうが良いかも知れないが、59.94fps も見るしなぁ。 ま、何でもいいけど 25fps とは比べものにならない。 これで不満は無くなった感じ。
問題が出たら早急にそれを検出して止める的なことができないか、gcc をコンパイルする時に何か仕掛けを突っ込む手はないかを考えている。 とりあえず、gcc に -include オプションを付ければ強引に好きなヘッダーファイルを読ませることができる。 それで、asm 文を入れればアセンブリ言語の出力に好きな内容を追加でき、それでアセンブラーのマクロでも入れれば適当な命令を差し替えることができるかも知れない。
しかし %rip の値をチェックするには lea 命令を使いたい。 そうするとレジスターを破壊しなければならない。 どうにかしてレジスターを予約できないか? というと、できるらしい。
register int x asm("%r10");
こんな感じで書けば、%r10 を予約できる。 ただし、%r10 は通常関数で破壊して良いレジスターなので、以下のような警告が出る。
z.c:1:14: warning: call-clobbered register used for global register variable
これはライブラリ関数などを呼んだときに変数の中身が壊されうるのだからコンパイラーとしては当然の警告か。 今回は無理やりアセンブリ言語で lea 命令を挿入したいとすれば、破壊しても良いほうが都合がいい。Red zone が使われている場合はスタックを好きに使えないので、こうしてレジスターを予約できているほうがやりやすい。
後は比較のためにフラグレジスターを破壊してしまうので、まぁ例えば cmp 命令の直前に入れる分には困らないが、mov 命令の間に挟み込むのは手間だ。 あと条件ジャンプをどうするか、異常検出時にジャンプで int3 を埋め尽くした領域にジャンプするとかかな? でも %rip ズレたところからジャンプしたら元をたどりにくくなる? cmov は即値指定できないんだっけか、うーん。 比較したあと予約しておいたレジスターに目印の値を入れてから条件ジャンプでいいかな?
ま、そんな凝ったことしても再現しなくなるかも知れないし、いつものように変なところで飛んで変なところアクセスして落ちるパターンは引き続き避けられないし、難しいところだ。
藤野。5 回乗ってベストタイムは 39.771 秒くらい。
クッソ暑い一日。 午前中に耳鼻科に寄って、藤野には午後一に車で行って 1 時間半ほどでさっさと帰ってシャワー浴びて昼寝した。 暑かった。
気象庁アメダスの府中市幸町の記録した最高気温が 34.0 度 (13:01) だもんね、相模湖はそこまででは無かったかも知れないけどそれにしても良く 40 秒切れたな。 路面温度が高いせいでタイヤはあっという間に熱々でグリップしすぎるし、エンジンはお疲れモードだし、良いタイムが出せるコンディションでは全く無かった...
車もエアコンつけっぱにしていたらシガーソケット電圧がずっと 13.7V 前後。 いつもなら 14.1V 前後なのだが、たぶん温度か何かの条件で低めの電圧に制御されていたものと思われる。 というのは、試しに一時的にエアコン・送風を止めてアクセルペダルを離したら、いつものように 14.6V 前後まで上がったので、発電系統の故障によるものではない。 ということで、エンジンルーム内は相当な温度になっていたものと思われ、こうなるとエンジンオイルを 0W-20 の代わりに 5W-30 にしたのは精神的な安心感が多少ある。
cc1 を gcc のソースからビルドする。Ubuntu の gcc パッケージのビルドを始めたら、build/gcc/ ディレクトリに cc1 ができていて、これかな。 ビルド自体は並列ビルドが行われないためか 11 時間も掛かった。 しかも成功したように見えたが dmesg 見るとたくさんの trap や segfault が残されていて本当に大丈夫なのか? 適当にファイルを消して make cc1 したら再コンパイルが行われるようだから、これがあればいいようだ。
さて、Makefile をちょっといじる。make cc1 の時に出てきたコンパイラーオプションの中に -fprofile-use という目立つものがあったので、それを検索すると 3 箇所。 その後ろに -include /root/hoge.h を付ける。 んで、そのヘッダーファイルの中身はこれだ:
register int DUMMY_dummy asm("%r10");
asm(".include \"/root/hogeasm.s\"");
こないだ見つけた方法で %r10 レジスターをコンパイラーに使わせないようにした上で、アセンブリ言語のほうにも .include でファイルを読み込ませる。 そっちのファイルの内容はこれ:
.macro defhoge i
.macro \i o:vararg
hoge \i,\o
.endm
.endm
.macro hoge i,o:vararg
.purgem \i
lea (%rip),%r10
cmp $.,%r10
jne hoge_fail
\i \o
defhoge \i
.endm
defhoge cmpb
defhoge cmpw
defhoge cmpl
defhoge cmpq
.text
.rept 512
int3
.endr
hoge_fail:
.rept 512
int3
.endr
マクロを使ってやってみたのだが、もうちょっと、マシな方法があるかも知れない。vararg を使わないと (%rax,%rbx,8) 形式の指定を変な風に解釈されてしまったので vararg を使うのと、呼び出しがネストしてしまわないように .purgem でマクロを消して使ってから再定義するという怪しい方法を使っている。 で、cmpb/cmpw/cmpl/cmpq の 4 命令の直前に、%rip が正しいかどうかの比較テストをする短いテストコードを挿入している。 不一致の時は hoge_fail に飛ぶ。 これは 1,024 個の int3 の真ん中で、多少ズレても int3 があるという構成。
これで cc1 はずいぶん大きくなってしまったが (笑)、ビルドテストを試みたところ int3 が実行されるケースを見ることができた。 ひとつ目は以下の場所で停止:
(gdb) x/i $pc => 0x1640b41 <hoge_fail+65>: int3
%r10 の付近を観察 (長いシンボル名はカット):
(gdb) p/x $r10 $1 = 0x1161aba 1161a61: 4c 8b 9c fc b0 00 00 mov 0xb0(%rsp,%rdi,8),%r11 1161a68: 00 1161a69: 4d 0f a3 e3 bt %r12,%r11 1161a6d: 0f 83 7d 01 00 00 jae 1161bf0 1161a73: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 1161a7a: 49 81 fa 7a 1a 16 01 cmp $0x1161a7a,%r10 1161a81: 0f 85 79 f0 4d 00 jne 1640b00 <hoge_fail> 1161a87: 45 39 e0 cmp %r12d,%r8d 1161a8a: 0f 86 60 03 00 00 jbe 1161df0 1161a90: 8b 43 04 mov 0x4(%rbx),%eax 1161a93: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 1161a9a: 49 81 fa 9a 1a 16 01 cmp $0x1161a9a,%r10 1161aa1: 0f 85 59 f0 4d 00 jne 1640b00 <hoge_fail> 1161aa7: 41 39 c4 cmp %eax,%r12d 1161aaa: 0f 85 3a 02 00 00 jne 1161cea 1161ab0: 8b 7b 08 mov 0x8(%rbx),%edi 1161ab3: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 1161aba: 49 81 fa ba 1a 16 01 cmp $0x1161aba,%r10 1161ac1: 0f 85 39 f0 4d 00 jne 1640b00 <hoge_fail>
見事に %r10 の位置にも 64 バイト手前にも上で足したテストコードが入っている。%r10 が指す位置の命令が本当に実行されていたなら、クラッシュはしない。 実際にはそのへんで 64 バイト手前にワープしてしまったと考えられる。 なお、いくつかのレジスターの内容を確認したが、直前までは普通に実行されていたと思われる。
(gdb) x/x 8+$rbx 0x3f30a68: 0xffffffff (gdb) p/x $rdi $2 = 0xffffffff (gdb) p/x $eax==$r12d $4 = 0x1 (gdb) x/x 4+$rbx 0x3f30a64: 0x00000018 (gdb) p/x $eax $5 = 0x18
ふたつ目は以下の場所で停止:
(gdb) x/i $pc => 0x16b58e1 <hoge_fail+65>: int3
%r10 の付近を観察:
(gdb) p/x $r10 $1 = 0x13b0188 13b0123: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 13b012a: 49 81 fa 2a 01 3b 01 cmp $0x13b012a,%r10 13b0131: 0f 85 69 57 30 00 jne 16b58a0 <hoge_fail> 13b0137: 66 83 f8 2b cmp $0x2b,%ax 13b013b: 0f 84 0f 1a 00 00 je 13b1b50 13b0141: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 13b0148: 49 81 fa 48 01 3b 01 cmp $0x13b0148,%r10 13b014f: 0f 85 4b 57 30 00 jne 16b58a0 <hoge_fail> 13b0155: 66 83 f8 35 cmp $0x35,%ax 13b0159: 0f 85 21 08 00 00 jne 13b0980 13b015f: 48 8b 6b 08 mov 0x8(%rbx),%rbp 13b0163: 48 8b 53 10 mov 0x10(%rbx),%rdx 13b0167: 0f b7 4d 00 movzwl 0x0(%rbp),%ecx 13b016b: 48 89 54 24 30 mov %rdx,0x30(%rsp) 13b0170: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 13b0177: 49 81 fa 77 01 3b 01 cmp $0x13b0177,%r10 13b017e: 0f 85 1c 57 30 00 jne 16b58a0 <hoge_fail> 13b0184: 66 83 f9 35 cmp $0x35,%cx 13b0188: 0f 84 02 0e 00 00 je 13b0f90
今度は %r10 の 64 バイト手前にテストコードが入っている。%r10 が指す位置の直前にも比較があるため、そこが実行されていたとしてもその時点では問題は発生していなかったと考えられる。 見た感じ 13b0177 から 64 バイト手前を実行し始めたと見るのが正解かなと。
(gdb) x/gx 0x30+$rsp 0x7ffd4322adb0: 0x00007f220d3cd830 (gdb) p/x $rdx $4 = 0x7f220d3cd830 (gdb) x/x 8+$rbx 0x7f220cdf2c38: 0x00007f220d20d300 (gdb) p/x $rbp $5 = 0x7f220d20d300 (gdb) p/x $ax $6 = 0x35
こんな感じで、現状うちの環境では 64 バイトズレ問題ばかりが発生している。 これまでの core で原因を特定できていないものもあったけど、それはどこかで 64 バイトズレたまま普通に実行が済んでしまった場合、後からその場所を特定するのは困難だからだと思っている。 今回のこのテストコード入り cc1 を使えば、頻繁に %rip チェックが走るので、そう簡単には 64 バイトズレたままの実行は継続されないと思う。
スーパーフォーミュラ第 3 戦、富士スピードウェイ。 この暑さでは現地に行く元気も起きないので、BS フジの生中継で観戦。 スタート直後の周回では一部ガチャガチャやり合っていたが、その後は静かに進む、かと思いきや、パンクやらブレーキやらエンストやら何やらとトラブルが多発。 暑さの影響もあるだろうか。 終盤の 4 位関口を先頭にしたバトルがおもしろくて、これが DRS のないバトルだよなぁと。 もし DRS があったらたぶん 1, 2 周で抜けてしまってその後は引き離されて終わりだっただろう。 タイヤの関係でかなりのペース差があったはずなのに、ストレートスピードを重視したセッティングと思われる関口がストレートで微妙に引き離し、オーバーテイクを難しくした。Formula One の DRS はオーバーテイクを増やしたが、レースの見所は減ってしまったんだよな。
東京競馬場の花火大会。 最後に音楽に合わせてドカドカっと、かなりの数が短時間に一気に打ち上げられて、煙で花火が隠れるほどになり、そこらじゅうに火薬のにおいと煙が充満して終了となったのには笑った。 帰るタイミングをミスって人と自転車の大渋滞だった。 花火大会に来ると、モータースポーツで音とにおいが云々と言う人がいるのを思い出すな。 花火大会の音とにおいが無くなったらと思うとちょっと寂しいもんね。 でもなー、モータースポーツの音はエネルギーの損失なので、最新技術を取り入れていくと静かになるのは避けられないもんかと。
DAZN の Formula One 本当に良くなってるな。50fps って聞くと変な数字だなと思うけど、十分だ。
ポケモン GO プラスの電池が減ってきたらしく、電池残量が少ないマークがポケモン GO の画面に出るようになったので、電池を買ってきた。 このところバイブレーターの振動が弱々しい感じになってきていたし、マークも出るようになったから替え時だな。 時々アプリ側の接続表示は切れているのに実際には切れていないパターンがあって、それで予期せぬ電池消費をしてしまったことがあるかも知れない。 スマートフォン側は ZenFone Max のバッテリーが大きすぎて、減りが早くても気づけないw
-ffixed-reg などというオプションをコメントで教えて頂いた。 なんとまぁこれほどまでにドンピシャなオプションがあるものだろうか...
ま、それはともかく、きのうのやつで一晩ビルドテストを回した。linux-4.12-rc4 の defconfig build で -j16 で、あの改造で少し 1 サイクルの時間は延びて、80 秒あたりになっている。 それでも速い... さて、どんな core ができたかな?
-rw-r--r-- 1 root root 62722048 Jul 10 00:11 dbg-1499613093.56/core -rw-r--r-- 1 root root 26812416 Jul 10 00:12 dbg-1499613171.57/core -rw-r--r-- 1 root root 87371776 Jul 10 00:34 dbg-1499614440.73/core -rw-r--r-- 1 root root 72695808 Jul 10 01:58 dbg-1499619536.136/core -rw-r--r-- 1 root root 54448128 Jul 10 02:51 dbg-1499622678.175/core -rw-r--r-- 1 root root 63148032 Jul 10 02:55 dbg-1499622916.178/core -rw-r--r-- 1 root root 0 Jul 10 04:47 dbg-1499629623.261/core -rw-r--r-- 1 root root 37683200 Jul 10 04:54 dbg-1499630090.267/core -rw-r--r-- 1 root root 0 Jul 10 04:59 dbg-1499630359.271/core -rw-r--r-- 1 root root 39424000 Jul 10 05:00 dbg-1499630433.272/core -rw-r--r-- 1 root root 145039360 Jul 10 05:15 dbg-1499631320.283/core -rw-r--r-- 1 root root 22560768 Jul 10 05:29 dbg-1499632187.294/core -rw-r--r-- 1 root root 104542208 Jul 10 05:40 dbg-1499632829.302/core -rw-r--r-- 1 root root 61767680 Jul 10 05:46 dbg-1499633180.307/core -rw-r--r-- 1 root root 34443264 Jul 10 06:28 dbg-1499635712.339/core -rw-r--r-- 1 root root 4599808 Jul 10 06:33 dbg-1499636023.343/core
一部 0 バイトとあるのは実は core がはかれなかったところ、今回シグナルハンドラーのほうは何もしていなかったので、普通に SIGSEGV/SIGILL 等が起きると core 無しになってしまうのだった。 出力メッセージもとってあり、いずれも Segmentation fault でバックトレースは出ているが、それ以上の詳細は出ていないみたいだ。 ただ、これはまだ何かありそうで気になるところではある。
ま、分析できないものはしょうがない。 残りは core が出ているのだから、調べようがある。 まずは $pc の観察。
dbg-1499613093.56 (gdb) => 0x15e0421 <hoge_fail+65>: int3 dbg-1499613171.57 (gdb) => 0x16a7201 <hoge_fail+65>: int3 dbg-1499614440.73 (gdb) => 0x1687181 <hoge_fail+65>: int3 dbg-1499619536.136 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499622678.175 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499622916.178 (gdb) => 0x1617cd1 <hoge_fail+65>: int3 dbg-1499629623.261 dbg-1499630090.267 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499630359.271 dbg-1499630433.272 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499631320.283 (gdb) => 0x16e1a01 <hoge_fail+65>: int3 dbg-1499632187.294 (gdb) => 0x1617cd1 <hoge_fail+65>: int3 dbg-1499632829.302 (gdb) => 0x1640b41 <hoge_fail+65>: int3 dbg-1499633180.307 (gdb) => 0x1617cd1 <hoge_fail+65>: int3 dbg-1499635712.339 (gdb) => 0x16dbf01 <hoge_fail+65>: int3 dbg-1499636023.343 (gdb) => 0x1510761 <hoge_fail+65>: int3
全部 +65 で、期待が持てる。 次に $r10-64 を見てみよう。
dbg-1499613093.56 (gdb) 0xf80363 <_ZL13calc_dfs_treeP8dom_infob+243>: cmp $0xf80363,%r10
dbg-1499613171.57 (gdb) 0x1358079 <_Z16compare_tree_intPK9tree_nodem+73>: cmp $0x1358079,%r10
dbg-1499614440.73 (gdb) 0x130d941 <_Z18thread_across_edgeP5gcondP8edge_defbP3vecIP9tree_node7va_heap6vl_ptrEPFS5_P21gimple_statement_baseSB_E+1409>: cmp $0x130d941,%r10
dbg-1499619536.136 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499622678.175 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499622916.178 (gdb) 0x10b545e <_ZL20record_operand_costsP8rtx_insnP9reg_class+4766>:
sub %dl,%cs:0x0(%rsi)
dbg-1499629623.261 (gdb) (gdb) quit
dbg-1499630090.267 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499630359.271 (gdb) (gdb) quit
dbg-1499630433.272 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499631320.283 (gdb) 0x148536a <_ZN12_GLOBAL__N_115pass_rtl_fwprop7executeEP8function+3658>: cmp $0x148536a,%r10
dbg-1499632187.294 (gdb) 0x10b545e <_ZL20record_operand_costsP8rtx_insnP9reg_class+4766>:
sub %dl,%cs:0x0(%rsi)
dbg-1499632829.302 (gdb) 0x1161a7a <_ZN12_GLOBAL__N_118pass_cprop_hardreg7executeEP8function+10394>: cmp $0x1161a7a,%r10
dbg-1499633180.307 (gdb) 0x10b545e <_ZL20record_operand_costsP8rtx_insnP9reg_class+4766>:
sub %dl,%cs:0x0(%rsi)
dbg-1499635712.339 (gdb) 0x1440281 <_ZL22mark_used_regs_combineP7rtx_def+353>:
cmp $0x1440281,%r10
dbg-1499636023.343 (gdb) 0x151c275 <c_builtin_function(tree_node*)+261>: cmp $0x151c275,%r10
あ、あれ? あれれ? %r10 と比較する cmp 命令があって、そのオペランドと命令のアドレスが一致しているやつは想定通りなのだが、一部そうじゃないやつがある。dbg-1499622916.178 と dbg-1499632187.294 と dbg-1499633180.307 だ。 いずれも 64 引いたアドレスは 0x10b545e だ。 なお、これらの %r10 が指すアドレス 10b549e にはきちんとプログラムがあり、ここを実行していたなら変なことになるようには見えない。
10b5497: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b549e: 49 81 fa 9e 54 0b 01 cmp $0x10b549e,%r10 10b54a5: 0f 85 e5 27 56 00 jne 1617c90 <hoge_fail>
うーん... ジャンプ先のアドレスからして 64 バイトのズレということにはなるのに、64 バイトズレたところにきれいに命令があるわけではないというのはどう見ればよいのか...
10b544e: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b5455: 49 81 fa 55 54 0b 01 cmp $0x10b5455,%r10 10b545c: 0f 85 2e 28 56 00 jne 1617c90 <hoge_fail>
ここにはあるけどね、ここに合わせたら 73 バイトになっちゃうもんな。 わからん。
ああー。
10b5472: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b5479: 49 81 fa 79 54 0b 01 cmp $0x10b5479,%r10 10b5480: 0f 85 0a 28 56 00 jne 1617c90 <hoge_fail> (snip) 10b5497: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 10b549e: 49 81 fa 9e 54 0b 01 cmp $0x10b549e,%r10 10b54a5: 0f 85 e5 27 56 00 jne 1617c90 <hoge_fail> 10b54ab: 42 83 3c 85 08 27 fb cmpl $0x2,0x1fb2708(,%r8,4) 10b54b2: 01 02 10b54b4: 4c 8b 64 24 30 mov 0x30(%rsp),%r12 10b54b9: 4a 8b bc c6 08 01 00 mov 0x108(%rsi,%r8,8),%rdi 10b54c0: 00
発見した。10b5497 を実行したことで %r10 には 0x10b549e が入る。 もちろん 10b54a5 ではジャンプせず実行が続く。 その後 cmpl を実行し、mov で %r12 に値をロードしたところで、64 バイトズレ問題が起きて、10b54b9 の命令を実行せず 10b5479 の命令を実行すれば、%r10 は変更されることなく、cmp での値は当然一致せず、10b5480 の命令のところでジャンプしてしまう。 これで 64 バイトズレで説明が付く。 確認のため %r12 と %rdi の内容を見る。
(gdb) x/x 0x30+$rsp 0x7ffd64fd3e50: 0x0000000003c815c0 (gdb) p/x $r12 $7 = 0x3c815c0 (gdb) x/x 0x108+$rsi+$r8*8 0x1f3d6a8 <default_target_ira_int+264>: 0x0000000003b74740 (gdb) p/x $rdi $8 = 0x0
矛盾無し。 後は segfault の謎だけ、この cmp hack でズレたまま実行される事象をすべてつぶしたかったが、そううまくはいかないもんだねというところである。 ま、それも、残されたバックトレースが若干変なのはアレだが (なぜか同じアドレスで違うファイル名・関数名が出ている部分が多々ある)、ひとつはシグナルハンドラーの直前のアドレスが命令の途中になっていて、その 64 バイト手前だといい感じに命令の区切りが合うのでそれかなという感じはする。
後は UEFI ファームウェアのアップデートや Linux カーネルのアップデートなど、やってみるべきことはある。 どうもうちではやっぱり 64 バイトズレしか起きていない感じなので、まずは今のファームウェア 0514 03/30/2017 にそろそろおさらばするべきか。 まぁ、あるいは再現プログラムが作れればいいなとは思っているんだけど、それはなかなか難しそうな気が。
プラスの電池かえて順調に「モンスターボールがありません」を連発したw プラスではポケストップよりポケモン発見が優先されてしまう仕組み上、いつまで経ってもボールが増えない悪循環に陥る。
ま、それはともかく、最近接続エラーが増えていたのは電池切れのせいだったのかな、と思ったら、やっぱりあんまり関係ないみたいだ。ZenFone Max との相性の問題なのかも知れない。 いくらボタンを押しても全く見つからないケースは、アプリ側を強制終了してやり直せばだいたい OK。 よくあるのはぶるっと振動して「接続しています」みたいな表示になってからしばらくして黙って切れる、あるいは、エラーが出てブルブルと振動して切れるパターン。 これはしつこくやり直すしか。
他にエラーと出た癖に結局つながっているパターンや、つながっている (画面のアイコンがそうなっていて、ボタンを押すと振動する) のに全くポケストップ等に反応しないパターンもある。 あと、使えていたのがしれっと切れていることがあるし、アプリ側のプラス関連表示だけが固まってしまって、切ろうにも切れず、プラスが事実上使えなくなるケースもある。
アプリ自体も操作によっては操作不能に陥ることがあるが、逆にプラス側は生きていることも多々ある。 しかし、アプリ側が操作不能の場合、プラスはポケモン発見優先の関係で、ポケストップに手を出せなくなってしまうので様子を見てアプリの再起動である。
あと、つながっているのを切ろうとしてアイコンを押すと「探しています」表示になることもある。 これは通知から停止すれば正常に停止できる。 見た目上は普通に切れてもボタンを押すと振動するパターンもあり、そのような場合は、通知も消えていて、アプリを戻るキーで終了しても、プラスのボタンを押すと引き続き振動する状態となる。 あるいは再接続しようとしてもプラス側は接続された状態のままなので再接続できない。 そういう時はいったん Bluetooth をオフにしてからオンにすると再接続できるようになる。 アプリ終了後に切れていない場合アプリの強制終了で切ることができる。(つまりアプリの一部が生き残っているということ...)
九州北部は豪雨被害がひどいらしくって、まだ行方不明者もいるらしいし大変そう。
鹿児島市で震度 5 強とニュースが流れたのがきのう。 地震にある程度慣れてしまった自分でも、震度 5 強は経験したことがないので少し心配ではある。 でも、たぶん、ちょっと物が落ちたり壊れたりはあるかも知れないが、大けがをするほどではないかな? 実際、あまり地震被害のニュースは出ていない気がする。1997 年に川内にいた人は震度 5 強や 6 弱を経験しているだろうけど、あの時鹿児島市は震度 5 弱があったかなー、震度 4 までだったかな、そんな感じだった。
そうそう、川内原発は当然通常運転だ。 何しろ 1997 年のすぐそばで震度 6 弱でも通常運転継続していたんだから、数十キロも離れた鹿児島市で震度 5 強程度では止まるわけがない。
Ryzen の件で as のマクロでへんてこなことをやったが、他にもいろいろできるんだなこれ。.if の式に . (現在のアドレス、MASM の $ みたいなもの) を含む式を書くこともできて、それでこの label からここまで何バイトあったらこれを入れる、みたいなのも表現できるみたい。 あと、知らなかったけど .align に最大バイト数なんて指定があるのね。 アラインメント調整のために必要な領域が最大バイト数を超えるようならアラインメントを合わせないという機能。 古いバージョンにはなかったのかな?
今年の 7 月はやたら暑い気がする。 今朝も朝 8 時台に窓を開けてみたら外がすでにむわーっとすごい温度になっていた。 アメダスの記録をたどると 2011 年が似たような暑さの感じだったっぽい。 ただし 7 月後半は下がっていて、そういえばあの年は、震災の後、電気使用量がやばいんじゃないかと言っていたのが気温が落ち着いて何とかなったんだっけ。 なお、エアコンは相変わらず冷房 30 度設定で夜から朝まで付けっぱなし。 エアコンの風が通る側の温度計は 27 度前後、ベッドあたりの温度計は 28 度前後を指している。
JR 東日本の指定席券売機で回数券を購入し、不要な表紙を駅員の目で券売機の前に放置するだけの簡単な作業。(何も言われなかったw)
GNU as で 1〜数個前のマクロで定義した label を参照する術を考えていたが、連番を振ろうと思ったら、うまいアイディアが浮かばず。 例のマクロの中でマクロを定義するやつなので、それに引数を与えて数字を入れて +1 していけばいいかなと思ったら、+1 してもそれがそのまま計算されずに展開されてしまうため label の名前には入れられない。 数字じゃなくてアルファベットを 1 文字ずつ増やしていくならできるが、そんなことするくらいなら \@ を使って定義して、数個前までの分を引数にずらずらと並べてしまうのが簡単かなと。 見苦しいがマクロといったらたいていそんなものだろう。
東京港フェリーターミナル、なんか見覚えがあるなーと思えば一度ここから新門司まで往復したことがあるんだった。 新門司行きの写真がないが東京行きに乗る前のフェリーの写真はある。 そういえばやたら閑散としたターミナルだったような気はするが、まさか大洗から北海道に行くフェリーがもともとはここから出ていたとはね。 なおフェリーは新型になったみたいなので、また乗ってみたい気もするが、とにかく時間が掛かるんだよなこれ。 四国観光あるいはツーリングでもするんなら有りかな。 でも新門司行きの徳島着が 14 時台で、東京行きの徳島発が 11 時台か、なかなか...
Label の引き算で命令のバイト数を決定できるかと思ったが、ジャンプ命令が挟まるとジャンプ先によってバイト数が変化してしまうため、定数にはならない。 そうすると .if の条件判定には使えないようだ。 うーん。 でも .space は使えるのか...
そんなわけで、新たな実験コードはこんな感じ (途中行が長すぎるので折り返してある):
.macro defhoge2 a,b,c,i
.macro \i o:vararg
hoge \a,\b,\c,\i,\o
.endm
.endm
.macro undefhoge2 i
.purgem \i
.endm
.macro defhoge a,b,c
defhoge2 \a,\b,\c,cmpb
defhoge2 \a,\b,\c,cmpw
defhoge2 \a,\b,\c,cmpl
defhoge2 \a,\b,\c,cmpq
.endm
.macro undefhoge
undefhoge2 cmpb
undefhoge2 cmpw
undefhoge2 cmpl
undefhoge2 cmpq
.endm
.macro alignhoge a,b,c
.space (.-\a==64)*0-(.-\a==63)*1-(.-\a==62)*2-(.-\a==61)*3-(.-\a==60)*4-
(.-\a==59)*5-(.-\a==58)*6-(.-\a==57)*7-(.-\a==56)*8-(.-\a==55)*9-(.-\a==54)*10-(
.-\a==53)*11-(.-\a==52)*12-(.-\a==51)*13-(.-\a==50)*14-(.-\a==49)*15,0x90
.space (.-\b==64)*0-(.-\b==63)*1-(.-\b==62)*2-(.-\b==61)*3-(.-\b==60)*4-
(.-\b==59)*5-(.-\b==58)*6-(.-\b==57)*7-(.-\b==56)*8-(.-\b==55)*9-(.-\b==54)*10-(
.-\b==53)*11-(.-\b==52)*12-(.-\b==51)*13-(.-\b==50)*14-(.-\b==49)*15,0x90
.space (.-\c==64)*0-(.-\c==63)*1-(.-\c==62)*2-(.-\c==61)*3-(.-\c==60)*4-
(.-\c==59)*5-(.-\c==58)*6-(.-\c==57)*7-(.-\c==56)*8-(.-\c==55)*9-(.-\c==54)*10-(
.-\c==53)*11-(.-\c==52)*12-(.-\c==51)*13-(.-\c==50)*14-(.-\c==49)*15,0x90
.endm
.macro hoge a,b,c,i,o:vararg
undefhoge
alignhoge \a,\b,\c
.L_hoge_\@ :
lea (%rip),%r10
cmp $.,%r10
jne hoge_fail
\i \o
defhoge .L_hoge_\@,\a,\b
.endm
defhoge hoge_fail,hoge_fail,hoge_fail
.text
.rept 512
int3
.endr
hoge_fail:
.rept 512
int3
.endr
だいぶ見苦しいが、大小比較を使うとどうもうまくいかなかったので == にしてみた。cmp の位置にテストコードを挿入する時に、15 バイト以内の nop 挿入で前のコードから 64 バイトの位置に合わせられるなら nop を入れてしまおうという代物である。 これで 64 バイトズレた位置に命令がある率が上がるため、問題発生頻度が上がるとおもしろいなと思っているが、果たして。
頻度が上がるようなら、次のステップとしてファームウェアアップデートというのも考えている。 これは後戻りができなさそうな気がするので、今のうちに問題の起きやすい環境を用意しておきたい。 あ、でも、その前に ASLR をオフにしても頻発する状態に持ち込むのが先かな?
ヤマト運輸の宅急便、本当に平日の再配達による自宅での受け取りが厳しくなってしまった。 主に以下の 2 点:
今までどちらも 19 時のところが 20 時だったため、普通に帰宅しても受け取りが可能だったが、19 時から家にいろと言われると無理だ。 これだったら営業所受け取りにして朝取りに行ったほうが簡単だ。 なお、つい先日受け取ったゆうパックは、今のところ 20 時〜21 時の再配達指定が可能だし、ドライバー携帯電話も 20 時まで OK だったので、ますますヤマト運輸がいまいちに見えてしまう。 営業所も 21 時に閉まっちゃうしな、って、それは近くの郵便局もゆうゆう窓口が無くなってしまって残念な感じになっている。
自宅での受け取りを諦めるなら、PUDO ステーションという共同宅配ボックスが一部の最近のセブンイレブンにはあるようで、そこに配達してもらう手はあるらしい。 時代は変わってきている。 また、コンビニ受け取りというのもあるらしい。 いずれにしてもヤマト運輸の会員登録が必要? だかなんだかで、めんどくさそう。 通販だったら最初から営業所止めの指定もできないことは無いのかな? この 6 月・7 月によく受け取るのはだいたい、配達方法の指定もできない & 宛先にこちらの電話番号すら入っていない株主優待の荷物...
アドレス比較のテストコードが 64 バイト手前付近にあればそこに合わせるみたいなやつで、頻度をすごく高めることには成功した。
-rw-r--r-- 1 root root 142835712 Jul 14 23:10 dbg-1500041451.4/core -rw-r--r-- 1 root root 53772288 Jul 14 23:14 dbg-1500041693.7/core -rw-r--r-- 1 root root 48943104 Jul 14 23:18 dbg-1500041939.10/core -rw-r--r-- 1 root root 58232832 Jul 14 23:20 dbg-1500042001.11/core -rw-r--r-- 1 root root 0 Jul 14 23:23 dbg-1500042226.14/core -rw-r--r-- 1 root root 36225024 Jul 14 23:28 dbg-1500042502.18/core -rw-r--r-- 1 root root 53669888 Jul 14 23:30 dbg-1500042656.20/core -rw-r--r-- 1 root root 31170560 Jul 14 23:36 dbg-1500043010.25/core -rw-r--r-- 1 root root 64176128 Jul 14 23:44 dbg-1500043453.31/core -rw-r--r-- 1 root root 0 Jul 14 23:50 dbg-1500043853.36/core -rw-r--r-- 1 root root 19714048 Jul 15 00:08 dbg-1500044925.49/core -rw-r--r-- 1 root root 33472512 Jul 15 00:15 dbg-1500045330.54/core -rw-r--r-- 1 root root 0 Jul 15 00:19 dbg-1500045574.57/core -rw-r--r-- 1 root root 22044672 Jul 15 00:20 dbg-1500045634.58/core -rw-r--r-- 1 root root 21573632 Jul 15 00:23 dbg-1500045796.60/core -rw-r--r-- 1 root root 28372992 Jul 15 00:33 dbg-1500046438.68/core -rw-r--r-- 1 root root 32063488 Jul 15 00:38 dbg-1500046682.71/core -rw-r--r-- 1 root root 47169536 Jul 15 00:47 dbg-1500047241.78/core
よしこれなら、と思って、sysctl kernel.randomize_va_space=0 で ASLR をオフにしてみたら、そのまま朝まで 6 時間以上も一切クラッシュ無し。 うーん、そうなのか... ASLR がどう影響しているというのか... そこがわからない...
スポーツカート耐久レース。 御殿場。 ハイスピードコース。2.5 時間耐久ナイトレース。2 人チームから参加。
スタート車両が予想外に速いことが練習走行で発覚したため、最初のスティントを長くとり、2 人チームの利点を生かし、75 分も走ってもらった。60 代なんですけどね... トラブルは特に無かったが、最初に長いスティントを持ってきたため、自分のスティントで一時トップを走行していたものの、体重の重さと腕の問題でラップタイムは悪いという、何とも珍しい (?) パターン。 スリップストリームが使えた周回は少しマシだったけどなぁ... 順位は 8 位、全部で何台いたんだっけか。
行きは高速、三連休初日故の大渋滞。 渋滞中に事故情報が増えるし、相模湖まで一時間を超え、談合坂 SA はもちろん藤野 PA にまで行列ができていて、なんだこりゃ状態。 でも談合坂を過ぎた後は比較的スムーズだったな。
帰りは富士スピードウェイの前を通って、峠道を抜けた。 峠道の急勾配は真っ暗でいつ動物が飛び出してくるかもわからないところ、途中でいきなり濃霧になり、視界が 10m ほどで心細さが半端ない。 電脳コイルだったらイリーガルに鍵穴が出てきそうな不気味さである (笑)。 帰り方向なので下る側のほうが鹿が出てきそうで慎重に走ったが、こっち側は結構人や車がいた。 コンビニの案内を頼りに道志みち、そこから城山・野猿街道経由で帰宅、2 時間半。 深夜だから最後のほうはそこそこハイペースだったけど、このコースが速いかどうかは謎だな。 相模原 IC のほうに行くほうが速いと思うんだけど、橋本あたりの地図が頭に入っていないのが最大の問題だ。
給油した。131 円/l。 燃費計算 16.7km/l。 燃費表示 17.2km/l。
よく寝た日。
きのうの APG のレースでは合計 70 分近く乗った計算になる。 特にロングスティントで 50 分以上走った時があり、他の人に付いていくのはいろいろ勉強になった。 走り方が正直わからんコーナーというのがいくつかあり、それらで他の人と差が付くかどうか。 体重重い組は、タイヤのグリップは良くても、加速も減速も不利で、唯一有利な可能性があるのが高速コーナーだ。 それも、その後の加速が長ければ取り戻されてしまうから、本当に限られたところだけ。 実際差の付き方を見ているとそんな感じがあって、でもちょっとでもミスれば加速が悪いので一気に離されるし、バトルになってラインがズレると厳しい。 あとおもしろい発見は、勾配の関係でフッと前が一瞬浮いたような感じでハンドルが軽くなる高速コーナーがあるのだが、そこに入るラインを間違えるとかなりアンダーステアになる。 思わずアクセルを抜いちゃうくらい。 たぶん、前が浮く前に姿勢を作っておけばいいのだが、姿勢ができる前に浮いてしまうとアンダーステアなんだな。 こういうの、気づくのにも時間がかかるし、どう対処したらいいかその場ですぐに判断できないあたりが、自分の下手クソなところである。 本当なら、練習走行の間にすべて把握しておくべきところなのだ。
DAZN の今回の Formula One イギリス GP はカクカクしていて 25fps っぽかった。 なんだよ前回だけ特別だったんか? 25fps って昔の 24fps 映画と同じようにぱっと見でわかっちゃうんだよな。
DAZN アプリは KALOS2 ではエラーになって動かない。Nexus 10 でも試してみたら、動くことは動くが、動画再生にスペックが足りないらしく、ぎこちないフレーム落ちが続いた後に映像が止まって音だけになってしまう。
肝心の GP のほうは、途中のベッテル絡みの激しいバトルと、最後の数周のタイヤトラブルが見所だった。 ベッテルはピットストップでアンダーカットを成功させたのは良かったが、それで距離が長くなってしまった上ボッタスとのバトルもありタイヤが持たなかったようだ。 ライコネンはほとんど一人旅でタイヤに負担を掛けることは無かったと思うし、ピットインのタイミングも余裕があったはずなのに、タイヤのトラブルが出て 2 位から予定外ピットストップ、でも 3 位で、なんでかと思えば下にいたフェルスタッペンもタイヤが怪しかったのかフェラーリに合わせて最後にピットインしたんだな。 なんという幸運。
朝方ちょっと雨が降ったが、その後は天気がよさそうなので、ちょっとバイクを動かした。
GSR250S L5 東京〜東名川崎 100km/h 走行 - YouTube
遠出したら帰りの渋滞がやばいことは目に見えていたので、空いている範囲でと思って、単にこの動画を撮りに行っただけなのだが... エンジンの熱気がすごかった (笑) 以前グラストラッカーで同じところを走ったが、こうして動画で見比べると 100km/h 走行がずいぶん楽ちんなのがわかる。 グラストラッカーも、80km/h あたりまでなら十分速いのだが、その先の加速がとてもゆっくりだったし、とにかく振動がすごかった。 もちろん、さすがに単気筒と二気筒の違いは大きいし、エンジン自体がグラストラッカーは低い回転数での力強さが重視されていて、あまり上まで回す仕様では無かったためである。 東名のこの区間はちょっと登るところがあるのだが、確かそこはアクセル全開でやっとかっと 100km/h キープみたいな感じだった。 それに比べれば当然のことながら二気筒の GSR250S は楽勝である。 今回もあえて ETC を使わずに料金所から加速してみたのだが (アクセル全開にはしたが回転数はそんなに上まで回してはいない)、出口の看板よりも手前で悠々と 100km/h に到達してしまっている。
最近の GIXXER なんかは 150cc 単気筒だが意外と速いみたいだ。 最初からそういうのを買っていたら二気筒には変えなかったかも知れない... でも当時は無かったし、二気筒は振動の少なさも魅力なんだよな。 本当にスムーズ。
今にして思えば、中古で 15 万くらいで売られていたスズキ・イナズマ 400、アレにエンジンガードを付けてもらえばそれで多少こかしつつ乗っていたかもなとも思う。 イナズマ 400 がどのくらい速いかわからないけど、レンタルで CB400SF 乗った時にこれに乗ってたらスピード出し過ぎていつか死ぬなというようなことを思ったので、初めてでああいう速そうな四気筒というのはどうなっていたかわからないな。 ま、でも、グラストラッカーの、軽くて足つき良くて原付感覚でほいほいとなぜか高速まで走れる感じはあれはあれで良い経験だった。 ほんと、二輪は車体が軽ければ、多少操縦が下手でも何とかなるというのはある。
電圧が話題なので CPU と何とかの両方を上げてみたが、症状は今まで通り。 まぁ AGESA 古いしね。 正直なところ ASLR 絡みの影響を調べる方法を思いつかないんで、もうファームウェアアップデートしてしまおうかな。
整形外科の待合室で暇なので Gunpei をやっている。 やっぱりパズルモードが楽しい。 地味に難しくなっていくのだが、アクション要素がないのでじっくり考えて解けば良いわけで。 ステージ 32 あたりまでいった。
っていうか、待合室では携帯電話のご利用はご遠慮くださいとなっているので堂々とワンダースワンカラーを使っているわけなのだが、マジ電池持ちが良すぎ。 単三電池 1 本でこの電池持ちはこの手のゲーム機の中では驚異的でしょ...
引き続き整形外科には通っている。 薬は最近はノイロトロピンだけになっている。 頓服で痛み止めをもらっているが、これは 1 回 2 錠なんだけど、軽い痛みが続くような時は 1 錠でもいいから飲んでねとのこと。 例のアレだな、痛みが出ていると脳が反応してしまって悪循環に陥るやつだ。
痛みの症状としては妙で、やっぱり何となくはっきりはしないんだけど、横向いて寝ると何かやらかしやすい感じと、下向くのもやっぱりよくなさそうなのと、カートレースの時はちょっと変かなと思ったがまたしてもなぜかその後は調子が良いというやつ。 いや、まぁ、筋肉痛が出ている間はちょっと変だったけど。
ちょっと興味のあるチラシや、株式関係の書類や、時間がある時にシュレッダーに掛けるつもりの書類など、そういうのをとりあえず目に付くところ、例えば机の上に置く。 次々に増えるそれらをその上に積んでいく。 いつしかそれらはあふれ、あるいは、何かの拍子に崩してしまうなどして、床に散らばる。 早く何とかしないとと思っている間にも、どんどん増える。 そのうち、ゴミ箱やゴミ袋に入れ損ねたちょっとした紙くずなどが床の上で交ざる。 もちろん、埃は区別無く全体に積もる。 その結果、床の上には、古くなって役に立たなくなった書類、シュレッダーに掛けるつもりの書類、紙くずに埃まで、すべて混ざったゴミが堆積する。
みたいな感じ。 ここ数日、久しぶりに片づけをしている。 自分の行動を大きく矯正するのは難しいだろうが、注意すべきは「とりあえず」のところで、せめてそれを時系列に積む、いや、並べてあれば、古いほうから処分するのがだいぶたやすくなる。 特に株式関係の議決権の行使は、株主総会に出席するかその前日までに郵送する等の期限があるので、それまでは意味があるのだが期限を過ぎた瞬間ゴミである。 そういうのが散らかってしまうケースが多発しているので、時系列に並べておきたい。
なお、レシートが財布からあふれそうになっていた時期もあったが、最近はそういうのはあえて服のポケットに突っ込んで、早急に処理するように意識している。 さすがにポケットにあると 1 枚でも結構邪魔なので、このアイディアは思ったよりうまくいっている。
日経平均 (225) は 2 万円をいったり来たり。 手持ちの損益のプラス上位は何年か持っているミクシィと寿スピリッツで、見たこともないすげぇプラス額になっている。 なんでもっと買っておかなかったんだ、みたいな。 特にミクシィなんて分割前に取引単位分は持っておくべきだったよな。 あのときおそるおそる S 株で持っていたんだもんな。
その下に来るのがシャープ、これはまぁギャンブルに当たったみたいなものだが、台湾の会社に買われて本当に良かった。400 円くらいで安定してくれるならそれでいい。
それら以外は地味にプラスなやつと、派手にマイナスなやつがいろいろある。 最近はホンダがマイナス転落である。 一時期グリーの損が減っていたが、また増えてしまった... 損益順でコロプラが最下位にいるのもしばらく続いている。 郵政関連株もゆうちょ銀行以外はぼろぼろだ。 ネタで 20 株だけ買った東芝株はプラスだが、取引単位 1000 なのでプラスマイナスなどどうでもいい額だ。 たぶん 1000 株買っていたら下がっていたに違いない。
ってな感じでやっぱり損益 (買った時と現在の評価額の差分) を見てしまうのだけど、実際のところ減ってしまったものは仕方が無いわけだし、増えたものも減ってしまえば損していると言えるわけで、もっとちゃんと動きを見ておかないとな、と思っても、70 銘柄も持ってれば頭では把握しきれない。 日々の変動をデータ化しておかないとなぁ。 で、損益は何に役立つかと言えば、年末に節税目的で利益額に見合う損が出ているやつを損切りする時かな。
BIOS アップデートした。/proc/cpuinfo で見える microcode は 0x8001105 から 0x8001126 になった。
さっそく試したら、例の 64 バイトズレでの再現頻度を上げたやつで、30 回近く回したのに一度も int3 が実行されない。Segmentation fault は出ていたが、int3 が全く出ないのはこれは挙動が変わったな。 また core を見てみないと、というわけで、その前のバイナリー書き換えで試していた cc1 に差し替えてしばらく回してみる。 またデータ集めからか...
以前の cc1 では純粋に segfault の頻度も低い。36 回で 1 回しか出なかった。 うーん。 確かにそんなもんだったっけなー。 一応例のやつのほうが頻度高いから、シグナルハンドラーをいじった cc1 をビルドするか。 それでしばらく回してみる。
四国発着のフェリーを調べてみたら、結構いろいろあるのね。 これなら、例のやつで徳島に着いた後、観光でもしてから、フェリーで九州に渡る、っていうような選択肢もあり得そうな雰囲気。 それで繁忙期料金もなさそうだから、お盆のところでも... あっ、空き無しか...
結局きのうの夜回していたやつは 6 時間以上数百回回ってもクラッシュは最初の 2 回のみ。 うーん...?
その前に前に使っていた cc1 で試した時に 1 回クラッシュがあって、それら 3 つの core を調べるといずれも一般保護例外だ。 それも、単なるジャンプ命令など、一般保護例外を起こしそうにはない命令だ。 また、前にあった一般保護例外の時とは異なり、あからさまに不審な (48bit の仮想アドレスの範囲を超える) 値のレジスターはなく、64 バイトズレを疑ってもそれらしき命令はない。 そして、3 パターンをそれぞれさかのぼってみたけど不審な点がない。 全部、再開したら動くんじゃね...? というやつ。 また BitVisor 入れてみるかねー。
というわけで入れてみたんだが、案の定一般保護例外からそのまま再開可能だった。 回数が少ないからアレだが、怪しい一般保護例外だけなら多少 OS 側の対処のやりようもあるというものだろう。 と思いながら何度かやっていたら、だめなケースも起きた。%rip がズレてるので見るからに再開は厳しそうだ。 例によって 64 バイト前なら命令境界は合う。 はてさて。
あっ、あと、うちでは nomodeset をつけていれば Linux がいきなり応答しなくなるみたいなトラブルは一切出ていないのだが、BIOS アップデートでもしかして nomodeset つけなくても良くなっているのかどうかも、見てみる必要があるかな。 でも応答しなくなるといちいちめんどくさいんだよな。
古いバージョンの Skype for Linux 32bit 版、7 月に入る前からサインインしっぱなしで、見た目上の変化はなく、エラーも何も出ないのだが、最近ログイン状態が変化しなくなった。 自分の状態が一時退席中から変化しないし (マウスを動かしてもオンラインにならないし、あえて状態を変更しようとしても変化しない)、状態がオンラインでない他人の状態のまるまる以降の表示も、7 月 17 日の 21 時過ぎあたりが最後で、それより最近のものは見当たらない。 アップデートの確認も何も出なくなっているな。 ついに本当に終わったかな。 オンライン人数の表示は 61,892,227 人だ。
しかし、今のところ他人のプロフィールの表示はできているようにも見える。 ローカルにキャッシュがあるのかも知れない。 今回のサービス終了に関する情報を見ていった感じから、なんとなく、先月までのサービスが P2P の生き残りだったんじゃないかと思っているんだよな。 それなら今月頭に案内通りばっさり使えなくならなかったのも (おそらく新たなサインインだけは制限されたのだろうが) 説明がつく。 特にうちみたいにだらだらと動かしっぱなしにしているノードがスーパーノードになっていたとしたら... なっていたのかな? 回線の性能は十分だが、CPU は遅いし RAM も小さいからなー。 しかしこれで、やっと完全に Skype は P2P とおさらばしたのでは。
(あ、そういえば 17 日頃に pulseaudio の再起動か何かやった気がする...)
今日は妙に肩の痛みが出る日。 痛み止めを合計何錠か飲んだ。 姿勢を良くしていれば悪くはなさそうというか、寝ている時に調子が悪いのはいまいちだ。 まー横向いて寝なければいいんだろうけど、うーん。
朝から片づけしてめちゃ汗かいた。 おかしいな、エアコンつけっぱなのに。 そして夜も片づけしたらやっぱり汗かいた。 ふと気づいたけどどうも湿度が関係あるみたいだ。 湿度 73% って高すぎ。 おかしいな、エアコンつけっぱなのに。 それで除湿機もつけるという謎運転により多少快適になった。 普通にエアコンを除湿運転に切り替えればいいような気はする。
部屋の中で何年も手つかずだった場所を多少整理した。 大学時代のもので捨てられないもの、特に学位記や表彰されたものなど、捨てられないのはいいとしても、アクセスの良い棚に突っ込んでおくのは我ながら意味がわからないので、箱に入れることにした。
テレビでやってた映画『パッチ・アダムス トゥルー・ストーリー』(原題：Patch Adams)。1998 年のアメリカ映画。 最後のほうだけまじめに見た。 実在の医師の話らしい。Wikipedia 見るとちょっと劇的に変更されているのかな?
稲城の多摩レクリエーションセンターという在日米軍施設 (元は日本軍の火薬製造所があった場所) でお祭りの日。 最寄り駅は南多摩駅。 健康な多摩川線沿線住民としては素直に是政駅から歩いて行った。 歩いている間からすでに雨粒がわずかながら感じられる時があり、現地のフード行列に並んでいる間に割と降り始めた。 ステーキ食ってドリンク飲んで帰った感じだなw 帰る途中で雨が上がり始めたけどw ま、いい天気で熱中症になるよりは良かったかもね。
横田基地とは違ってアメリカ人が住んでいる感じではなく、完全に「レクリエーション施設」なんだと思う。 そしてお祭り自体もどっちかというと自治体 (稲城市) がやっている風というか、露店や運営やら日本人が多いのね。 横田基地のお祭りだとアメリカ人のほうが多い感じがするよね。
湿度問題、今日も天気が微妙だったからか引き続き起きている。 試しに除湿運転を選んでみたが 30 度設定だと湿度が下がる気配が全くない。 稲城フェスティバルに行っている間 (2 時間半ほど)、除湿で設定温度を 25 度にしておいたら、帰ってきた時、部屋の温度計は 24 度台、湿度は 55% ほどになっていた。 なるほど、設定温度を下げないときかないんだ、この除湿機能は...
で、夜もやっぱり湿度が高いので今度は冷房で設定温度を 28 度にしたら、湿度 70% は切るようになった。29 度だと 70% を超えてくる感じだ。 そして温湿度計の置き場所がエアコンの風の通り道の近くなのは良くないものの、温度は 25 度台まで下がっていて、風の当たるところにいるとめっちゃ寒い。 と書いている間によく見たら 70% 超えてきたじゃないか... 28 度設定なのに... 何これどうなってるんだ... 外気温との関係なのか...
もっと高級なエアコンだと違うんだろうが、この備え付けの安いエアコンだと、除湿機との併用にもメリットはあるということか。 温度の調節はエアコンにまかせて、湿度を除湿機で強制的に下げると。
レンタルカート。 飯能。3 回乗ってベストタイムは 34.5 秒くらい。7 コーナーインリフトできないかな? というのは次の課題ということで。
ポケモン GO が何かお得な日ということみたいなので、ポケモン GO プラスを持って飯能にバイクで行った。 ポケモン GO の距離を稼ぐために、あえて 30km/h の道に回り道をして、昭和記念公園のほうに出て... おやっ、立川基地跡の広い道路が開通しているぞ! 知らなかった! 最近、武蔵村山のイオンにあまり行っていないからなぁ。
ＵＲ都市機構|立川基地跡地昭島地区|事業の進捗状況｜お知らせ
4 月 10 日に開通したということか。 武蔵村山のイオンがちょっと近くなった気分。 まーそんな感じで地図も見ないでうろうろして、のど乾いて一休みして、ポケモン GO の卵が孵っていたので別の卵をセットして、みたいな感じだったが、例によってモンスターボールはあっという間に使い果たし、ポケストップのアイテムはほとんど回収できないという残念パターンのまま飯能に到着。 そうそう、青梅経由で行ったらトンネルの中がめちゃ涼しかった。
帰りは、軍畑という、読めない地名のほうに行ってみた。 読みは「いくさばた」、あまりにも予想と違ったため、案内標識のローマ字をチラッと見ても読めず、何度も見直した。 軍畑駅という青梅線の青梅駅〜奥多摩駅の間の駅があるようだが、山間部らしく結構な高さの陸橋? 鉄橋? みたいなのがデーンと通っていてかっこいい。 単線だけど、ちゃんと電化区間なので架線も見える。 ちょっとなんか旅しているような気分になる風景、これでも東京都内なんだもんね! なお、多摩川を越えて左折するところまでは地図を確認してあったが、その先は案内に従っていけば何とかなるだろと、適当に走っていったら例によって案内がいまいちで、ちゃんと帰る方向に向かっているのかだいぶ不安になる帰り道だった。 ま、でも、知らぬ道をのんびり走るのはバイクの楽しみのひとつだ。 何しろ車と違って譲るのがとても楽なので、家路を急ぐ皆さん (かどうかは知らないけどラッシュの始まる時間帯だった) にはどんどん先を譲って、その後ろをのんびりついていけばよい。
帰って片づけをしていたら肩の痛みが... 予想はしていたが、やっぱり片づけなんかをする時の自分の姿勢は神経に厳しいみたい。 バイクに乗っている時も、(よく言われるように) 背筋を曲げて、しかし顔を上げて乗ると厳しい。 背筋を伸ばして顔をまっすぐにするか、背筋を曲げたら顔も下を見ちゃうくらいでないと。 カート? カートの乗車姿勢自体は割と理想的な感じだけど、今日のラー飯能の場合結構縁石を使うので、そのときの上下動はあまり良くはなさそうな感じがする。
片づけで出てきた、賞味期限が 3 か月前に切れていたバーモントカレーのルウを華麗に消費した。 バーモントカレーの中辛は全く辛くないので、水を結構少なめで作っちゃうくらいで良い感じ。
合成皮革? か何かのいすがぼろぼろになっていたのはもう何年も前の話。 それで、スツールのほうはいらなくなった T シャツをかぶせてごまかしてあったのだが、いすのほうはサンキで布を買ってきて、それをタッカーで張り付けようと思ってダイソーでタッカーと針を買ってきたところまでは良かったものの、いつの間にかタッカーが行方不明になり、それで 1 年以上放置していた。 その間にぼろぼろさが悪化しそこら中に黒いカスみたいなのが散らかる始末... 今回片づけでタッカーが発掘されたので、重い腰を上げて作業した。 もう寿命なんだろうけどね、このいす...
朝イチで整形外科に行くとだいたい待ち時間が短くて済むケースが多いが、そうでない日もある。 今朝は短かった。 待合室でいつも同じメンツを見かけている気がする。 いつも話好きそうなおじさんが楽しそうに会話している。 明石家さんまなんかも将来病院通いになったらあんな風になるのかな、みたいな。
出勤前に朝イチで整形外科に行くためには、普段より早く家を出て、バスか鉄道を使うかその他の手段で向かわなければならない。 バスだとだいぶ早く出なきゃなんないので、鉄道かその他になる。8 時半前後の鉄道というのは、まー西武線は短い路線なのでいいが (それでも駅員が改札に出ているなど忙しそうで、乗車券も見る気がなさそうな 9 時半とは雰囲気が違う)、JR 線は当然のことながらまだまだ通勤ラッシュの時間帯である。 でも 7 時台よりはずっとマシで、せいぜい 1 本待つ程度でよい。 特別快速等の待ち合わせ・通過待ちになる列車のひとつ前は混みやすい傾向もある。 それ自体は意外と楽なのだが、駅を歩く人が多く、殺伐とした雰囲気で足音がザッザッと響くのを聞くのはあまり好きになれない。
たまごの距離が 1/3 になるやつ、ふかそうちのところに x0.33 みたいに出ているのだが、セットした瞬間は 1/3 になっていなくて、いったん閉じて開き直すと距離が縮んでいるというなんだかバグっぽい挙動。 きのうはバイクだったので 10km たまごとか 5km たまごとかを入れていたんだけど、今日は帰りにちょっと歩いて 2km たまごを何個か孵化させた。 今野生のポケモン出現頻度も上がっているんだっけ? とにかくボール不足でポケモン GO プラスユーザーには厳しい。
今日は雨降ったし、天気予報の週間天気が不穏な感じになってきたぞ... まぁ台風もあるのでそのせいかも知れないけど、なんか 7 月下旬に天気がすっきりしないのは 1993 年を思い出して良くない。
帰りのバスでせっせとポケストップからアイテムをかき集めたw さらにちょっと自宅まで遠回りして 2km 卵を孵化させるなど。
なんか最近のアップデートからだと思うんだけど、ポケモンボックスを開いてチェックして博士に送ってみたいな操作をしていると割と短時間で突然終了するようになった。 実にメモリーリークっぽい感じがぷんぷんと漂っているのだが...
最近宣伝されている『メアリと魔女の花』、米林宏昌監督という共通点によりこないだテレビで『思い出のマーニー』をやっていたわけだ。 『メアリと魔女の花』は絵もジブリっぽいからジブリなんだろうと思い込んでいたが、スタジオポノックだと。 なんだそれ??? と思って調べてみたら、ジブリの制作部門は 2014 年で終わってしまっていて、そのメンバーがスタジオポノックに引き継がれているような感じらしい。 へぇー。
びっくりなのは場所。 武蔵野市境南町って、原付なんかでよく通るところじゃないかw スタジオジブリも隣の小金井市だし、三鷹の森 ジブリ美術館は隣の三鷹市だし、武蔵野市内にある職場のビルにもアニメーション制作会社が入っているし、他にも中央線沿線に何かあったっけ? 漫画家の福本伸行も武蔵野市だっけ。
最近の片づけで発掘された書類を処理する。 以下のようなものそのもの、または、それが入った封筒があった。
こんな感じでしれっと危ういものが混ざっていて大変油断ならない内容。 これに加えて大量のレシート、それに、明らかなゴミ (弁当についてきた割り箸の入っていた紙など) も混ざっていてカオスだった。 幸い腐るような生ゴミは混ざっていないが、誰だこんないい加減なことをしたのは...
結局封筒を開けて中身を確認していくだけで小一時間。 さらに大量のレシートを処理するのに小一時間。 そして出てきた大量のゴミ。 疲れた。
先日試した首都高遠回りライド。 請求は、「自永福上 至高井戸 軽・二」でなんと 270 円! 「上」って出ているから上り方向の料金所を通過しているのは記録されていて、C2 かそれより内側まで入ったことは明らかなのに、1 区間の計算になるのね。 今回は C1 ぐるりで終わりだったけど、神奈川県に入ってきても同じなら、昔の定額時代よりも割安になったということになるな。
毎年恒例の花火大会。 仕事帰りに電車で。
露店で焼きチャーシュー? みたいなのをだまされたと思って買ったら意外と美味かった。 まともに肉だしキャベツも入っていて満足度が高い。 フライドポテトはまーこんなもんかという味だった。
遅れて行ったもので (駅の改札を出る前に打ち上げ音がし始めた) 屋根が邪魔で見えない。 うろうろしてほっそい隙間から何とか見える場所を見つけた。 休憩の時間に奥に進めたが、めんどくさくなって近くのいすをゲット。 結局休憩後も屋根が邪魔で見えなかったw 最後の名物ナイアガラの滝くらいだな、ちゃんと見えたのは。
帰りは歩いてみた。 小一時間で着くはず、と、北門から出て、途中ポケモン GO のジムバトルなどして (今のスタイルになってからうまくバトルできたの初めて)、踏切で待ち、自販機でジュースを買い、再び踏み切りで待ち、という感じで 50 分ほどだったか。
テレビでやってた映画『ジュラシック・パーク』(原題: Jurassic Park)。1993 年のアメリカ映画。 コンピューターグラフィックスが映画でたくさん使われ始めた時代の映画。 そうはいってもこの映画でコンピューターグラフィックスが多用されているのは恐竜のところが主ではないだろうか。 とは思うんだけど、当時の制作スタッフは、お金はかかるけど迫力のある映画が作れるぞ、というような思いは強かったんだろうな。 この当時のクオリティーは今だと数万円のパソコンでも実時間で表現できるレベルだろうか?
あまりよく見てないけど、出てくるコンピューターの画面が、あまり現実離れしていない感じがあってよかった。 一応 GUI っぽいし、1993 年当時はまだ Windows 95 が出ていない頃だから、あ、でも SGI のワークステーションなんかだと結構それっぽかったのかな、そうだよな、コンピューターグラフィックスのためにその手の最先端のワークステーションは使われていたはずだから、そのへんにインスパイアされているのかも知れないな。
字幕無しの英語音声で見ていたら "It's a Unix system, I know this." なんてせりふが出てきて笑ったw しかも子供のせりふw
レンタルカート。 藤野。3 回乗ってベストタイムは 39.910 秒。2 回目の走行中にほんの少し小雨がぱらついたが影響なし。
朝の中央道下りは渋滞していた。 この前の三連休ほどではないが、日野バス停までの区間と、八王子 JCT (圏央道との分岐) あたりからずっと。 夏休みの慣れない人達だろうなーという感じ。 八王子 JCT〜相模湖 IC あたりは勾配変化が地味に激しいので、運転に慣れてない人は速度変化が激しく、交通量も多いのですぐ渋滞につながる。 まぁでも子供が夏休みで出かけている家族なのか、レンタカーで出かけている夏休みの学生達かはわからない。
帰りは甲州街道経由で飯食って帰宅。 てんすいのイタリアンハンバーグはお気に入りで、数か月ごとに食べている気がする。 ハンバーグ自体はかためのしっかりしたやつ、それにいい感じに溶けたチーズと焼けたチーズがあって、いい感じ。
今日の DAZN Formula One 予選は 50fps だった。 やはり 25fps より良い。 マッサ体調不良で代役にまさかのポールディレスタ登場。2009 年のルカ・バドエルやジャンカルロ・フィジケラの件があるので、数年のブランクを経てフリー走行無しでいきなり予選だったのに、最後尾にならなかったのは立派かな。 シミュレーターは経験していただろうけど、さすがにフリー走行無しというのは厳しいよね。 今年はアントニオ・ジョビナッツィも急遽代役があったっけ、でもあれはフリー走行 1 回は走ったんだな。 そもそも今回はウィリアムズのマシンがあまりにもだめなようで、多くは望めないみたいだけど。 そういえばスーパーライセンスはあったんだな?
首... から来る痛みだが、姿勢によって痛みが出る姿勢があるのだと思う。 それが、たぶん、最初はとても弱い痛みで、その姿勢を保っているとそのうち強くなるのではないかと。 だから、ちょっと違和感があるといえばあるかな程度の時に、気づかないでそのままでいると普通に痛みが出てきて、あっ、ってなる。 前より痛みの出ない姿勢が限られて来ている感じはする。
よく寝た日。
Formula One ハンガリー GP。 なんで予選は 50fps だったのに決勝は 25fps なの DAZN... ま、それはいいとして、追い越しが難しいとされるハンガロリンクで、見た目上は割と地味だがタイムは近く攻めてギリギリでやり合っているという手に汗握るトップ争いが続いて、おもしろかった。 タイヤが摩耗してきているかどうかは、見た目上の変化がある場合はわかりやすいが、そうでなければラップタイムがひとつの指標ではあるものの、単にいたわって走っている場合もあるので、観客からはわからないこともある。 しかし、異なるチーム同士のバトルとなれば、お互い攻め続けるから、限界を超える場面がチラチラ見え始める。 ライコネンもたまにブレーキングで前タイヤをわずかにロックさせていたし、ハミルトンもコーナリング中に滑って修正するところが映っていた。
あ、そうそう、マクラーレンも今回ポイントとれたみたいで良かったね。 今回はルノーが意外と好調だったが、パワーユニットの出力はホンダとルノーが同じくらいなんだろうか? 車体性能的にはまだトップ 3 チームには届かない感じだな。 レッドブルもパワーユニットがいまいちだけど確実に上にいるもんな。 アロンソもいろいろ口数は多いけどレースでは最大限の結果を残すところはさすがとしか。
去年 5kg 太って、今年はそこから 1kg くらい減ったか減らないか、あたり。 晩ご飯の調整とほんのちょっとだけ筋トレ的なものを意識するくらい。
晩ご飯は、白飯を抜いてタンパク質を中心にするべく肉やら何やらで脂っこいのを食うと、自分の場合胃に来る。 白飯を胃に入れるとそれが油分を吸収して和らぐ感じなのではないか、みたいなイメージ。 で、最近たまにやるのはその白飯の代わりにサラダを食べる。 本当は生野菜より火を通した野菜のほうがいいのかも知れないけど、とりあえずサラダにしている。 普通に白飯を食ってることも多いが、甘いジュースなんかを飲みたい時には抜いている感じか。
夜、帰宅時の部屋の温度が 30 度。 そこで設定温度 30 度の冷房を入れ、しばらくしたら温度は 25 度台になり、湿度は 60% を切って「快適」表示になった。 ただしその温度計はエアコンの風がすぐ近くを通っているであろう位置にある。
数時間後に見ると温度は 27 度台、湿度は 70% を超えていた。 エアコンは引き続き風を出している。 うーん。 想像では、最初は温度を下げようとしてコンプレッサーは強めに稼働し、その結果湿度も下がったが、その後は温度を保とうとして風は出しつつもコンプレッサーは弱めに稼働し続け、その結果湿度は上がった。 的な感じなのだろうか?
何が言いたいかというと、カシオ IDL-150NJ は時計も温度も湿度も見やすくて気に入っている。
そういえばポールディレスタは残念ながら途中リタイアだった。 というか、ウィリアムズは 2 台ともぐだぐだなレースだった。 ここ 5 年くらいのウィリアムズってずっと直線番長では? 同じパワーユニットのフォースインディアにももう完全に負けてしまっているよなぁ。 ボッタスは移籍して正解でしょ。
メルセデスは前後入れ替えてフェラーリを追いかけさせた。 結局抜けなかったので最終的には順位を戻した。 最初からハミルトンはチームメイトをオーバーテイクしていれば良かったのかも知れないが、この抜きにくいコースで同じ車のオーバーテイクが成功していたかどうかは怪しい。
フェラーリは逆に順位を入れ替えなかった。 ただしフェラーリのことだから、どういう状況であっても、コンストラクターズポイントを最大限得ることを最優先にしていたのだろうとは思う。 ベッテルが苦しみながらも最低限のペースを得られていたからというか、仮にメルセデスがもっと厳しくライコネンを追いつめていたなら、ライコネンは逃げるために必然的にベッテルにプレッシャーを掛けることになり、そうなっていたらベッテルが譲る可能性はあるとは思っていた。2 台とも抜かれて 2, 3 よりは 1, 3 になるほうがマシなので。 しかし実際には今回メルセデスはそこまで速くなかった。 フェラーリのセクター 3 が速かったというのも影響していたんだろう。
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU