昔の最近の出来事(2025.08)

2025/08/31

AM中に起床。

掃除したり洗濯したり。

先日の関数truncl() ですが、これってマルチスレッドの時はどうなってるんだ？と思ったりも。というのは、(1)それまでのFPUの制御レジスタの値を一旦保存しておいて、(2)丸めの設定をtruncl()用に変更した後、 (3)実際に丸め処理を行って、(4)終わったら保存していた丸めの設定を元に戻す、というような事をやっているようです。ただこれ、例えば丸めの設定を変更した後に実際の丸め処理を行う前にスレッドが切り替わったとして、その後またスレッドに実行権が戻って来た時に丸めの設定が他のスレッドで変えられていないという保証ってされてるの？と思ったりも。一連の操作がアトミックに行われる保証があるなら問題無いかも知れませんが、関数truncl()ってスレッドセーフなのかしら？が先日のコードだけ見てもよくわかりません。
いや、スレッドが切り替わるときにレジスタを全て保存してれば大丈夫か。だた、saved_cw や tmp_cw がスレッドローカルストレージには見えないので、最適化によりメモリに置くことは無くレジスタに保持しているという保証が必要では？とは思ったりも。

先日よりgdb上で動かしているEmacsですが、その後も何度かハング状態になり、その度にメインスレッドがサスペンド状態だったのですが、Resumeすれば回復するという感じになりました。でも gdbのプロンプトに戻ってくる訳では無いので状態を見ることができません。 gdb上で動かすか否かで挙動が大分違うのでどうにも困った感じです。何かしら動いてはいるので、CPUをバク食いしているスレッドにアタッチできれば良さそうにも思うのですが、どうやればよいのか分かりません🥺。

VirtualBoxのFedoraのソフトウェアアップデートしたらEmacs30.2が来てました。結構タイムラグがあるなぁとは思ったりも。

2025/08/30

AM中に起床。

全然関係ない流れで「【100年以上未解決】小学生でもわかる・昆虫が海にいない理由【科学・ざっくり解説】」という動画を知りました。内容はアカデミックなのに表現が独特で難しさが和らいでいるように感じました。全部は見れていませんが他の動画も面白かったです。

プロセス起動時に生成される謎のスレッド。 D言語で以下のようなほぼ無限ループのコードを実行した状態を Process Explorer で観察してみました。

import std.stdio;
import std.string;

void main()
{
  for( long i=0 ; i<0x10000000000; i++){
    if( i%1000000000==0 ){
      writeln("Hello D world.",i);
    }
  }
  return;
}

起動して直ぐは、謎のスレッドが3つほど立ち上がっているのですが、30秒ほどするとメインスレッド以外のスレッドは終了するようです。

プロセス起動直後のスレッド一覧

→30秒後→

また、謎のスレッドが無くなる前に意図的にスレッドをkillしてみた(スレッドを選んでkillボタンで殺せる)のですが、メインスレッドがどうにかなる事は無く動き続けるようです。ハングの要因にこの謎のスレッドが関係しているのではないか？と思っていた訳ですが、そもそもメインスレッドには何も影響は無く、ほっとけば勝手に終了してしまうスレッドという事から、 Cygwin管理下のスレッド群の何かがどうにかなっててEmacsがハング状態に陥っているのかなぁ？と思い直したりも。

なんとなく「これか？」と思う所があったりも。 Emacsがハング状態に陥っているところで、残っているスレッドを見てみたところ、「Cycles Delta」というパラメータがやたら大きくなっているスレッドがありました。これってCPUをバク食いしているスレッドで、これがハングの原因じゃね？と思った次第。二つのEmacsで再現したので両方で見てみたところ、どちらも同じ感じになっているようでした。CPUをバグ食いしているスレッドのスタックを表示したのが以下。

Emacsハング時にCPUをバク食いしているスレッドのスタック

見える範囲では、cygwin1.dll内の truncl って関数の中で何かが起こっているのかな？と思ったりも。関数truncl 自体はいくつかの箇所で定義されているようですが、Cygwin本体のは winsup/cygwin/math/truncl.c の奴かな？と思って調べてみたり。 git log上は 2016年3月18日にファイルが追加されて、2016年7月18日に更新された以降は特に手が加えられてはいないようです。ファイル自体は大きくはなくて、全部表示しても以下のような感じみたいです。

$ cat winsup/cygwin/math/truncl.c
/**
 * This file has no copyright assigned and is placed in the Public Domain.
 * This file is part of the mingw-w64 runtime package.
 * No warranty is given; refer to the file DISCLAIMER.PD within this package.
 */
#include <fenv.h>
#include <math.h>

/* Mask and shift amount for rounding bits on x86/x86_64. */
#define FE_CW_ROUND_MASK        (0x0c00)
#define FE_CW_ROUND_SHIFT       (10)

long double
truncl (long double _x)
{
#if defined(_ARM_) || defined(__arm__)
  return trunc(_x);
#else
  long double retval = 0.0L;
  unsigned short saved_cw;
  unsigned short tmp_cw;
  __asm__ __volatile__ ("fnstcw %0;" : "=m" (saved_cw)); /* save FPU control word */
  tmp_cw = (saved_cw & ~FE_CW_ROUND_MASK)
           | (FE_TOWARDZERO << FE_CW_ROUND_SHIFT);
  __asm__ __volatile__ ("fldcw %0;" : : "m" (tmp_cw));
  __asm__ __volatile__ ("frndint;" : "=t" (retval)  : "0" (_x)); /* round towards zero */
  __asm__ __volatile__ ("fldcw %0;" : : "m" (saved_cw) ); /* restore saved control word */
  return retval;
#endif /* defined(_ARM_) || defined(__arm__) */
}

x86の場合はインラインアセンブラで書かれている模様。そもそも、trunclは浮動小数点数値を絶対値に最も近い整数値に切り捨て方向に丸めるという関数のようなのですが、そういう関数でハング状態に陥るか？？？？🤔 とは思ったりも。

ソースコードを眺めてみても、関数sigfilset()から関数secure_getenv()に辿り着けそうに無いし、関数secure_getenv()から関数truncl()にも辿り着けそうにありません。このスタック表示は正しいのだろうか？🤔

gdb上で関数trunclにブレークポイントを張った状態でEmacsを動かしてハングが再現したのですが、 trunclで止まっている訳ではなさそう(gdbプロンプトに落ちてこない)であれぇ？な感じに。ただ、何故かメインスレッドがサスペンドした状態になっていて、Process Explorer で Resume が可能だったので Resumeしてみると再び動き始めました。むむ、何かgdbではキャッチしていないシグナルを受けて止まっているという状況なのか？？？🤔 そんな事できるんだっけ？

2025/08/29

テレワーク。早めに終了。

Emacsのハング再現。「Process Explorer」を使ってスレッドの観察をしてみているのですが、イマイチ振る舞いがよくわからず。プロセス起動時に生成されるスレッドを見ていると何故か無くなる場合があるようで、それでも動いているので「どういう事？🤔」ってなってます。 gdb上で動かす場合とそうでない場合で振る舞いが異なるようにも見えている気も。うーむ？

2025/08/28

テレワーク。早めに終了。

タイピングplus。バグってたのは直った模様。

調べごとをして終了。

2025/08/27

テレワーク。早めに終了。

タイピングplus、なんか激しくバグってないか？

Emacsのハング再現。なにやら緩めの負荷でやっているせいか再現しないなぁ？🤔

2025/08/26

テレワーク。早めに終了。

Windowsプロセスのスレッド。そういや「Process Explorer」があったのを思い出したり。スレッドも表示ができるようなので、ハングした時の様子を観察するのに使えないか？という事で試してみることに。見ている時間でハング再現せず😓。因みに、Process Explorerで見ても、プロセス起動時に生成される名無しのスレッドがどれなのか？は分からないので、

gdb上で Emacsを実行。
Ctrl-Zなどで適当にSIGSTOPで「info threads」でスレッドの一覧を表示。
Process Explorerで対象となるEmacsのプロセスを探して、右クリック→Propertiesの Threadsタブを開く。
2.のgdbでの ThreadId xxxx.0x???? の 0x????を 10進数にしたものが、3.のProcess ExplorerでのThreadsタブの TIDに対応する。

で対応付けを確認する必要があるみたい。

とか調べているとハングが再現したり。スレッドのスタックが表示できるようなので、名無しのスレッドの一つを見てみると、

0x0000000000000000
ntdll.dll!ZwWaitForAlertByThreadId+0x14
ntdll.dll!RtlInitializeResource+0x9bf
ntdll.dll!RtlRaiseStatus+0x48f
ntdll.dll!RtlEnterCriticalSection+0xf2
ntdll.dll!RtlSizeHeap+0x109a
ntdll.dll!RtlAllocateHeap+0x753c
ntdll.dll!RtlFreeHeap+0x620
ntdll.dll!LdrLockLoaderLock+0x6ae
ntdll.dll!RtlAcquireSRWLockExclusive+0x150a
KERNEL32.DLL!BaseThreadInitThunk+0x17
ntdll.dll!RtlUserThreadStart+0x2c

という感じになっていて、WaitForAlertByThreadId なる所で何かを待っているっぽいようです。スレッドのステートは「Wait:WrAlertByThread」なるものになっているようです。うーむ、分からん🥺。

2025/08/25

テレワーク。早めに終了。

Windowsプロセスのスレッド。D言語で書いてdmdやldc2でコンパイルした HelloWorld的なコマンドラインのプログラムでも、スレッドが生成されているようなのでこういうものなのか？と思ったりも。 Webで検索すると、必ず1つプライマリスレッドが生成されるらしいというのは分かったのですが、複数のスレッドの場合があるのかはよくわかりませんでした。また、dmdだとスレッドが3つだけど ldc2ではスレッドが2つ生成される感じになっていて、どういう事？かがよく解らなかったり。だた、dmdやldc2でコンパイルした実行ファイルは objdumpで逆アセンブルしてもシンボルが無くて何やっているのかが分かりません。 .textセクションの先頭アドレスでブレークポイントを置いても、そのブレークポイントに達する前にスレッドが生成されているようです。Cygwinでコンパイルした emacsバイナリでも、先頭アドレス(シンボル的にはWinMainCRTStartup)で止まる前にスレッドが生成されているという感じのようです。

(gdb) b WinMainCRTStartup
Breakpoint 1 at 0x100401004: file /usr/src/debug/cygwin-3.6.2-1/winsup/cygwin/crt0.c, line 17.
(gdb) run
Starting program: /cygdrive/d/cygwin/home/TANE-HP/develop/work/emacs-30.2/emacs-30.2-ime/emacs-30.2/src/emacs.exe
[New Thread 9556.0x9fdc]
[New Thread 9556.0x68fc]
[New Thread 9556.0x4db8]
[New Thread 9556.0x4cb0]

Thread 1 hit Breakpoint 1, mainCRTStartup () at /usr/src/debug/cygwin-3.6.2-1/winsup/cygwin/crt0.c:17
warning: 17     /usr/src/debug/cygwin-3.6.2-1/winsup/cygwin/crt0.c: No such file or directory
(gdb) info threads
  Id   Target Id          Frame
* 1    Thread 9556.0x6404 mainCRTStartup () at /usr/src/debug/cygwin-3.6.2-1/winsup/cygwin/crt0.c:17
  2    Thread 9556.0x9fdc 0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  3    Thread 9556.0x68fc 0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  4    Thread 9556.0x4db8 0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  5    Thread 9556.0x4cb0 0x00007ffb9225c320 in ntdll!RtlUserThreadStart () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
(gdb) thread apply all bt

Thread 5 (Thread 9556.0x4cb0):
#0  0x00007ffb9225c320 in ntdll!RtlUserThreadStart () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#1  0x0000000000000000 in ?? ()

Thread 4 (Thread 9556.0x4db8):
#0  0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#1  0x00007ffb922b259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#2  0x00007ffb90b9e8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/windows/System32/KERNEL32.DLL
#3  0x00007ffb9225c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 3 (Thread 9556.0x68fc):
#0  0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#1  0x00007ffb922b259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#2  0x00007ffb90b9e8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/windows/System32/KERNEL32.DLL
#3  0x00007ffb9225c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 9556.0x9fdc):
#0  0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#1  0x00007ffb922b259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#2  0x00007ffb90b9e8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/windows/System32/KERNEL32.DLL
#3  0x00007ffb9225c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 9556.0x6404):
#0  mainCRTStartup () at /usr/src/debug/cygwin-3.6.2-1/winsup/cygwin/crt0.c:17
(gdb)

プログラムの先頭で既に複数のスレッドが存在している状況に見えるので、もう調べようがありません🥺。

2025/08/24

AM中に起床。

掃除したり洗濯したり。

そういえばと思い今更ですが検索した「REALFORCE TYPING CHAMPIONSHIP 2025」。おかしな速度(褒め)なのは以前にも思った事ですが、史上最年少って小学生らしい。すげぇ....。で、最近は上位ランカーが多くて全然見ていなかったのですが、「タイピングplus」のランキング上位に大会に出場していた選手と思われる人たちが居るなぁと思ったり。 TANE自身は一応毎日1回以上は練習しているものの、サービス全体平均スコアくらいを維持するので精一杯です😅。ところで、8月21日くらいから練習記録の練習時間が妙な時間を表示するようになってますがバグか？

Emacsハングの件。結局程度の差はあるけど、どのようなビルドでもハングはするという感じに見えます。そこでスレッドのバックトレースを取れるのを知ったので、それで何か分からないかと少し調べてみました。何度か再現させて観察してみたところ、ハングが再現した後にいくつかのスレッドが終了しているように思いました。

  Id   Target Id                             Frame
* 1    Thread 27424.0x369c "emacs-30.2.1"    0x00007fff14b12352 in _cygtls::lock (this=<optimized out>) at /home/TANE-HP/develop/work/cygwin/newlib-cygwin/winsup/cygwin/local_includes/cygtls.h:245
  2    Thread 27424.0x5514                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 27424.0x2c14                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 27424.0x2ce4                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 27424.0x2fa8 "sig"             0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  6    Thread 27424.0x2b2c                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 27424.0x6350                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 27424.0x4b20 "timerfd"         0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  9    Thread 27424.0x4dec "gmain"           0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 27424.0x6698 "pipesel"         0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 27424.0x315c "itimer"          0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  12   Thread 27424.0x5178                   0x00007fffc52d1324 in win32u!NtUserGetMessage () from /cygdrive/c/WINDOWS/System32/win32u.dll
  13   Thread 27424.0x4dd4                   0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  16   Thread 27424.0x672c                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  17   Thread 27424.0x2b54                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  18   Thread 27424.0x3594 "waitproc"        0x00007fffc7da2974 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  19   Thread 27424.0x173c                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  20   Thread 27424.0x2350 "pipesel"         0x00007fffc7da2934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  21   Thread 27424.0x39c4 "[pango] fontcon" 0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  22   Thread 27424.0x2f8c "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  23   Thread 27424.0x1e1c "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  24   Thread 27424.0x4124                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
[Thread 27424.0x2c14 exited with code 0]
[Thread 27424.0x5514 exited with code 0]
[Thread 27424.0x2ce4 exited with code 0]
[New Thread 27424.0x634c]

一覧の番号で言うと Id=2,3,4 のスレッドが code 0 で終了しているようです。で、この Id=2,3,4 って何？というのをスタックダンプで見たのが以下。

  :
Thread 4 (Thread 27424.0x2ce4):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 3 (Thread 27424.0x2c14):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 27424.0x5514):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()
  :

これらのスレッド以外のスレッドは何かしらCygwinを経由しているようなトレースが取れていますが、これらはCygwinとは無関係な何かに見えます。ここからは想像ですが、何かしらの理由で Id=2,3,4 のスレッドが終了してしまうけど、それが検知されずハング状態に陥ってしまうという事か？因みに、今回の出所不明のスレッドについては、 Idは違いますがこちらのML記事と同じように存在しているものと思われます。ただ、何者なのかは分からないみたい。スレッド生成のAPIにブレークポイントを仕掛けて誰がスレッドを作っているかを調べるしか無いのか？

とりあえずWin32APIの CreateThread() にブレークポイントを設定してみたのですが、以下のような感じになりました。

(gdb) b CreateThread
Breakpoint 1 at 0x1007173f0
(gdb) run
Starting program: /home/TANE-HP/develop/work/emacs-30.2/emacs-30.2-ime/hangtest-emacs-30.2/src/emacs-30.2.1.exe
[New Thread 19000.0x43c4]
[New Thread 19000.0x5490]
[New Thread 19000.0x5a4c]

Thread 1 hit Breakpoint 1.2, 0x00007fffc68b3107 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
(gdb) info threads
  Id   Target Id           Frame
* 1    Thread 19000.0x27e8 0x00007fffc68b3107 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
  2    Thread 19000.0x43c4 0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 19000.0x5490 0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 19000.0x5a4c 0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) thread apply all bt

Thread 4 (Thread 19000.0x5a4c):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 3 (Thread 19000.0x5490):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 2 (Thread 19000.0x43c4):
#0  0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#1  0x00007fffc7cd259e in ntdll!RtlAcquireSRWLockExclusive () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#2  0x00007fffc68ae8d7 in KERNEL32!BaseThreadInitThunk () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#3  0x00007fffc7c7c34c in ntdll!RtlUserThreadStart () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x0000000000000000 in ?? ()

Thread 1 (Thread 19000.0x27e8):
#0  0x00007fffc68b3107 in KERNEL32!CreateThread () from /cygdrive/c/WINDOWS/System32/KERNEL32.DLL
#1  0x00007fff14af50e3 in cygthread::create (this=this@entry=0x7fff14cf54e0 <threads>) at ../../../../newlib-cygwin/winsup/cygwin/cygthread.cc:299
#2  0x00007fff14af515d in cygthread::async_create (arg=140733542520032) at ../../../../newlib-cygwin/winsup/cygwin/cygthread.cc:273
#3  0x00007fffc7cb1b93 in ntdll!RtlDeleteElementGenericTableAvlEx () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#4  0x00007fffc7da67be in ntdll!KiUserApcDispatcher () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x00007fffc7da6304 in ntdll!ZwTestAlert () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x00007fffc7ca37e6 in ntdll!EtwEventWriteNoRegistration () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x00007fffc7ca367e in ntdll!EtwEventWriteNoRegistration () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#8  0x00007fffc7c75fce in ntdll!LdrInitializeThunk () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#9  0x0000000000000000 in ?? ()
(gdb)

一応止まるのですが、止まった時点では既に Id=2,3,4 が生成されているように見えます。CreateThread()じゃない何かでスレッドが生成されているという事？🤔
gdbは「[New Thread 39784.0x5310]」のような感じで新しいスレッドが生成されたことを認識できているように思えるのですが、何かしらgdb側でスレッドが生成された時に止めるとか情報表示する方法は無いのかしら？🤔

2025/08/23

AM中に起床。

午前中に通院。

Emacsハングの件。

| imagemagick | native-image-api |  rsvg   | IMEpatch | ハング再現 |       その他       |
|-------------+------------------+---------+----------+------------+--------------------|
|   without   |     without      | without |   with   |    する    |     パッチ有り     |
|   without   |     without      | without | without  |    する    |     パッチ有り     |
|   without   |        -         |    -    |    -     |    する    |     パッチ無し     |
|      -      |        -         |    -    |    -     |    する    | オリジナルバイナリ |

※Cygwin 3.6.5相当(commit a5f96c196 (HEAD -> cygwin-3_6-branch, origin/cygwin-3_6-branch))にSIGTRAP回避パッチを当てたもの
※ベースのconfigureオプションは「--prefix=/usr --with-w32 --with-native-compilation=no」
※観察の為にgdb上で動かし SIGTRAPをトリガに info threads を表示する(参考)
※IMEpatchは src/config.h を手で変える方式
※「-」は選択不能でwithoutと同等

これまで大丈夫と思っていたオリジナルのemacs-w32バイナリでも、時間をかければハング再現してしまう感じになっています🥺。ただ、gdb上で動かしているとか、シグナルを送っているとか、普段使いでは行わない事をやっているので、加速する感じになっている気がしなくはありません。
必ず再現する手番(時間をかけるようなのではなくて再現する一意の操作手順)が見つかっていないのと、ハングしている状況では何も調べられないのとで、原因究明が困難になっています。

Web検索していると過去にCygwinのMLで「Threads」という投稿からの一連の流れがあった事を知ったり。現在もCygwinのEmacsパッケージをメンテナンスしている Ken Brown氏が Emacsを起動すると大量の threadが生成されるけど誰が生成しているんだ？的な話から、シグナルの話などなんか既視感のある話題だなぁ？と思ったりも。今から10年くらい前の話なので直接関係は無いと思いますが。全部読めてません(英語よく解らんもある😓)が、最終的に解決した話題のようなので当時は何が問題でどういう原因をどう直したかが読めると、今回の話のヒントが何かないかなぁ？と思ったりも。何も分からないかも知れませんが😓。

gdbコマンドの「info threads」でスレッドの一覧を表示できることを知ったのですが、「thread apply all bt」で全スレッドのスタックトレースを表示できることを知ったり。
こちらのML記事の中にスレッドの負荷テストのコードが記されているのですが、試しにコンパイル＆実行してみたところ謎の動きになったり。

$ cat signal-stress.c
#include <assert.h>
#include <sys/time.h>
#include <signal.h>
#include <stdio.h>

long SmartScheduleInterval = 1; /* ms */
long SmartScheduleTime = 0;

static void
SmartScheduleTimer(int sig)
{
    if (sig != 0)
       SmartScheduleTime += SmartScheduleInterval;
}

void
SmartScheduleStartTimer(void)
{
    struct itimerval timer;
    timer.it_interval.tv_sec = 0;
    timer.it_interval.tv_usec = SmartScheduleInterval * 1000;
    timer.it_value.tv_sec = 0;
    timer.it_value.tv_usec = SmartScheduleInterval * 1000;
    setitimer(ITIMER_REAL, &timer, 0);
}

int main()
{
    /* Set up the timer signal function */
    struct sigaction act;
    act.sa_handler = SmartScheduleTimer;
    sigemptyset(&act.sa_mask);
    sigaddset(&act.sa_mask, SIGALRM);
    if (sigaction(SIGALRM, &act, 0) < 0) {
        perror("sigaction failed");
        return -1;
    }

   /* start timer */
   SmartScheduleStartTimer();

   /* Loop forever, doing tests which should always succeed, with lots of signals */
   int x = 0;
   int i = 0;
   while (1) {
     x = i;
     int j = x;
     if (j != i)
       {
          printf("failed: %d isn't equal to %d, apparently\n", i, j);
          break;
       }
     i++;
  }
  return 0;
}

$ gcc signal-stress.c  -Wall -O0 -g

$ ./a
Alarm clock

$ ※エラーしないと終了しないプログラムなのに、コードに無い文字列を表示して終了してしまう。

なんで？🤔 gdbから実行すると期待通りに動いているようです。少なくとも「Alarm clock」なんて文字列が出力される理由が分からない。謎。
その後、一通りMLの記事を翻訳で読んでみたつもりですが、どこをどのように修正したかが分かりませんでした🥺。

2025/08/22

テレワーク。早めに終了。

Emacsハングの件。 Cygwinパッケージのオリジナルemacs-w32(組み込みImageMagick無し、組み込みRSVG描画無し) だと3.6.5相当の野良ビルドしたCygwinでもハングせず。 IME/他パッチをあてて、ImageMagick無し、組み込みRSVG無しにしてみたのですがハングします。むむ。--with-native-image-api を付けていたり IMEパッチも有効なので、もっとオリジナルの emacs-w32に寄せてみるとどうなるのだろう？と思って試してみる事に。

2025/08/21

テレワーク。早めに終了。

先日のEmacsで起動されるスレッドの観察。ハングは再現していたのですが何か掴む事はできず。ただ、killコマンドが「bash: kill: (1775) - Permission denied」てな感じでエラーしていて、何やらシグナルを送れない状況になっているのか？と思ったりも。正確に権限の問題なのか、理由はともかくシグナルを送れない状況を権限の問題と丸めてしまっているのかは判らず。

ハング前に表示されていた最後のスレッド一覧は以下のようになっていました。

Thread 1 "emacs-30.2.1" hit Catchpoint 1 (signal SIGSTOP), 0x00007fffbf618019 in WindowsCodecs!WICSetEncoderFormat_Proxy () from /cygdrive/c/WINDOWS/SYSTEM32/WindowsCodecs.dll
  Id   Target Id                            Frame
* 1    Thread 8512.0x10ac "emacs-30.2.1"    0x00007fffbf618019 in WindowsCodecs!WICSetEncoderFormat_Proxy () from /cygdrive/c/WINDOWS/SYSTEM32/WindowsCodecs.dll
  2    Thread 8512.0x6c64                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 8512.0x31a4                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 8512.0x3960                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 8512.0x6298 "sig"             0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  6    Thread 8512.0x56dc                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 8512.0x2a6c                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 8512.0x6f68 "timerfd"         0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  9    Thread 8512.0x1e08 "gmain"           0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 8512.0x6e54 "pipesel"         0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 8512.0x3284 "itimer"          0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 8512.0x651c                   0x00007fffc52d1324 in win32u!NtUserGetMessage () from /cygdrive/c/WINDOWS/System32/win32u.dll
  13   Thread 8512.0x26f8                   0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  16   Thread 8512.0x4130                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  17   Thread 8512.0x5cd8                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  18   Thread 8512.0x1c8 "waitproc"         0x00007fffc7da2974 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  19   Thread 8512.0x54e8                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  20   Thread 8512.0x3458 "pipesel"         0x00007fffc7da2934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  21   Thread 8512.0x62bc "[pango] fontcon" 0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  22   Thread 8512.0xe78 "emacs-30.2.1"     0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  23   Thread 8512.0x6f9c "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  30   Thread 8512.0x5258 "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  31   Thread 8512.0x6ed0 "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  32   Thread 8512.0x3308 "emacs-30.2.1"    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
[New Thread 8512.0x1da8]

スレッドIDが32に達しているなぁ？とは思ったりも。ただ、番号は抜けているので総数は24のようですが。 IDは再利用されていないのだろうか？🤔 IDが32に達したところで、新しくスレッドを作っているようですが、まさかオーバーフロー的に溢れてダメになっているとかじゃないよね？

今のところハングの再現しない Cygwin 3.6.2-1で、同じく Emacsを gdb上で動かして定期的にSIGSTOPを送ってスレッドを表示するとどうなるか？を試してみたところ、4時間ほどするとハングしてしまいました🥺。以下はハング直前の最後のスレッド表示です。ノートPCではなくデスクトップPCで試したのですが、何故かスレッドの数がちょっと多いです。

Thread 1 "emacs-30.2.1" hit Catchpoint 1 (signal SIGSTOP), 0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx ()
   from /cygdrive/c/windows/System32/win32u.dll
  Id   Target Id                             Frame
* 1    Thread 37036.0x622c "emacs-30.2.1"    0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/windows/System32/win32u.dll
  2    Thread 37036.0x4ad8                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  3    Thread 37036.0x2200                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  4    Thread 37036.0x8dbc                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  5    Thread 37036.0x8600 "sig"             0x00007ffb8faf7f7a in RaiseException () from /cygdrive/c/windows/System32/KERNELBASE.dll
  6    Thread 37036.0x73dc                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  7    Thread 37036.0xdd0                    0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  8    Thread 37036.0x1f80 "timerfd"         0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/windows/System32/win32u.dll
  9    Thread 37036.0x70ec "gmain"           0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  10   Thread 37036.0x6c68 "itimer"          0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  11   Thread 37036.0x15c8 "pipesel"         0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  12   Thread 37036.0x8ee4                   0x00007ffb8ff81324 in win32u!NtUserGetMessage () from /cygdrive/c/windows/System32/win32u.dll
  14   Thread 37036.0x9538 "waitproc"        0x00007ffb92382974 in ntdll!ZwReadFile () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  15   Thread 37036.0x7c50                   0x00007ffb8ff8acc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/windows/System32/win32u.dll
  16   Thread 37036.0x5d30 "pipesel"         0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  17   Thread 37036.0x85fc "[pango] fontcon" 0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  18   Thread 37036.0x5d0c "ptym"            0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  19   Thread 37036.0x782c "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  20   Thread 37036.0x6a00 "ptym"            0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  21   Thread 37036.0x5a14 "ptym"            0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  22   Thread 37036.0x4288 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  23   Thread 37036.0x89c4 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  24   Thread 37036.0x5a0c "itimer"          0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  25   Thread 37036.0x7388 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  26   Thread 37036.0x7b28 "pipesel"         0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  27   Thread 37036.0x7c18 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  28   Thread 37036.0x8a64 "ptymf"           0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  29   Thread 37036.0x904 "waitproc"         0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  30   Thread 37036.0x3b1c "itimer"          0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  31   Thread 37036.0x8634 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  32   Thread 37036.0x5b40 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  33   Thread 37036.0x95a8 "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  34   Thread 37036.0x7d9c "waitproc"        0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  35   Thread 37036.0x2288 "pipesel"         0x00007ffb92382934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  36   Thread 37036.0x5b30 "emacs-30.2.1"    0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  37   Thread 37036.0x8f20 "emacs-30.2.1"    0x00007ffb92383404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
  38   Thread 37036.0x6b58                   0x00007ffb92386564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/windows/SYSTEM32/ntdll.dll
[Thread 37036.0x2200 exited with code 0]
[Thread 37036.0x8dbc exited with code 0]
[Thread 37036.0x4ad8 exited with code 0]
[New Thread 37036.0x7cdc]

シグナルを送る為のkillコマンドも「bash: kill: (638) - Permission denied」てな感じになっていました。という訳で、Cygwin 3.6.2-1でもハングしない訳では無いという感じのようです。

それじゃぁと思い、Cygwinオリジナルの emacs-w32(組み込みImageMagick無し、組み込みRSVG描画無し) だとどうなんだ？と思ったり。ひとまず仕掛けてみたのですが、なんかスレッド数が半分しか無いぞ？もしかしてスレッド数とハングには因果関係がある？🤔

マクドナルドのハッピーセットで転売目的の大量購入や食品廃棄などの問題の話。え？マクドナルド側の方が何か言われるの？

2025/08/20

テレワーク。早めに終了。

先日、gdbで handleコマンドによりシグナル受信時の振る舞いを変えられるのを知りましたが、シグナルを受信した時に任意のgdbコマンドを実行できないのか？と思ったり。 Web検索で見つけられなかったので Copilotで聞いてみたら、catch signal と commands の組み合わせで実現できるという答えが返ってきました。

(gdb) catch signal SIGSTOP
Catchpoint 1 (signal SIGSTOP)
(gdb) commands 1
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>info threads
>continue
>end
(gdb) run

これで実行した状態で、プロセスに「kill -s SIGSTOP プロセスID」でシグナルを送ると、スレッドの情報を表示したのち continueで実行を継続する感じになるようです。なる。
なぜこのような事がしたかったかと言うと、C-zでちょこちょこ止めて「info threads」で見てみるとスレッドの数が増えているようだったので、増え続けたりするのだろうか？と思った次第。別bashから「while true; do kill -s SIGSTOP プロセスID; sleep 1; done」でシグナルを送り続けて Emacsハング再現した時の最後の瞬間が見られないだろうか？という訳で試してみたり。....直ぐには再現しないようなのでそのまま放置。

2025/08/19

テレワーク。気持ち早めに終了。

Cygwin 3.6.3-1以降で Emacsがハングする件。
如何せんハング状態に陥っていると、 strace -p でアタッチしてもそのまま何もできない状況になるし、 gdb -p でアタッチしても同様に C-z で SIGSTOPを送ることもできません。でも、なにやら大量にスレッドが生成されているようなので、どこで生成されているのだろうか？と思ったり。 src/systhread.c:sys_thread_create() が呼ばれているのだろうかと思い、ブレークポイントを設定しても止まる気配が無し。どこでスレッドが生成されているのかよくわからず🤔。
gdb上で動かして、適当なところで C-z で止めてから info threadコマンドを実行してみたところ、以下のようなスレッドが生成されているようでした。

(gdb) info threads
  Id   Target Id                             Frame
* 1    Thread 28184.0x5f0c "emacs"           0x00007fffc52d1344 in win32u!NtUserMessageCall () from /cygdrive/c/WINDOWS/System32/win32u.dll
  2    Thread 28184.0x4828                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  3    Thread 28184.0x69b0                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  4    Thread 28184.0x6390                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  5    Thread 28184.0x5fc0 "sig"             0x00007fffc5547f7a in RaiseException () from /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
  6    Thread 28184.0x3050                   0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  7    Thread 28184.0xf60                    0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  8    Thread 28184.0x6f38 "timerfd"         0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  9    Thread 28184.0x2184 "gmain"           0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  10   Thread 28184.0x2d68 "pipesel"         0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  11   Thread 28184.0x6b34 "itimer"          0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  12   Thread 28184.0x5684                   0x00007fffc52d1324 in win32u!NtUserGetMessage () from /cygdrive/c/WINDOWS/System32/win32u.dll
  13   Thread 28184.0xef8                    0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  16   Thread 28184.0x6db0                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  17   Thread 28184.0x704                    0x00007fffc7da6564 in ntdll!ZwWaitForWorkViaWorkerFactory () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  18   Thread 28184.0x4268 "waitproc"        0x00007fffc7da2974 in ntdll!ZwReadFile () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  19   Thread 28184.0x3450                   0x00007fffc52dacc4 in win32u!NtUserMsgWaitForMultipleObjectsEx () from /cygdrive/c/WINDOWS/System32/win32u.dll
  20   Thread 28184.0x5b1c "pipesel"         0x00007fffc7da2934 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
  21   Thread 28184.0x64c8 "[pango] fontcon" 0x00007fffc7da3404 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb)

「Id 1」は emacsのメインスレッドと思われますが、それ以外は何のスレッドなのかよくわかりません。ただ、「[pango] fontcon」は数日前に何かあるのか？と思った所でした。「sig」もスレッドのようなのですが、どちらも emacs本体のスレッドでは無いようにも思えたり。特に何かを得られた感じはせず🥺。

2025/08/18

テレワーク。早めに終了。

Cygwin 3.6.3-1以降で Emacsがハングする件。
先日の続きで謎のSIGTRAP対応をしたリリースされていない野良ビルド Cygwin 3.6.5相当でハング再現の様子見していたのですが、やっぱり3.6.3以前よりも再現性が高いです。あと、一度だけで契機は判りませんが「Fontconfig warning: using without calling FcInit()」というメッセージが起動したターミナルに表示された事がありました。少し前にpangoや fontconfigが何か関係している可能性を考えたのですが、何かあるのか？と思ったり。原因では無く影響を受けた結果かも知れないのでなんとも言えませんが....🤔

特に何も掴めず🥺。

2025/08/17

AM中に起床。

Cygwin 3.6.3-1以降で Emacsがハングする件。
昨日のCygwin 3.6.2-1に相当する野良ビルドしたcygwin1.dllでハング再現しない事を確認していたのですが、ハング再現してました🥺。むむ。ただし、2つのEmacsのうち一つだけハング再現で、もう一つは朝まで耐えていた感じではありますか。

ちょっと話は逸れて gdbで実行すると謎のSIGTRAPが発生する件。3.6.3-1では試していなかったというのに気づいたのでパッケージでCygwin 3.6.3-1を再インストールして確認。総合結果で言うと以下のような感じ。

  | Version   | 謎のSIGTRAP | 備考       | 備考(Emacsハング)            |
  |-----------+-------------+------------+------------------------------|
  | 3.6.1-1   | ？          | パッケージ | ハングしない                 |
  | 3.6.2-1   | 発生しない  | パッケージ | (パッケージ版は)ハングしない |
  | 3.6.3-1   | 発生しない  | パッケージ | ハングする                   |
  | 3.6.4-1   | 発生する    | パッケージ | ハングする                   |
  | 3.6.5相当 | 発生する    | 野良ビルド | ハングする                   |

3.6.4-1は、よりによってこのタイミングで感🥺。逆に謎のSIGTRAP と Emacsハングとの因果関係は無いかも。

話は Cygwin 3.6.3-1以降で Emacsがハングする件に戻る。
デッドロック的なものが発生しているとして、どうやって止めれば良いのだろう？🤔。
Cygwin 3.6.2-1相当でオプティマイズレベルを -O0にして野良ビルド。ハング再現待ち。

ハング再現待ちの間に掃除でもするかと思って掃除機の電源を入れたところ、モーターの回転が急に遅くなり部屋の照明が点滅したり。これはショートか？と思い即停止。なんてこった😭。午前中だったので即座にヨドバシヘ調達に。普段行かない家電フロアでいくつか試して、型落ちだけど持ち帰り可能なコードレスのスティックタイプに決定。約25000円でしたが全額ポイントで支払い。
因みに、壊れた掃除機は2001年1月に引っ越した時に買ったものだったので約24.5年使用したことになります。掃除機って壊れないのかと思っていたのですが突然壊れるのか....

掃除したり。説明書にはフル充電に4時間かかると書かれていたのですが小一時間ほどで充電完了。バッテリー保管時は満充電にしておけとも記されていたので、出荷時に充電されていたのかも。さておき、軽くて快適😄。そしてめっちゃ吸う😆。よき。

掃除機調達やら掃除の間、5時間ほどハング再現待ちはほったらかしにしていたのですが、この時間では再現せず。3.6.2は実はギリギリ大丈夫で、コンパイル条件とかによって再現性が変わるのか？🤔 いずれにしても、これまでたまたま大丈夫だっただけという疑惑も湧いてきた気がしたりも。困った。
その後もハング再現せずトータル7時間ほど耐えたので一旦別条件に。

Cygwin 3.6.3相当を野良ビルドしてみたり。ただし、オプティマイズレベルを -O0にしてみます。 Cygwin 3.6.3-1のパッケージからハングが再現するのですが、一旦オプティマイズレベルを下げるとどうなるか？を見てみる事に。ただ、3.6.2と 3.6.3は差分内容的にはほぼ変更無しにも見えるので (数日前のメモ)、オプティマイズレベルを下げると再現性に影響あるのかを見る感じで。 ....1.5時間くらいでハング再現。マジか🥺。ダメになったのは強制終了して、追加でEmacsを起動して様子見継続した感じ6時間は耐えられてそう。イケるときはイケるし、ダメなときはダメという感じだな......

gdb上でemacsを実行すると謎のSIGTRAPが発生する件。 git log を眺めていると、スレッドに関連する不具合に対処する為に、意図的にトラップを起こすような変更を加えているようでした。複数のコミットで色々な部分を直しているので全部を外す事は難しそうだったのですが、 x86の EFlagsレジスタのTF(トラップフラグ)を設定するようなコードがあり、これが何かしら悪さをするケースがあるのではないか？と推測してみたり。フラグの設定コードをコメントアウトして、リリースされていない Cygwin 3.6.5相当で野良ビルドしたところ、 gdb上で emacsを実行しても謎のSIGTRAP は発生しなくなりました。 Emacsは結構な数のスレッドが起動されるようなので、強めの負荷テストになっているのかも知れません。で、Emacsのハングに影響するのか？を見てみたところ早めにハング再現😓。という訳で、gdb実行での謎のSIGTRAP は別件確定という感じかも。

2025/08/16

AM中に起床。

直ぐには出ないだろうと思っていたら、Cygwinパッケージに emacs 30.2-1 がもう来ていたり。マジか😓。
ひとまず「Emacsの雑記」を Emacs-30.2ベースに更新してみました。御参考まで。まだ Cygwinのバージョンとの組み合わせでハングする件は解決できていないので、先日のワークアラウンド方法を但し書きとして記してます。

話は Cygwin 3.6.3-1以降で Emacsがハングする件に戻る🥺。
調査しているノートPCは Cygwin 3.6.3-1の一つ前が Cygwin 3.6.1-1だったのですが、3.6.1-1まで戻してもハングは再現しませんでした(なので「Emacsの雑記」には 3.6.1-1まで戻すのもワークアラウンドとしています)。で、3.6.1-1でも gdb上で実行すれば SIGTRAPは発生しません。3.6.3-1以降だと謎のSIGTRAPが発生するのとハングは関係があるのじゃないか？と思い始めたりも。
SIGTRAPを受け取ると一応 gdbの操作は可能でバックトレースも表示できるのですが、シグナルの発生源は判らんなぁ？と思ったりも。何かしらデバッガ上で発生源を調べられるかと思いきや方法が見当たらず。むぅ🤔

ハング調査のノートPCのEmacsを30.2-1にアップデートしてみたり。Cygwin本体のバージョンを上げたり下げたりしていると、関係無いパケージも更新するかしないかを指示しなくてはならないのが面倒臭いから。それだけ😓。でもやっぱりハングは再現します。やっぱり原因は Cygwin側にあると考えるのが打倒だろうか....

Cygwinを野良ビルドしてみる事に。ひとまず先日調べた cygwin-3_6-branch の HEAD(まだリリースされていない3.6.5に相当)で試してみたり。一度もCygwinをビルドしたことの無いノートPCだったので、ツールのインストールが足りなかったのを追加したり、以前ハマった「shilka」ってコマンドが無くてビルドに失敗するのを回避手順で対応したり。ひとまず new-cygwin1.dll のビルドは成功。 3.6.4-1と入れ替えて(rebaseは無し)様子を見てみることに。
gdbで実行すると謎のSIGTRAPが発生する件はビルドしたcygwin1.dllにしても再現するようです🤔。
Emacsを起動して様子見中に Cygwin の git logを眺めていたところ、何やらデッドロック案件が修正されているみたい。もしこれが関係しているのだとすると、様子見中のEmacsはハングしない事が期待できるかも？...... と期待したのですが、やっぱりハングが再現しました🥺。

Cygwin 3.6.2-1に相当するコミットをcheckoutしてビルド。野良ビルドしてもこのバージョンならハング再現しないのか？を確認してみる事に。何故かビルドに失敗したのですが、Cygwin 3.6.2-1の後にw32apiが13.0.0-1になった為ヘッダの二重定義が発生している模様。手でちょっと直して対応。
gdbで実行するとパッケージのCygwin 3.6.2-1と同じく謎のSIGTRAPが発生する事は無いようです。少なくとも謎のSIGTRAPについては面倒ですがどのコミットで発生するようになるかを特定する事は可能かも。 Emacsの方は見ている範囲ではハング再現はせず。再現しないのが期待ですが、一応一晩放置で様子見する事に。

2025/08/15

AM中に起床。

Emacs 30.2のリリースアナウンス (Emacs 30.2 released)。メンテナンスリリースという位置づけのようです。結局昨日は深夜までアクセス可能になりませんでした🥺。

Cygwinパッケージの libglibのバージョンを libglib2.0_0-2.85.x-1(今年の5月末～のリリース) よりも前の libglib2.0_0-2.84.1-1(今年の4月頃リリース) まで戻したいと思ったのですがインストーラーで選択できず。ローカルにはダウンロードしたアーカイブファイルがあるので再インストール可能なハズですが。しかたないので選択可能な範囲で一番古い libglib2.0_0-2.85.1-1 まで戻して様子見。

うーむ、やっぱりハングが再現します。libglibじゃない可能性もあるのですが、やっぱりもっと古いのに戻したい。という訳でlibglib2.0_0-2.84.1-1のアーカイブ(runtimeとdevel)を展開して手動インストールした後、適当にCygwin本体を再インストールしてrebaseを実行。一応ファイルの日付は4月になっている事と、野良ビルドしたemacs-w32は再ビルドしなくても起動できたので様子見。

glibを4月のまで戻してもやっぱりハングが再現しました🥺。先日も記したのですが、glibは最新のままでCygwin本体を 3.6.2-1まで戻せば動くので、 glibが原因では無いかも知れません。困った。
現時点のワークアラウンドは以下のいずれかになるかと思います。

Cygwin本体のバージョンを 3.6.2-1まで戻す。
IME/他パッチを当てて Emacsを野良ビルドする際のconfigureオプションに --without-imagemagick と --without-rsvg を指定して組み込みImageMagickと RSVG対応を無効化する。

ただし、前者は時期を逃すと Cygwinのインストーラで選択できるバージョンのスコープを外れる可能性があり、一度新しいのを入れてしまうと戻れなくなる可能性はあります。また、後者は ImageMagickの処理を全て外部コマンドで行うように設定変更を伴ったり、そもそも SVG描画が使えなくなります(SVGを直接描画使用するアプリは使用できなくなります)。どちらにしてもダメージが大きすぎる🥺

gdbからプログラムを実行すると謎の SIGTRAPを受信して停止しまくる件。 handleコマンドで「handle SIGTRAP nostop」のようにして停止しないようにして実行してみたり。停止はしないけどSIGTRAPを受信した事は表示されるのでひとまずこれでハング再現するか？を様子見してみたり。
SIGTRAPで停止しないようにしたEmacsでハングが再現したのですが、C-zを押してもSIGSTPが受信されていないのか止められず。当然のように C-cもダメ。むーん🤔。タスクマネージャでプロセスを終了すると、SIGHUPを受けて終了するようです。コンパイルのオプティマイズレベルでも下げてみるか....
もしかするとハングがSegfaultとかに変わる事を期待したのですが、オプティマイズレベルを下げても様子は変わらず。
clangでコンパイルしてみるかと思い試してみたり。warningメッセージは出るもののビルドに成功。実行してみるもやっぱりハングは再現します。
straceを使ってハング直前に何をやってたか判るか？と思って試してみるも、イマイチ何やってたんだか判らず。何度か straceを使用した状態でハングが再現したのですが、

   :
   80 381962734 [sig] emacs-30.1.1 1052 sigpacket::process: signal 14, signal handler 0x1005F9BB0
   41 381962775 [sig] emacs-30.1.1 1052 sigpacket::setup_handler: suspending thread, tls 0x7FFFFCE00, _main_tls 0x7FFFFCE00
  107 381962882 [[pango] fontcon] emacs-30.1.1 1052 set_signal_mask: setmask C082006, newmask 0, mask_bits C082006
   64 381962946 [sig] emacs-30.1.1 1052 _cygtls::inside_kernel: pc 0x7FFFC52D1364, h 0x7FFFC52D0000, inside_kernel 1
   61 381963007 [[pango] fontcon] emacs-30.1.1 1052 sig_send: sendsig 0x13C, pid 1052, signal -71, its_me 1
   48 381963055 [sig] emacs-30.1.1 1052 sigpacket::setup_handler: couldn't interrupt.  trying again.
  101 381963156 [[pango] fontcon] emacs-30.1.1 1052 sig_send: wakeup 0x125C
   42 381963198 [sig] emacs-30.1.1 1052 sigpacket::setup_handler: suspending thread, tls 0x7FFFFCE00, _main_tls 0x7FFFFCE00

「[[pango] fontcon] ....」というのが毎度ハングでメッセージが出なくなる前に現れていて、どちらもImageMagickの /usr/bin/cygMagickCore-7.Q16HDRI-9.dll や RSVGの /usr/bin/cygrsvg-2-2.dll から辿れると言えば辿れるような気も。ただ、Emacs本体からpangoの関数を呼んでいる訳ではない(というかpangoの何を指しているかもよくわからない)ので、スタックトレース的な物がないと調べられないなぁという感じ。うーむ🤔

2025/08/14

AM中に起床。

Cygwin 3.6.3-1以降で Emacsがハングする件。
まずCygwinパッケージのemacs-w32の .pdmp ですが、例えば 30.1 であれば「/usr/libexec/emacs/30.1/x86_64-pc-cygwin/emacs-*.pdmp」に配置されていた模様。なので、pdump対応を外している訳では無かったみたい。なのですが、、、configureオプションに「--with-dumping=none」を追加してダンプを抑止した実行バイナリだとハングがすぐには再現しなくなりました。むぅ🤔

その後、色々試してみたり。見かけ上、

Cygwin 3.6.2-1を、3.6.3-1以降に入れ替えると、野良ビルドしたemacs-w32実行ファイル(pdump有効) でハングするようになる。
オリジナルのemacs-w32(pdump有効のハズ)ではハングしない。
Cygwin 3.6.4-1でも configureオプションに --with-dumping=noneを付けて野良ビルドした実行ファイルはハングが再現しない........ と思いきやしばらくするとハング再現🥺。
ただし、pdump有効よりは大分長持ち。
configureオプションに --with-dumping=unexecを付けて野良ビルドした実行ファイルもハングは再現しない....... と思ったけどしばらくするとハング再現🥺。
ただし、pdump有効よりは大分長持ち。

という感じになっています。
あと、様子見してみる限り恐らくEmacsがハングするのとは別件のようですが、

Cygwinを 3.6.4-1で gdbからemacsを実行すると、オリジナルのemacs-w32、pdumpした野良ビルドemacs、 dump無し野良ビルドemacs、unexec-dumpした野良ビルドemacsのいずれも、起動途中や起動後に SIGTRAPシグナルを受信して止まる。continueで続けても、少し動いてまたSIGTRAP受信で止まる。
Emacsハングの件を調べるのにgdbを使用できないという謎の縛りが発生しています🥺。

というのもあります。

以前、Cygwin 3.6.2と 3.6.3の変更点でそんな事になるのか？と思ったのですが、当時はリリースノートを見ただけの感想でした。実際にどんな変更が入っていたのだろうか？と思い、gitリポジトリをcloneして 3.6.2と 3.6.3のタグを比較(==3.6.3の変更差分の抽出)してみた結果が以下です。

$ git branch
* cygwin-3_6-branch
  main

$ git diff cygwin-3.6.2 cygwin-3.6.3
diff --git a/winsup/cygwin/include/cygwin/version.h b/winsup/cygwin/include/cygwin/version.h
index 622aaa95a..961a98c78 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -11,7 +11,7 @@ details. */
    changes to the DLL and is mainly informative in nature. */

 #define CYGWIN_VERSION_DLL_MAJOR 3006
-#define CYGWIN_VERSION_DLL_MINOR 2
+#define CYGWIN_VERSION_DLL_MINOR 3

 /* CYGWIN_VERSION_DLL_COMBINED gives us a single number representing the
    combined DLL major and minor numbers. */
diff --git a/winsup/cygwin/release/3.6.3 b/winsup/cygwin/release/3.6.3
new file mode 100644
index 000000000..60031e5b0
--- /dev/null
+++ b/winsup/cygwin/release/3.6.3
@@ -0,0 +1,5 @@
+Fixes:
+------
+
+- Fix "There are no available terminals" error with AzureAD accounts.
+  Addresses: https://cygwin.com/pipermail/cygwin/2025-May/258214.html
diff --git a/winsup/cygwin/uinfo.cc b/winsup/cygwin/uinfo.cc
index 83883f9f6..ffe71ee07 100644
--- a/winsup/cygwin/uinfo.cc
+++ b/winsup/cygwin/uinfo.cc
@@ -1996,10 +1996,6 @@ pwdgrp::fetch_account_from_windows (fetch_user_arg_t &arg, cyg_ldap *pldap)
       if (sid_id_auth (sid) == 5 /* SECURITY_NT_AUTHORITY */
          && sid_sub_auth (sid, 0) == SECURITY_APPPOOL_ID_BASE_RID)
        break;
-      /* AzureAD SIDs */
-      if (sid_id_auth (sid) == 12 /* AzureAD ID */
-         && sid_sub_auth (sid, 0) == 1 /* Azure ID base RID */)
-       break;
       /* Samba user/group SIDs */
       if (sid_id_auth (sid) == 22)
        break;

うーむ、やっぱりこれで変になるとは思えない....🤔

だんだん rebase関連の事案じゃないかと思い始めたり。オリジナルのemacs-w32は imagemagick無し(デフォルト)、rsvg無し(Cygwin向けは未対応)ですが、 IME他パッチ版の野良ビルドではこれらを含んでいます。これを順に外してみる事に。

--with-imagemagick, --with-rsvg, --with-native-image-api はハング再現する。
--without-imagemagick, --with-rsvg, --with-native-image-api はハング再現する。
--without-imagemagick, --without-rsvg, --with-native-image-api はハング再現せず。
--with-imagemagick, --without-rsvg, --with-native-image-api はハング再現する。

imagemagickもrsvgも両方外せばハング再現せず。ある意味オリジナルのemacs-w32(ハングせず)に近いのかも。で、imagemagickとrsvgに共通する点で心当たりがあると言えば glibが思い浮かんだり。丁度 Cygwin 3.6.3-1のアップデートと同じくらいの時期に glib2.0_0-2.85.x-1 ってのがパッケージリリースされています。 Cygwin本体だけを 3.6.2-1に戻せば大丈夫というのと辻褄が合わないですが、時期的な所に連動しているので何か手がかりはないか？と思ったり。それにしても、毎年 Cygwin本体が更新されるとなにやら Emacsが不調になって、その原因を調べているような気がします🥺。

とかやっているうちに、Emacs30系のブランチに emacs-30.2 のタグが打たれたっぽい。 git pullして気づいたのでリリースアナウンスを確認したいのですが、 MLアーカイブページがタイムアウトで反応しなくて確認できず。そういやここ1ヵ月くらいMLアーカイブページのタイムアウトにかなり高い確率で遭遇するなぁ？とは思ったり。メインのftpサイトにはアーカイブが置かれている模様。ftpサイトも激烈に遅くてダウンロードに小一時間を要したり。
で、IME/他パッチを当ててビルド。configureのパッチがリジェクトされたのは 30.1.90の時と同じでした。 Cygwin 3.6.2-1での確認ですが、ちょろっと動かした感じではいきなりずっこけたりはしなさげ。 Cygwinパッケージのリリースまでテストする感じで。少し前に、30.2に向けてそろそろ動きがあるだろうと予想していたのですが、ハングの件が拗れてしまっているので油断していました。

2025/08/13

AM中に起床。

そういえば Unicode 16.0 で追加される絵文字に東日本で言うところの「スコップ」、西日本で言うところの「シャベル」が追加されますが、絵文字の説明的にはどっちになるんだ？と思い、Emacs 31.0.50 の admin/unidata/emoji-sequences.txt を調べてみたところ、0x1FA8Fに対応する絵文字は「shovel」と記されていました。シャベルのWikipedia によると、「日本のJISでは足をかける部分があるものをシャベル、無い物をスコップとしている」ようなので、東日本の方が逆なのかも。スコップはオランダ語らしいので英語圏の人には分からない。また、「園芸用こて」は英語で trowel らしいので、やっぱりスコップは通じないのかも。

シャベルの事を調べていて、JIS(Japanese Industrial Standards)の日本語呼びが「日本工業規格」から「日本産業規格」になっていたらしい (日本産業規格のWikipedia)のを知ったり。 industrialは工業/産業どちらの意味もあるのでJISはそのままの模様。 JISマークも変わったりしているようですが、Unicodeに旧JISマーク「〄」が刻まれているのはそのままみたい。 JISマークのUnicode文字が割り当てられている経緯に MacJapanese(Wikipedia)なるAppleの独自ShiftJIS拡張が関係しているらしい。そういえば以前、「㌀」や「㍇」なんて誰得なんだ？と思った事がありましたが MacJapaneseが起源となっているようです。今回、旧JISマークのようなロゴマークをUnicode文字に入れてるのは迂闊だよなぁ？と思ったのですが、「㌀」や「㍇」の時にも思った「なんで？」の犯人はMacJapaneseだったのか。

Windows Update。ノートPCのアップデートだけ何故か異常に遅いのは変わらず。

Cygwin 3.6.3-1以降で Emacsがハングする件。普段使いのデスクトップPCで調べるのは色々と作業の邪魔になるのでノートPCで確認してみる事に。 Cygwin 3.6.3-1まで入れてあったのですが、3.6.4-1にアップデートして Emacsをいくつか起動して再現するかを試してみたり。やっぱり契機は判りませんが再現はする模様。で、とりあえず gdbを挟んでみるかと試してみたところ、 run実行したら何故か起動途中くらいで SIGTRAPが発生して止まったり。なんだこれ？🤔 continueで続けると、ちょっとするとまた SIGTRAPが発生するという感じで全然普通に動く様子がなかったり。止まる場所は決まっていなさげ。むむ。これを受けて、ハングの発生しない Cygwin 3.6.2-1 のデスクトップPCで同じく gdb上で動かしてみたところ、 SIGTRAPが発生するような事はありませんでした。もしかしてハングと関係ある？🤔

様子を見始めたら少し模様が付いている感じに見えたり。

Cygwinパッケージオリジナルのemacs-w32バイナリおよび emacs-gtkバイナリでは、試している範囲内ではハングが再現しない。
自分でビルドしたIME/他パッチの当たっている emacs-w32バイナリだと再現する。ビルドし直したり、IMEパッチだけを無しにしても再現する。

という事から、オリジナルのバイナリのconfigureオプションを「M-x describe-variable」で変数 system-configuration-options から調べて適用したり、pdumpをやめたりするとどうなるか？を調べてみる方向で。

pdumpをやめるにはconfigureオプションが必要っぽいのですが、オリジナルのバイナリのconfigureオプションにはダンプに関するオプションが指定されていません。オリジナルのバイナリはどうやってビルドしたんだ？🤔

2025/08/12

AM中に起床。

Emacsのキー割り当てとして「\C-z」には「scroll-down」コマンドを割り当てています (Emacs24以降から(?)scroll-down-commandになっていたらしい。さっき知りました😅)。元々 X68kの μEmacs で previous-page という scroll-downに相当するページ単位のスクロールに割当たっていたのが由来で設定しています。 Emacsでは「\C-v」が「scroll-up-command」が割当たっていて、これは X68kの μEmacsでも「\C-v」に同じ動作の「next-page」が割当たっていたのですが、 Emacsでの「scroll-down-command」が「\M-v」に割当たっているのは (Metaキーは ESCキーを使った2ストローク入力だったのもあり) "無いわー"と思ったのと、サスペンドなんて頻繁に行わないだろ？という理由から、X68kの設定を逆輸入する形で「\C-z」への「scroll-down」割り当てを30年以上前から行っています。で、この「\C-z」への割り当てって何由来だろう？と思って調べたのですが出所は分からず。 X68kの μEmacs では ED.Xのキーバインドが少し混ざっているので、ED.X由来か？とも思ったのですがそういう訳でも無いっぽい。
さておき、一般的に scroll-down-commandに相当する操作は「\M-v」のまま使っているのだろうか？🤔 先に記した通り ESC押しの2ストローク操作は論外にしても、CtrlとALTを押し分けるのも結構難しいように思います。

今になってX68kのμEmacsのキーバインドを調べたのですが、罫線描画のモード(バインド)があったのか...とか、 grepモードがあったのか...とか、「M-x describe-bindings」って使えたのか...など、全然使いこなせていなかったかも知れんなぁと思ったりも😓。

そういえば何か違和感があったのですが、Edgeで使用しているデフォルトフォントが「Noto Sans/Serif JP」になっているなぁ？と思ったり。Webで調べると4月には変わっていたようですが、Windows10には適用されていなさげだった事と、新PC(Windows11)への乗り換えを行った 5月時点では既に変化点が無い状態だったので気づいていませんでした😅。きっかけは「\(ASCII 0x5c)」が「¥(円マーク)」じゃなくて「\(バックスラッシュ)」で表示されていたので気づきました。Microsoftが表示互換を損なうようなデフォルト変更を入れてくるとは思いませんでした。固定幅フォントは去年変更された BIZ UDGothic のままなのでpreタグ内は

\(ASCII 0x5c)

「¥」で表示されるようです。もしフォントもロケールに依存しない (例えば日本語フォントの「¥(円マーク)」やEUC-KRの「₩(ウォン)」で表示される事が無い)方向に進んでいるのだとすると、以前「Windows標準の日本語文字フォントでは表示互換を維持する為にバックスラッシュ表示になる事は絶対に無い」と思っていたのがそうではなくなる可能性はあるのかも？

以前、「游ゴシック Regular」には「猶」の文字が旧字体で表示される不具合があると言うのを知り確かにと思ったのですが、現在の Windows11では修正されているようです。

Windows10 游ゴシック猶

修正されたという情報を全然見つけられないのですが、少なくともTANEが知った2024年5月時点には修正済っぽかったらしい。そしてWikipedia にも修正された事が記されていないままとなっているようです。 Windows11で修正されていてもWindows10はそのままなので、「Windows10では修正されていない」と言われればそんな気もしますが。

2025/08/11

AM中に起床。

先日、いくつか知らないフォントがあって挙げてみたのですが、fontタグで指定してもうまく反映できないフォントがありました。例えば「Bodoni MT Poster Compressed」というフォントで、フォントファイルは「BOD_PSTC.TTF」が対応していると思われるのですが、 Windowsのフォント設定で探すと完全名「Bodoni MT」のフォントファミリに属していて face違いという扱いのようです。しかし、メタデータのフォントフェイスを選択することができて、「Poster Compressed」を選択すると完全名は「Bodoni MT Poster Compressed」となります。なんだこりゃ？🤔 Emacs上ではファミリ名「Bodoni MT Poster Compressed」を指定すれば表示できる、つまり「Bodoni MT」とは別ファミリという扱いになっています。仮に同ファミリの別faceの扱いだとして、WeightでもSlant(italic,oblique)でも無いパラメータで指定するのか？🤔

そういえば、UNIXのラインエディタに「ed」がありますが、 X68kに標準で付属していたフルスクリーンのテキストエディタも「ED(ED.X)」だったなと思ったり。これまでX68kの話の文脈から UNIXのedを連想した事は無いなと思ったりも。 X68kのEDのキーバインドってどんなだったっけ？と思って検索してみたら、 AI回答に X68kでラインエディタの edを操作するような例が出てきて、「X68000のテキストエディタ「ed」のキーバインドについてですね。edはUNIX系OSで使われる基本的なテキストエディタで、X68000にも搭載されていました。具体的なキーバインドは、標準的なUNIX版edとほぼ同じです。」と記されていたので、うーん？🤔 ってなりました。X68kの話の文脈でも UNIXのedを連想するのは AIはどういう学習をしたんだ？とは思ったりも。

2025/08/10

AM中に起床。

掃除したり。

何気にフォントの一覧を眺めていて、こんなフォントありましたっけ？と思ったり。 Windows10とWindows11とで「c:\Windows\Fonts」を比べてみて、気になったものをザックリ挙げてみました。以下の表はfontタグのface指定を使っていますが、 Windows11じゃないとフォントが存在しなくてうまく表示できないかも知れません。

ファミリ名(完全名) 表示例

Berlin Sans FB Berlin Sans FB: This is a pen. 012345

Bernard MT Condensed Bernard MT Condensed: This is a pen. 012345

Broadway Broadway: This is a pen. 012345

Brush Script MT Brush Script MT: This is a pen. 012345

Chiller Chiller: This is a pen. 012345

Colonna MT Colonna MT: This is a pen. 012345

Cooper Black Cooper Black: This is a pen. 012345

Curlz MT Curlz MT: This is a pen. 012345

Felix Titling Felix Titling: This is a pen. 012345

Forte Forte: This is a pen. 012345

Gigi Gigi: This is a pen. 012345

Goudy Stout Goudy Stout: This is a pen. 012345

Harlow Solid Harlow Solid: This is a pen. 012345

Jokerman Jokerman: This is a pen. 012345

Juice ITC Juice ITC: This is a pen. 012345

Magneto Magneto: This is a pen. 012345

Matura MT Script Capitals Matura MT Script Capitals: This is a pen. 012345

Onyx Onyx: This is a pen. 012345

Ravie Ravie: This is a pen. 012345

Rage Rage Italic: This is a pen. 012345

Rockwell Rockewll: This is a pen. 012345

Script MT Script MT: This is a pen. 012345

Showcard Gothic Showcard Gothic: This is a pen. 012345

Stencil Stencil: This is a pen. 012345

Viner Hand ITC Viner Hand ITC: This is a pen. 012345

Vivaldi Vivaldi: This is a pen. 012345

Vladimir Script Vladimir Script: This is a pen. 012345

普段使いできる感じのものは少ない気もしますが😅。

ファミリ名(完全名)	表示例
Berlin Sans FB	Berlin Sans FB: This is a pen. 012345
Bernard MT Condensed	Bernard MT Condensed: This is a pen. 012345
Broadway	Broadway: This is a pen. 012345
Brush Script MT	Brush Script MT: This is a pen. 012345
Chiller	Chiller: This is a pen. 012345
Colonna MT	Colonna MT: This is a pen. 012345
Cooper Black	Cooper Black: This is a pen. 012345
Curlz MT	Curlz MT: This is a pen. 012345
Felix Titling	Felix Titling: This is a pen. 012345
Forte	Forte: This is a pen. 012345
Gigi	Gigi: This is a pen. 012345
Goudy Stout	Goudy Stout: This is a pen. 012345
Harlow Solid	Harlow Solid: This is a pen. 012345
Jokerman	Jokerman: This is a pen. 012345
Juice ITC	Juice ITC: This is a pen. 012345
Magneto	Magneto: This is a pen. 012345
Matura MT Script Capitals	Matura MT Script Capitals: This is a pen. 012345
Onyx	Onyx: This is a pen. 012345
Ravie	Ravie: This is a pen. 012345
Rage	Rage Italic: This is a pen. 012345
Rockwell	Rockewll: This is a pen. 012345
Script MT	Script MT: This is a pen. 012345
Showcard Gothic	Showcard Gothic: This is a pen. 012345
Stencil	Stencil: This is a pen. 012345
Viner Hand ITC	Viner Hand ITC: This is a pen. 012345
Vivaldi	Vivaldi: This is a pen. 012345
Vladimir Script	Vladimir Script: This is a pen. 012345

2025/08/09

AM中に起床。

「新美の巨人たち」。伊藤若冲と円山応挙が割とご近所さん(距離にして200mくらい)だったらしい。交流の記録は無いみたいですが若冲の方が17歳年上だったようなので、まぁそれなら直接の交流は無いかも知れないなぁとは思ったりも。

2025/08/08

テレワーク。早めに終了。

先日、ビデオゲームは残すのが大変と記したのですが、そういやオンラインサービスのみのゲームはサービス終了とともに遊ぶこと自体ができなくなる物もあるよなぁ？と思ったり。かろうじてブログや動画配信で記録として残る場合はあるかも知れませんが、ゲーム進行の無いようなコミュニケーションゲームだとほとんどは思い出にしか残らない(そしていつか忘れられる)と思います。もしかすると、今から30年後は 1980～1990年代のゲームは遊べるのに 2010～2020年代のゲーム(特にスマホゲーム)はほとんど遊べないという状況になっているかも知れません。

2025/08/07

テレワーク。早めに終了。

「グラディウスオリジンコレクション」てのが発売されているらしい (公式ページ)。グラディウス、II、III、沙羅曼蛇、LIFE FORCE、2、他と、新作として沙羅曼蛇IIIが収録されているらしい。グラディウスIVは？ 90年代前半までのタイトルなのか？と思ったのですが、完全な再現が難しかったので未収録とした模様 (参考記事)。そういやグラディウスVはナンバリングタイトルだけど PS2専用で移植もされていません。あと、言われてみれば今年はシリーズ40周年なのか。大分前、30年とか50年とかに渡って出たらそれはそれでスゴいと書いた事がありましたが、既にビデオゲームは本や音楽や映画と変わらないなとは思ったりも。ただ、メディア的に残すのが大変という問題はあるかも知れませんが。

2025/08/06

テレワーク。早めに終了。

調べごとをして終了。

2025/08/05

テレワーク。早くもなく遅くもなく終了。

Web巡回して終了。

2025/08/04

テレワーク。気持ち早めに終了。

そういえば、Copilotと言われると Microsoft Copilot と GitHub Copilot がありますが、単にCopilotというとどちらを指すかは文脈によるかも。用途は全く違うので混ざることは無いかも知れませんが。

現在では、恐竜は鳥類の祖先という事になってますが、海に棲んでいた首長竜は爬虫類に分類されていて恐竜では無いらしい。「ドラえもんのび太の恐竜」に出てくるピー助はフタバスズキリュウという設定でしたが、現在の分類に従うとピー助は恐竜では無いという事になります。そこ変わるのか....とは思ったりも。

2025/08/03

AM中に起床。

掃除したり洗濯したり。

そういえば、ラッコって日本では鳥羽水族館のメス2頭だけになっているらしい。海外から輸入する事もできなくなっているようなので、このままだと日本で見られなくなるのは時間の問題のようです。
ところで、Windows11の Fluent Emoji ではカワウソに相当する OTTER の絵文字のデザインはラッコのように描かれています(🦦)。ラッコは英語で Sea otter なのだそうな。カワウソと兼用でも良いのかも知れませんが、背泳ぎで手に何か持っているとラッコにしか見えない不思議。 Google検索でAIの回答に「ラッコの絵文字は、一般的に「🦭」で表されます。」って記されていたのですが、それはアザラシだろ？とは思ったりも。AIは絵文字を絵として認識していないのだろうか？🤔
MSのCopilotに「🦦は何の絵文字ですか？」って聞いたら「ラッコの絵文字です」って答えが返ってきました。ラッコと認識しているのもあるかも知れませんが「この絵文字を元に絵を描けますか？」って聞いたら、

絵文字🦦を元にMS-Copilot画伯の描いたラッコ

って絵が描かれました。器用なもんです。結局絵文字の絵を見てラッコと判断しているのか、文字コードにラッコが紐づけられているのかは判断できません...

そうだ、それも聞いてみればいいじゃん？と思い「Microsoft Copilotは絵文字のテキストを絵として認識しているのですか？それとも文字コードに対応した意味として認識しているのですか？」と聞いてみたら「Copilotは🦦のような絵文字を、画像そのものではなく「Unicodeで定義された文字コード」として処理します。その上でコンテキストや学習データに基づき、ある種の“意味”や“概念”として理解しています。」という回答でした。文字コードにラッコが紐づけられているということらしい。どうも OTTER の絵文字はラッコっぽく描かれた絵の方が多いようなので、人類もラッコとカワウソの区別が付いていないようには思ったりも。

2025/08/02

AM中に起床。

何気に調べごとをしていて、node.jsは CygwinでビルドできるというAI回答が出てきたので、マジで？と思って試してみたらダメでした🥺。大分古いバージョンでビルドできていた事があったようですが今はできそうに無いです。検索してみてもWindowsのバイナリを使用する....みたいな方向に向いているのですが、 Cygwinからだとファイルパスの問題が解決できない場合があるので、結局用事にならない事の方が多い気がします。

2025/08/01

テレワーク。早めに終了。

そういえば「ASSEMBLY SUMMER'25」が始まっているもよう。メインのCOMPOは日本時間の深夜から早朝という感じだと思うので、 Pouetで結果を見る感じになるかも知れませんが。

TOP PREV