11/12 宮ケ瀬湖をグルっとしてきた
宮ケ瀬湖の位置はここです
続きを読む二日酔いで午後までボロ雑巾、夕方にトレーニング走
皇居周辺を走った後に、リアディレイラーの不調をみてもらうべく トレックストア六本木に立ち寄り
ジャパンカップ や ツール・ド・フランスさいたまクリテリウム で別府選手が乗っていた Madone が展示されていた。ラッキ〜
BEPPU のロゴ、見えるかな?
しばし鑑賞。差色の赤がよい感じにアクセントになってネオンカラーを引き締めている
もはや「自転車」のイメージからかけ離れているね。戦闘機やF1 のようなシルエット。相当に速く走れないと似合わなそうだ!!!
やったぜ2連覇!!みんな応援ありがとう!! 🇯🇵 📸: @keitsuji pic.twitter.com/KbMCplTjUK
— Fumiyuki Beppu (@Fumybeppu) 2016年10月22日
二連覇、おめでとうございました。ぱちぱち
リアディレイラーの不調はシフトケーブルが錆びて断線気味だったのが原因らしい。修理費用は交換のケーブル代だけで格安 (900円) 。加えて、BB周りが錆びにやられていたとのことでオーバーホールもすすめられた。(ついでにコラムカットも一緒にやれますよ とお得情報) 。アフターケアが手厚い。
錆びの原因を思い返してみたが、以前に 大雨の宇都宮〜日光を走っていて 予後のメンテナンスが不十分で内部まで浸水していたのだろう。がーん
CentOS7 で BUG: unable to handle kernel NULL pointer dereference at (null)
で kernel panic したのを深追いで調べていた
[705327.823158] BUG: unable to handle kernel NULL pointer dereference at (null) [705327.824009] IP: [<ffffffff81573762>] skb_entail+0x52/0xd0 [705327.828140] PGD 18fe72067 PUD 18fe73067 PMD 0 [705327.828140] Oops: 0002 [#1] SMP [705327.828140] Modules linked in: dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag nls_utf8 isofs ppdev i2c_piix4 sg parport_pc virtio_balloon parport pcspkr nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sr_mod cdrom ata_generic pata_acpi cirrus virtio_blk virtio_net syscopyarea sysfillrect sysimgblt drm_kms_helper ttm ata_piix crc32c_intel drm virtio_pci virtio_ring serio_raw libata virtio i2c_core floppy dm_mirror dm_region_hash dm_log dm_mod [705327.837099] CPU: 0 PID: 2790 Comm: nginx Not tainted 3.10.0-327.36.1.el7.x86_64 #1 [705327.837099] Hardware name: Red Hat Inc. OpenStack Nova, BIOS 0.5.1 01/01/2007 [705327.837099] task: ffff880036a1dc00 ti: ffff88018fcbc000 task.ti: ffff88018fcbc000 [705327.837099] RIP: 0010:[<ffffffff81573762>] [<ffffffff81573762>] skb_entail+0x52/0xd0 [705327.837099] RSP: 0018:ffff88018fcbfb88 EFLAGS: 00010202 [705327.837099] RAX: 0000000000000000 RBX: 0000000000003890 RCX: 00000000ffffffff [705327.837099] RDX: ffff8801089c9038 RSI: ffff8801089c9038 RDI: ffff8801089c8f00 [705327.837099] RBP: ffff88018fcbfb88 R08: 00000000000006c0 R09: 0000000000000900 [705327.837099] R10: ffff880217001400 R11: 8883e3b982e39d83 R12: 0000000000000000 [705327.837099] R13: ffff8801089c8f00 R14: ffff8801089c9038 R15: 0000000000000fb0 [705327.837099] FS: 00007fca72598840(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 [705327.837099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [705327.837099] CR2: 0000000000000000 CR3: 000000018fe71000 CR4: 00000000000007f0 [705327.837099] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [705327.837099] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [705327.837099] Stack: [705327.837099] ffff88018fcbfc50 ffffffff81577bf2 ffff880036a1e688 ffff880000000001 [705327.837099] 0000000000000050 ffff88018fcbffd8 0000000000000000 ffff880036a1dc00 [705327.837099] ffff88018fcbffd8 ffff88018fcbfe70 00000000011b4df9 0000000000000501 [705327.837099] Call Trace: [705327.837099] [<ffffffff81577bf2>] tcp_sendmsg+0x6f2/0xc20 [705327.837099] [<ffffffff815a1c04>] inet_sendmsg+0x64/0xb0 [705327.837099] [<ffffffff815103d7>] sock_aio_write+0x157/0x180 [705327.837099] [<ffffffff811de5d9>] do_sync_readv_writev+0x79/0xd0 [705327.837099] [<ffffffff811dfbae>] do_readv_writev+0xce/0x260 [705327.837099] [<ffffffff81058aaf>] ? kvm_clock_get_cycles+0x1f/0x30 [705327.837099] [<ffffffff810d896a>] ? __getnstimeofday64+0x3a/0xd0 [705327.837099] [<ffffffff811dfdd5>] vfs_writev+0x35/0x60 [705327.837099] [<ffffffff811dff8f>] SyS_writev+0x7f/0x110 [705327.837099] [<ffffffff81646a09>] system_call_fastpath+0x16/0x1b [705327.837099] Code: 4d 00 89 46 44 89 46 40 8b 86 dc 00 00 00 c7 44 02 24 01 00 01 00 48 8b 87 40 01 00 00 48 8d 97 38 01 00 00 48 89 16 48 89 46 08 <48> 89 30 83 87 48 01 00 00 01 48 83 bf 68 02 00 00 00 48 89 b7 [705327.837099] RIP [<ffffffff81573762>] skb_entail+0x52/0xd0 [705327.837099] RSP <ffff88018fcbfb88> [705327.837099] CR2: 0000000000000000
以下、調べてみてのわかったことと推測
NULL pointer dereference が起きた状況は整理できたが、なぜこうなったのか、根本的な原因はよくわからない。ググってみても「これ」といったものは発見できず
調べていったログを記しておく (全体を整頓しきれていないので、情報が飛散しているのはご了承を)
続きを読むCentOS7 で ipcs-m
を実行すると下記のような出力になる
$ ipcs -m ------ 共有メモリセグメント -------- キー shmid 所有者 権限 バイト nattch 状態 0x00000000 113934337 root 600 40 9 対象 🍣
🍣 部分の 対象 って訳されているのが何なのだろうと気になってしょうがない
$ LANG=C ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 113934337 root 600 40 9 dest
デフォルトロケールでみてみると dest となっている
pthread_mutex_destroy(3) のソースコードリーディングを hiboma/hiboma に push した
pthread_mutex_destroy(3) 済みの mutex を pthread_mutex_lock(3) しようとすると EINVAL を返すが、Linux (正確には NPTL だろうか) ではどんな実装か気になったので読んだ
-1
をセットしているだけだった。
システムコールやライブラリ関数で EINVAL を返すものはよく見かけるが、何がどうなって Invalid なのだろう? と度々疑問になる。そういう時はソースを読む
shmdt(2) のソースコードリーディングを hiboma/hiboma に push した
shmdt(2) したアドレスで segmentation fault を起こす問題をリサーチしていた。man を呼んでも不明瞭な箇所があり、どんな実装か気になったので読んでいた
というあたりが解消された
読んだ感想としては
struct vm_area_struct
の扱い方のお勉強によさそうといったところ
ソースコード(主に Linux カーネル) や技術書を読んだ際の軌跡や、デバッグやトラブルシューティングの履歴などを残しているリポジトリです。