コグノスケ

首都高バトルSteam版、フルチューン後の姿 - その3

目次: ゲーム

首都高バトル（Steam版）高ランクの車をひたすらフルチューンするやつの続きです。前回と合わせて8車種ほどフルチューンしました。もう飽きました。

SUZUKI SWIFT Sport(ZC33S)フルチューン

TOYOTA SUPRA RZ(JZA80)フルチューン

検索用にフルチューン後の主要パラメータを書いておきます。ちなみにスピード指標はギア比を最高速重視にすると高い数値になるので、参考程度です。

あとはインプレッサのどれかをフルチューンするかもなあくらいですが、あまり気力が沸きません。

ローダウンの謎

アップデート前は車高は下げれば下げるほどカーブが速くなる謎システムでしたが、アップデート後は限界まで車高を下げるとストレートで地面と擦って火花が出る＆逆に遅くなる変更が入ったそうです。キャプチャでは5段階のうち4まで下げた状態で撮っています。個人的には見た目は3か2くらいが一番バランスが良いですね。

RX-7のフロントRIDE HIGHT = -5

5まで下げるとおかしなことが起きる車もあって、RX-7はフロントを限界まで下げるとタイヤがフェンダーとボンネットを貫通して変な表示になります……。

timespecの操作関数

目次: C言語とlibc

POSIXには時間を表す構造体が2つあります。マイクロ秒単位のstruct timevalと、ナノ秒単位のstruct timespecです。struct timespecの方が後発なのか、比較的新しいAPIはstruct timespecを使う傾向にありますが、基本的には混在しています。

struct timeval {
    time_t      tv_sec;     /* 秒 */
    suseconds_t tv_usec;    /* マイクロ秒 */
};

struct timespec {
    time_t tv_sec;     /* 秒 */
    long   tv_nsec;    /* ナノ秒 */
};

見てのとおり構造体ですから、足し算や引き算をするにも桁上がりを考える必要があって一苦労必要かと思いきや、POSIXはtimeradd/timersubなどのマクロを用意しており、struct timevalの加減算と比較などが比較的簡単に行えます。便利ですね。

ではstruct timespecにも同様にtimespecadd/timespecsubがあると思いますよね？ところが一部のlibc（BSD系やnewlib）以外は実装していません。なぜ……！？

#define timespecadd(a, b, res)					\
	do {							\
		(res)->tv_sec = (a)->tv_sec + (b)->tv_sec;	\
		(res)->tv_nsec = (a)->tv_nsec + (b)->tv_nsec;	\
		if ((res)->tv_nsec >= 1000000000) {		\
			(res)->tv_sec++;			\
			(res)->tv_nsec -= 1000000000;		\
		}						\
	} while (0)
#define timespecsub(a, b, res)					\
	do {							\
		(res)->tv_sec = (a)->tv_sec - (b)->tv_sec;	\
		(res)->tv_nsec = (a)->tv_nsec - (b)->tv_nsec;	\
		if ((res)->tv_nsec < 0) {			\
			(res)->tv_sec--;			\
			(res)->tv_nsec += 1000000000;		\
		}						\
	} while (0)
#define timespecclear(tsp)    ((tsp)->tv_sec = (tsp)->tv_nsec = 0)
#define timespecisset(tsp)    ((tsp)->tv_sec || (tsp)->tv_nsec)
#define timespeccmp(a, b, cmp)					\
	(((a)->tv_sec == (b)->tv_sec) ?				\
		((a)->tv_nsec cmp (b)->tv_nsec) :		\
		((a)->tv_sec cmp (b)->tv_sec))

いつもstruct timespecを要求するAPIを使うたびにtimespecadd/timespecsubがなくて演算しづらさにイライラするので、コピペで使い回せるように実装例をメモしておきます。この程度なら誰が書いてもほとんど同じコードになると思いますが、気になる方のためにもし著作権が発生する場合はBSD 3条項ライセンス扱いでお願いします。

JavaとM5Stamp C3とBluetooth LE - Bluetoothデバイスとの通信改善

目次: Arduino

M5Stamp C3 + Raspberry Piを組み合わせて作った的あてゲーム、秋葉原のTarget-1（お店のサイト）で壊れることなく1年ほど安定稼働しているようです。良かった良かった。しかし最近、故障ではないもののタイトル画面に戻ってしまう頻度が増えているそうです。

ゲーム画面の例

以前に日記で紹介したとおり、的あてゲームのシステムはM5Stamp C3をBluetooth LEデバイスにして、Linux PCもしくはRaspberry PiなどのLinux SBCと通信しています。Bluetoothの接続が切れるとタイトル画面に戻って再接続する実装にしていますので、不意にタイトル画面に戻る = Bluetoothの接続が切断されていることを意味します。

原因の仮説と対策

お店での運用を見ていると、ゲームリザルト画面で放置されることが多いです。今の実装ではリザルト画面でBluetoothの通信を一切行いません。あまりにも長い間通信しないとBluetooth接続が切れてしまう？のかもしれません。

とりあえず今回は小手先の対処として、リザルト画面でM5Stamp C3本体のLEDを点滅させる指令を送り続け、Bluetooth接続を維持するようにしました。家でテストしてみたところ1日以上放置しても接続を維持できています。

代償として消費電力が0.1Wくらい増えますが、何度もタイトル画面に戻されるよりはマシでしょう……。

目指すは先代の実績？

先代のTSS（ターゲットシューティングシステム、作者さんの紹介サイト）は5年位稼働していたらしい（すごい！）ので、追いつくにはあと4年ですか、長いな〜……。

4年後を考えてみると、Linux側のマシンROCK 3Cはほぼ確実にEOL（End Of Life、生産終了、販売終了）だと思います。Linux側のシステムはHW依存は少ないし、SWも枯れたやつが多いので、そのとき販売されているお買い得なARM SBCボード（Raspberry Pi 6とか7とか？ROCK 3C後継のボードとか）への乗り換えは容易だと思います。

困るのはM5Stamp C3ですね。EOLになると別ボードへのSW移植とドッキングするためのボード再設計が必要でしょう。M5Stampは安くて良いんですけど、世代ごとに形がガンガン変わって互換性ゼロなのが良くない点ですね。作り直すとしたら、今のM5Stamp C3の2枚使い設計はダサいので、I/Oピン数の多いボード1枚に改めると思います。

signalの未定義動作を見る - その1

目次: C言語とlibc

シグナルマスクのマニュアル（sigprocmaskのマニュアル）を見ると下記のように「規定されていない」とあります。実際Linuxだとどうなるか気になります。

マルチスレッドのプロセスでsigprocmask()を使用した場合の動作は規定されていない。

実行環境は下記のとおりです。他のプラットフォームや過去/将来のバージョンのLinuxで今回の実験結果と同じ動作をするとは限りませんのでご注意ください。

• Debian Testing (trixie/sid)
• Linux 6.12.12-1

実験内容は5つのマルチスレッド（親スレッド＋4つの子スレッド）で全員でsigwait()するのは共通、誰がsigprocmask()を呼ぶか？を変えながら、下記4パターンを試します。

• 最初のスレッドがsigprocmask()
• 最初のスレッド「以外」の1スレッドがsigprocmask()
• 全スレッドがsigprocmask()
• 全スレッドがpthread_sigmask()

最後のパターンはマルチスレッドでsigwait()する場合の正しい方法（全スレッドがpthread_sigmask()）で、他の3つと動作を比較するためのものです。

プログラム

コードは長くなってしまったので最後にファイルへのリンクを張っておきます。

実験方法はコンパイル時にマクロを適宜切り替えて、生成された./a.outを起動し、別のターミナルからkillコマンドなどでSIGUSR1を送るだけです。

結果1 - 最初のスレッドがsigprocmask()

最初のスレッドがsigprocmask()した場合です。ゆっくり5回シグナルを送ると、親スレッド（th 4）のsigwait()がシグナルを受け取り、子スレッド（th 0）のsigwait()はEINTRが返ってきます。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK -DID_MAINTHREAD=4 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: sub  (child ) thread start
th  1: sub  (child ) thread start
th  2: sub  (child ) thread start
th  4: main (parent) thread start
th  4: sigprocmask(block)
th  3: sub  (child ) thread start
th  3: loop start
th  2: loop start
th  4: loop start
th  0: loop start
th  1: loop start
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)

一見すると良い感じに動くように見えますが、大量にシグナルを送りつけるとabortします。ありゃりゃ。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK -DID_MAINTHREAD=4 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: sub  (child ) thread start
th  1: sub  (child ) thread start
th  2: sub  (child ) thread start
th  4: main (parent) thread start
th  4: sigprocmask(block)
th  3: sub  (child ) thread start
th  3: loop start
th  1: loop start
th  0: loop start
th  2: loop start
th  4: loop start
ユーザー定義シグナル1


（別ターミナルから）
$ while :; do kill -USR1 123450; if [ $? -ne 0 ]; then break; fi; done

一見動くように見えて、だめなパターンですね。

結果2 - 最初のスレッド「以外」の1スレッドがsigprocmask()

最初のスレッド「以外」の1スレッドがsigprocmask()した場合です。1回シグナルを送っただけでabortしました。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK -DID_MAINTHREAD=0 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: main (child ) thread start
th  0: sigprocmask(block)
th  1: sub  (child ) thread start
th  2: sub  (child ) thread start
th  4: sub  (parent) thread start
th  3: sub  (child ) thread start
th  3: loop start
th  0: loop start
th  2: loop start
th  1: loop start
th  4: loop start
ユーザー定義シグナル1

結果1の動きを見る限り納得の結果と言えるでしょう。シグナルは常に親スレッドにも飛んでいたので、シグナルをマスクしてない親スレッドはabortするのはそりゃそうだなと思います。

続きはまた今度やります。

ソースコード

こちらからどうぞ。

•  ソースコード

signalの未定義動作を見る - その2

目次: C言語とlibc

シグナルマスク（sigprocmaskのマニュアル）の「規定されていない」使い方をするとどうなるか？の続きです。5つのマルチスレッド（親スレッド＋4つの子スレッド）で全員でsigwait()するのは共通で、誰がsigprocmask()を呼ぶか？を変えながら、下記4パターンを試します。

• 最初のスレッドがsigprocmask()
• 最初のスレッド「以外」の1スレッドがsigprocmask()
• 全スレッドがsigprocmask()
• 全スレッドがpthread_sigmask()

今回は結果3と4を紹介します。1〜3は定義されていない動作ですが、4は比較用に実施する「正しい方法」です。

結果3 - 全スレッドがsigprocmask()

全スレッドがsigprocmask()した場合です。ゆっくり5回シグナルを送ると、親スレッド（th 4）のsigwait()がシグナルを受け取り、子スレッド（th 0）のsigwait()はEINTRが返ります。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK_ALL -DID_MAINTHREAD=1 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: sub  (child ) thread start
th  0: sigprocmask(block)
th  1: main (child ) thread start
th  1: sigprocmask(block)
th  2: sub  (child ) thread start
th  2: sigprocmask(block)
th  4: sub  (parent) thread start
th  4: sigprocmask(block)
th  3: sub  (child ) thread start
th  3: sigprocmask(block)
th  3: loop start
th  0: loop start
th  2: loop start
th  1: loop start
th  4: loop start
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)

良い感じです。また結果1（親スレッドがsigprocmask()）と異なり、大量にシグナルを送りつけてもabortしないのも良いです。

$ g++ -Wall -g -O2 -DUSE_SIGPROCMASK_ALL -DID_MAINTHREAD=1 signal_thread.cpp && ./a.out
Use sigprocmask
th  0: sub  (child ) thread start
th  0: sigprocmask(block)
th  1: main (child ) thread start
th  1: sigprocmask(block)
th  2: sub  (child ) thread start
th  2: sigprocmask(block)
th  4: sub  (parent) thread start
th  4: sigprocmask(block)
th  3: sub  (child ) thread start
th  3: sigprocmask(block)
th  3: loop start
th  0: loop start
th  2: loop start
th  1: loop start
th  4: loop start
(...略...)
th  2: sigwait failed (Interrupted system call)
th  0: sigwait failed (Interrupted system call)
th  0: got SIGUSR1
th  1: got SIGUSR1
th  2: got SIGUSR1
th  2: got SIGUSR1
th  1: sigwait failed (Interrupted system call)
th  0: got SIGUSR1
th  4: sigwait failed (Interrupted system call)
th  3: sigwait failed (Interrupted system call)
th  2: sigwait failed (Interrupted system call)
th  1: got SIGUSR1

（別ターミナルから）
$ while :; do kill -USR1 123450; if [ $? -ne 0 ]; then break; fi; done

良さそうですね。

結果4 - 全スレッドがpthread_sigmask()

正しい方法（全スレッドがpthread_sigmask()）はどんな動きでしょうか？結果だけ先に書いてしまうと、全スレッドがsigprocmask()したときと同じ動きをするようです。

$ g++ -Wall -g -O2 -DUSE_PTHREADSIGMASK -DID_MAINTHREAD=1 signal_thread.cpp && ./a.out
Use pthread_sigmask
th  0: sub  (child ) thread start
th  0: pthread_sigmask(block)
th  1: main (child ) thread start
th  1: pthread_sigmask(block)
th  2: sub  (child ) thread start
th  2: pthread_sigmask(block)
th  4: sub  (parent) thread start
th  4: pthread_sigmask(block)
th  3: sub  (child ) thread start
th  3: pthread_sigmask(block)
th  3: loop start
th  2: loop start
th  0: loop start
th  1: loop start
th  4: loop start
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  4: got SIGUSR1
th  0: sigwait failed (Interrupted system call)

結果3（全員sigprocmask()）と同じ動きをしています。当然ながら、大量にシグナルを送りつけてもabortしません。

$ g++ -Wall -g -O2 -DUSE_PTHREADSIGMASK -DID_MAINTHREAD=1 signal_thread.cpp && ./a.out
Use pthread_sigmask
th  0: sub  (child ) thread start
th  0: pthread_sigmask(block)
th  1: main (child ) thread start
th  1: pthread_sigmask(block)
th  2: sub  (child ) thread start
th  2: pthread_sigmask(block)
th  4: sub  (parent) thread start
th  4: pthread_sigmask(block)
th  3: sub  (child ) thread start
th  3: pthread_sigmask(block)
th  3: loop start
th  2: loop start
th  0: loop start
th  1: loop start
th  4: loop start
(...略...)
th  2: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  1: sigwait failed (Interrupted system call)
th  4: sigwait failed (Interrupted system call)
th  0: got SIGUSR1
th  4: got SIGUSR1
th  0: got SIGUSR1
th  3: sigwait failed (Interrupted system call)
th  3: got SIGUSR1
th  2: sigwait failed (Interrupted system call)
th  2: got SIGUSR1
th  0: sigwait failed (Interrupted system call)
th  0: got SIGUSR1
th  1: sigwait failed (Interrupted system call)
th  3: sigwait failed (Interrupted system call)
th  3: got SIGUSR1
th  0: got SIGUSR1
th  4: sigwait failed (Interrupted system call)
th  2: sigwait failed (Interrupted system call)
th  1: sigwait failed (Interrupted system call)

（別ターミナルから）
$ while :; do kill -USR1 123450; if [ $? -ne 0 ]; then break; fi; done

4つの結果から推測するにpthread_sigmask()とsigprocmask()は同じシステムコールを使っているかもしれません。libcのソースコードを見ればわかるはずなので、また今度に見ようと思います。

ソースコード

こちらからどうぞ。

•  ソースコード

フォントがおかしいので直した

目次: 自宅サーバー

このブログ、フォント設定が2つほどおかしかったので直しました。今まで見づらくてすみません。

1つ目は一部の環境（Linux向けChromeなど）からこのサイトを見るとサンセリフ体（ゴシック体）ではなくセリフ体（明朝体）で表示される現象を直しました。セリフ体になってしまう現象は以前から認識していて不思議だな？とは思ったものの、原因が良くわからず放置していました。

Developer toolsでCSSを確認していたら、font-family: sans-serif, serifと指定していた箇所がありました。原因も何も、自分で指定してただけだったのか……。こんな単純なことに10年以上気づいていなかった。

2つ目はmonospace系の文字が表示されるpreタグなどの文字が小さかったのを直しました。今までfont-size: smallerにしていたんですが、monospaceは元々少し小さいサイズで表示されるブラウザが多くて、めちゃくちゃ字が小さくなっていました。

しかもこちらの現象は認識していませんでした。自分のFirefox環境はmonospaceのフォントサイズを少し大き目に指定している＆そのことを忘れており、デフォルト設定のブラウザで見ると字が小さすぎることに気付いてなかったです。すまねぇ。

glibcのsigprocmask()とpthread_sigmask()の実装

目次: C言語とlibc

以前、シグナルマスク（sigprocmaskのマニュアル）の「規定されていない」使い方をするとどうなるか？を見ました。前回までに確認したことは、5つのマルチスレッド（親スレッド＋4つの子スレッド）で全員でsigwait()するのは共通で、誰がsigprocmask()を呼ぶか？を変えながら、下記4パターンを試しました。

• 最初のスレッドがsigprocmask()
• 最初のスレッド「以外」の1スレッドがsigprocmask()
• 全スレッドがsigprocmask()
• 全スレッドがpthread_sigmask()

結果は1と2はabortし、4は「正しい方法」なので正しく動くとして、なぜか3も正しく動いていました。予想としてはsigprocmask()とpthread_sigmask()は実装が似ていて偶然こうなるのでしょう。

やっと本題

今回はGNU libc（glibc-2.41）のソースコードを確認して予想の答え合わせをします。繰り返しますが、マルチスレッドでsigprocmask()を呼ぶのは未定義動作なので3番の方法が正しく動く保証はないし、将来実装が変わって動かなくなる可能性があります。

まずpthread_sigmask()のコードを見ます。pthreadの制御に使うシグナルのマスクを消して、rt_sigprocmaskシステムコールを呼ぶだけです。

// glibc/nptl/pthread_sigmask.c

int
__pthread_sigmask (int how, const sigset_t *newmask, sigset_t *oldmask)
{
  sigset_t local_newmask;

  /* The only thing we have to make sure here is that SIGCANCEL and
     SIGSETXID is not blocked.  */
  if (newmask != NULL
      && (__glibc_unlikely (__sigismember (newmask, SIGCANCEL))
         || __glibc_unlikely (__sigismember (newmask, SIGSETXID))))
    {
      local_newmask = *newmask;
      clear_internal_signals (&local_newmask);
      newmask = &local_newmask;
    }

  /* We know that realtime signals are available if NPTL is used.  */
  int result = INTERNAL_SYSCALL_CALL (rt_sigprocmask, how, newmask,
				      oldmask, __NSIG_BYTES);

  return (INTERNAL_SYSCALL_ERROR_P (result)
	  ? INTERNAL_SYSCALL_ERRNO (result)
	  : 0);
}
libc_hidden_def (__pthread_sigmask)

versioned_symbol (libc, __pthread_sigmask, pthread_sigmask, GLIBC_2_32);

次にsigprocmask()のコードを見ます。見ての通りpthread_sigmask()を呼び出しているだけです。

// glibc/sysdeps/unix/sysv/linux/sigprocmask.c

/* Get and/or change the set of blocked signals.  */
int
__sigprocmask (int how, const sigset_t *set, sigset_t *oset)
{
  int result = __pthread_sigmask (how, set, oset);
  if (result == 0)
    return 0;
  __set_errno (result);
  return -1;
}
libc_hidden_def (__sigprocmask)
weak_alias (__sigprocmask, sigprocmask)

似ているどころか完全に一致していました。道理で同じ動作になるわけですね。

デバッグ用のlibcを使って実行する方法（スタティックリンク編）

目次: C言語とlibc

Cライブラリのデバッグをしたいときはあまりないと思いますが、Cライブラリにデバッグ情報やprintを追加して実行する方法を紹介します。今回使用するのはDebian Testingが採用しているglibc-2.40です。

バージョンはよほど古いバージョンでなければ動くと思いますが、最初はシステムにインストールされているバージョンと同じにしたほうがトラブルが少ないと思います。システムにインストールされているCライブラリの確認方法はディストリビューションによって違いますが、DebianやUbuntuならば下記のように確認できます。

$ dpkg -l libc6:amd64

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name            Version      Architecture Description
+++-===============-============-============-=================================
ii  libc6:amd64    2.40-7       amd64        GNU C Library: Shared libraries

バージョンは2.40でした。次にglibc-2.40のソースコードをもってきてビルドします。ソースコードは~/work/の下にあるとします。

$ git clone git://sourceware.org/git/glibc.git
$ cd glibc
$ git checkout glibc-2.40

$ mkdir build
$ cd build
$ ../configure --disable-sanity-checks --enable-debug
$ make -j16

実行したときに自分でビルドしたライブラリかどうか簡単にわかるようにpthread_sigmask()にprintf()を追加してからビルドします。

$ git diff

diff --git a/nptl/pthread_sigmask.c b/nptl/pthread_sigmask.c
index a39f3ca335..4c725592b6 100644
--- a/nptl/pthread_sigmask.c
+++ b/nptl/pthread_sigmask.c
@@ -19,12 +19,14 @@
 #include <pthreadP.h>
 #include <sysdep.h>
 #include <shlib-compat.h>
+#include <stdio.h>

 int
 __pthread_sigmask (int how, const sigset_t *newmask, sigset_t *oldmask)
 {
   sigset_t local_newmask;

+  printf("hoge\n");
   /* The only thing we have to make sure here is that SIGCANCEL and
      SIGSETXID is not blocked.  */
   if (newmask != NULL

ビルドしたglibcとテストプログラムをスタティックリンクします。-Lオプションには先程glibcをビルドしたディレクトリを指定し、-Dオプションには先程改変したpthread_sigmask()を呼ぶためのコンパイルスイッチを指定します。テストプログラムは以前紹介したものです（2025年5月12日の日記参照）。

$ g++ -g -O2 -Wall -static -L ~/work/glibc/build -DUSE_PTHREADSIGMASK 20250512_signal_thread.cpp

実行すると追加したhogeが出力されるはずです。

$ ./a.out

Use pthread_sigmask
th  0: sub  (child ) thread start
th  0: pthread_sigmask(block)
hoge
th  1: sub  (child ) thread start
th  1: pthread_sigmask(block)
hoge
th  2: sub  (child ) thread start
th  2: pthread_sigmask(block)
hoge
th  4: main (parent) thread start
th  4: pthread_sigmask(block)
th  3: sub  (child ) thread start
th  3: pthread_sigmask(block)
hoge
hoge
th  4: loop start
th  1: loop start
th  3: loop start
th  2: loop start
th  0: loop start

最後にデバッグしてソースコードが表示されるか試しましょう。

$ gdb a.out

(gdb) b pthread_sigmask
(gdb) run

Thread 2 "a.out" hit Breakpoint 1, __pthread_sigmask (how=0,
    newmask=0x7ffff7ff7120, oldmask=0x7ffff7ff71a0) at pthread_sigmask.c:29
29        printf("hoge\n");

(gdb) bt
#0  __pthread_sigmask (how=0, newmask=0x7ffff7ff7120, oldmask=0x7ffff7ff71a0)
    at pthread_sigmask.c:29
#1  0x0000000000401c43 in thread_main (arg=0x7fffffffc900)
    at signal_thread.cpp:81
#2  0x00000000004109cf in start_thread (arg=<optimized out>)
    at pthread_create.c:447
#3  0x0000000000422968 in __clone3 ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

ソースコードが表示されること、先程追加したprintf()が見えることも確認できました。良さそうです。

デバッグ用のlibcを使って実行する方法（ダイナミックリンク編）

目次: C言語とlibc

Cライブラリのデバッグをしたいときはあまりないと思いますが、Cライブラリにデバッグ情報やprintを追加して実行する方法を紹介します。今回使用するのはDebian Testingが採用しているglibc-2.40です。

システムにインストールされているバージョンと同じにしないと動作しないと思います。システムにインストールされているCライブラリの確認方法、ビルド方法は前回の日記（2025年5月22日の日記参照）と同様です。ソースコードは~/work/の下にあるとします。

Cライブラリをビルドしたら、テストプログラムをビルドします。スタティックリンクのときとは異なり-Lオプションは指定しません。ビルドは通常と一緒で、実行時にライブラリを差し替えるからです。-Dオプションには先程改変したpthread_sigmask()を呼ぶためのコンパイルスイッチを指定します。

$ gcc -g -O2 -Wall -DUSE_PTHREADSIGMASK test.c

実行すると追加したhogeが出力されるはずです。

$ LD_PRELOAD=~/work/glibc/__build/libc.so ./a.out

Use pthread_sigmask
th  0: sub  (child ) thread start
th  0: pthread_sigmask(block)
th  1: sub  (child ) thread start
th  1: pthread_sigmask(block)
hoge
th  2: sub  (child ) thread start
th  2: pthread_sigmask(block)
hoge
hoge
th  3: sub  (child ) thread start
th  3: pthread_sigmask(block)
th  4: main (parent) thread start
th  4: pthread_sigmask(block)
hoge
hoge
th  3: loop start
th  4: loop start
th  2: loop start
th  0: loop start
th  1: loop start

デバッグしてみましょう。

$ gdb ./a.out

(gdb) set env LD_PRELOAD ~/work/glibc/__build/libc.so
(gdb) b pthread_sigmask
(gdb) run

Thread 2 "a.out" hit Breakpoint 2, __GI___pthread_sigmask (how=0,
    newmask=0x7ffff7dd2da0, oldmask=0x7ffff7dd2e20) at pthread_sigmask.c:29
29        printf("hoge\n");

(gdb) bt
#0  __GI___pthread_sigmask (how=0, newmask=0x7ffff7dd2da0,
    oldmask=0x7ffff7dd2e20) at pthread_sigmask.c:29
#1  0x00005555555555e3 in thread_main (arg=0x7fffffffc880)
    at signal_thread.cpp:81
#2  0x00007ffff7e63332 in start_thread (arg=<optimized out>)
    at pthread_create.c:447
#3  0x00007ffff7edede8 in __GI___clone3 ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78

環境変数を設定して実行すると、ソースコードが表示されること、先程追加したprintf()が見えることも確認できました。ダイナミックリンクもうまくいっていそうです。

メガネが壊れた

金曜日、メガネの鼻当てが曲がってんなー？と思って、元の位置に戻そうと指で押したらパキっと音がして折れました。なにーー！？メガネの固定が甘くなって激しい動き、例えば走ったり階段の上り下りをすると、メガネが上下に揺れて視界がグワングワンします、目が回ります……。

メガネの鼻当てが折れた

直近で一番困ったのは、明日のシューティング大会JTSA Unlimitedです。サブのメガネもないし、メガネ外したら的が見えないですから、壊れたメガネのまま参加するしかありません。不幸中の幸いか、JTSA Unlimitedはアクションなし＝その場から動かないで撃つタイプなのでメガネが揺れてどうこうなることはありません。

今日のシューティング練習会で試した限りでも、視界に大きな影響はなかったですし壊れたメガネで参加してきます。

JTSA Unlimited大会参加2025

目次: 射的

JTSA Unlimitedの大会に参加しました。

「木」ステージが大失敗、「水」もダメダメで、高速ステージの「土」もいまいち振るわず、結果は75.69秒（前回は76.75秒）でした（総合82位/113人、LM 12位/21人）。70秒台前半くらいを出したかったけど無念ですね。

JTSA Unlimited練習会＋大会の記録

練習会の記録を見ると自己ベストは65.81秒ですが、その後はほとんど60秒台が出ないところをみると、75〜70秒くらいが実力と思われます。最近はあまり上達している感じがしません。そろそろ週1練習の限界かもしれませんが、今後もゆるゆると続けていきます。

メガネ注文

Newメガネを注文しました。今までどんなメガネかけてたっけ？と気になったので日記から掘り起こしてみました。古いものはいつ買ったのかすら怪しく、詳細も書き残していませんでした。メガネに関心がないことが良くわかりますね……。

• 2004年3月 オクターボ004（筑波、パリミキ）
• 2005年7月 999.9（北海道？詳細不明）
• 2008年12月 AMIPARIS TR-323（西武で買った、東京メガネ？）
• 2020年11月 増永眼鏡 GMS-831（品川、OPTIQUE PARIS MIKI）
• 2025年5月 増永眼鏡 GREENWICH（品川、OPTIQUE PARIS MIKI）

フォーナインズ（999.9）の前にもメガネは持っていたのですが、記録がなくて何もわかりません。パリミキに行って購入記録を聞いてみたら上記のような感じでした。20年前でも残ってるんですね。