最近の出来事

2025/09/13

AM中に起床。

gptel。先日のHSV2RGB変換を、コードのスタイルを少し変更する条件を加えてみたところ、 大分様子の違うコードが生成されました。

先日のに最後の一行を加えただけです。

/*
  色相と彩度と明度を 赤と緑と青 に変換するC言語の関数を作成してください。
  関数は「HSV2RGB(double h, double s, double v, double &r, double &g, double &b)」とし、
  入力となる色相は変数h、彩度は変数v、明度は変数vとし、変換結果はr,g,bはポインタ変数に
  赤はr、緑はg、青はbにそれぞれ値を格納してください。
  色相は0～360.0、彩度は0～1.0、明度は0～1.0 の範囲で指定します。
  赤、緑、青は 0～1.0の範囲に変換してください。
  関数の戻り値は変換できた場合は0を返し、入力となる色相、彩度、明度の値が範囲外の場合は-1を返してください。
  コード内コメントは日本語で、インデントは半角スペース2個で記してください。
*/

#include <math.h>

int HSV2RGB(double h, double s, double v, double *r, double *g, double *b)
{
  // 色相・彩度・明度の範囲チェック
  if (h < 0.0 || h > 360.0 || s < 0.0 || s > 1.0 || v < 0.0 || v > 1.0)
    return -1;

  // 彩度が0ならグレースケール
  if (s == 0.0) {
    *r = v;
    *g = v;
    *b = v;
    return 0;
  }

  double hh = h / 60.0;
  int i = (int)floor(hh);
  double f = hh - i;
  double p = v * (1.0 - s);
  double q = v * (1.0 - s * f);
  double t = v * (1.0 - s * (1.0 - f));

  switch (i % 6) {
    case 0: *r = v; *g = t; *b = p; break;
    case 1: *r = q; *g = v; *b = p; break;
    case 2: *r = p; *g = v; *b = t; break;
    case 3: *r = p; *g = q; *b = v; break;
    case 4: *r = t; *g = p; *b = v; break;
    case 5: *r = v; *g = p; *b = q; break;
  }

  return 0;
}

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

gptel。gptel-send や gptel-rewrite を試してみたり。どこまで書けるものか？を試してみた感じ、 ある程度内容を示せばイケるみたい。

以下のような文言を記してみました。

/*
  色相と彩度と明度を 赤と緑と青 に変換するC言語の関数を作成してください。
  関数は「HSV2RGB(double h, double s, double v, double &r, double &g, double &b)」とし、
  入力となる色相は変数h、彩度は変数v、明度は変数vとし、変換結果はr,g,bはポインタ変数に
  赤はr、緑はg、青はbにそれぞれ値を格納してください。
  色相は0～360.0、彩度は0～1.0、明度は0～1.0 の範囲で指定します。
  赤、緑、青は 0～1.0の範囲に変換してください。
  関数の戻り値は変換できた場合は0を返し、入力となる色相、彩度、明度の値が範囲外の場合は-1を返してください。
*/

#include <math.h>

/*
 * Convert HSV to RGB.
 *
 * Parameters:
 *   h  - Hue in degrees [0, 360]
 *   s  - Saturation [0, 1]
 *   v  - Value (brightness) [0, 1]
 *   r  - Pointer to store red component [0, 1]
 *   g  - Pointer to store green component [0, 1]
 *   b  - Pointer to store blue component [0, 1]
 *
 * Returns:
 *   0  - Success
 *  -1  - One or more parameters out of range
 */
int HSV2RGB(double h, double s, double v,
            double *r, double *g, double *b)
{
    if (!r || !g || !b)
        return -1;

    if (h < 0.0 || h > 360.0 || s < 0.0 || s > 1.0 || v < 0.0 || v > 1.0)
        return -1;

    double c = v * s;                     /* chroma */
    double h_prime = h / 60.0;
    double x = c * (1.0 - fabs(fmod(h_prime, 2.0) - 1.0));
    double m = v - c;

    double r1, g1, b1;

    if (h_prime >= 0.0 && h_prime < 1.0) {
        r1 = c;  g1 = x;  b1 = 0.0;
    } else if (h_prime >= 1.0 && h_prime < 2.0) {
        r1 = x;  g1 = c;  b1 = 0.0;
    } else if (h_prime >= 2.0 && h_prime < 3.0) {
        r1 = 0.0; g1 = c; b1 = x;
    } else if (h_prime >= 3.0 && h_prime < 4.0) {
        r1 = 0.0; g1 = x; b1 = c;
    } else if (h_prime >= 4.0 && h_prime < 5.0) {
        r1 = x;  g1 = 0.0; b1 = c;
    } else { /* h_prime >= 5.0 && h_prime < 6.0 */
        r1 = c;  g1 = 0.0; b1 = x;
    }

    *r = r1 + m;
    *g = g1 + m;
    *b = b1 + m;

    return 0;
}

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

記録的短時間大雨で落雷による停電がありました。体感で1分くらい停電したように思いますが、 色々リセットされてつらい。EmacsハングのテストはノートPCで行っているので継続されてました😅。

Emacsで使用できる AIチャットクライアントはいくつかあるようですが、Ollamaも使えるらしい gptelを試してみたり。 面倒臭いのは依存パッケージに Transient の 0.7.4 以降が必要なのですが、Emacs-30.2の標準パッケージのは 0.7.2.2 の為そのままでは使え無さそうです。 Transient は今や色んな所で使われつつあるので、 迂闊に新しいのを入れると色んな所がダメになりそうなのですが、仕方ないので入れてみたり。 最初に 影響を受けるであろう magit をちょろっと確認してみたのですが、「l l」でログを表示すると、 これまでのログを全て表示しようとしていたり。早速影響があるのが判明。 仕方ないのでmagitの方も更新したところ、適当な行数のログ表示で止まるようになりました。

で、本題のgptelを試したり。.emacsでの最小設定は以下くらいで良さそうです。

(require 'gptel)
(setq
 gptel-model 'gpt-oss:20b
 gptel-backend (gptel-make-ollama "Ollama"
                 :host "localhost:11434"
                 :stream t
                 :models '(gpt-oss:20b)))
(setq gptel-default-mode 'org-mode)

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

ノートPCはEmacsハングのテストの為に立ち上げっぱなしにしていたのですが、 今朝 Windowsアップデートが自動的に適用されてました。Emacsハングのテストは強制終了となったものの、 それと引き換えに いつもWindowsアップデートのダウンロートが何故か全然進まない イライラがありませんでした。 次回から使ってなくてもWindowsアップデート前日に電源入れておくかと思ったりも😓。

今まであまりよく見ていなかったのですが、何故かGPUの 3Dの負荷が常時 30% くらいあるなぁ？と思ったり。 「デスクトップウインドウマネージャー」というプロセスが薄っすらGPUを使っているようなのですが、 なんぞこれ？と思ったり。そして、起動しているEmacsを最小化するとGPU負荷が 0% になるようだったり。 どういうメカニズム？🤔
Webにあるような視覚効果の無効化をいくつか適用してみたのですが、あまり変化は無いようにみえたり。 あと、ウインドウサイズを小さくすると負荷が下がり、大きくすると上がるようです。 最小化すると0になるのとも辻褄が合っていると言われればそんな気もします。 まぁ気になるなら最小化しておくかというくらいで。

Ollamaの OpenAI互換APIを CygwinのPythonから使ってみようと思い、「pip install openai」を 実行してみたのですが、jiter という依存ライブラリがインストールできないようだったり。 エラーメッセージの一部が以下。

 :
  × pip subprocess to install build dependencies did not run successfully.
  │ exit code: 1
  ╰─> [28 lines of output]
      Collecting maturin<2,>=1
        Using cached maturin-1.9.4.tar.gz (213 kB)
        Installing build dependencies: started
        Installing build dependencies: finished with status 'done'
        Getting requirements to build wheel: started
        Getting requirements to build wheel: finished with status 'done'
        Installing backend dependencies: started
        Installing backend dependencies: finished with status 'done'
        Preparing metadata (pyproject.toml): started
        Preparing metadata (pyproject.toml): finished with status 'error'
        error: subprocess-exited-with-error

        × Preparing metadata (pyproject.toml) did not run successfully.
        │ exit code: 1
        ╰─> [3 lines of output]
            Python reports SOABI: cpython-39-x86_64-cygwin
            Unsupported platform: x86_64-cygwin
            Rust not found, installing into a temporary directory
            [end of output]

        note: This error originates from a subprocess, and is likely not a problem with pip.
      error: metadata-generation-failed

      × Encountered error while generating package metadata.
      ╰─> See above for output.

      note: This is an issue with the package mentioned above, not pip.
      hint: See above for details.
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.

 :

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

デスクトップのWindows11もCygwinにパッチを当てて様子を見てみることに。Emacsの動作よりも、普段使いして 他のコマンドに副作用が無いかの様子を見る感じで。

タスクマネージャでGPUの使用率にCUDAが選べなかった件は、先日の参考ページの通りで 再起動したら 表示できるようになりました。Ollamaを動かしてみたところ、問に答える時にCUDA全力で動いているようです。 あとよく見ていなかったのですが、GPUメモリをバク食い(13.8GBくらい)しています。

EmacsハングのCygwinパッチ対応。一昨日から複数のEmacsを起動しっぱなしにしていたのですが、 3つあるうちの一つが止まっていたり😭。やっぱりロックが解除できない状況に陥っているようです。 確かに、パッチのロジックでは、ロックがかかっている場合は100% スキップ されますが、ロックがかかっていないと判定した後で、ロックを掛ける前にスレッドがスイッチして ロック実行を横取りされる可能性はゼロではありません。 それをアトミックに行うのが InterlockedExchange() などのような特別な関数なのでしょうけど。うーむ。 ただ、ハング発生確率はかなり低くなっているとは言えそうです。

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

EmacsハングのCygwinパッチ対応。昨日から複数のEmacsを48時間ほど起動しっぱなしにしていたのですが、 どれもハングすること無く動き続けてます。ひとまず今週のWindowsアップデートが来るまでそのまま継続してみよう。

唐突ですが ローカルLLMとやらを試してみたくなったので調べてみたり。 Ollamaというツールを使えば 色々なモデルが試せるようなのでインストールしてみたり。 インストール完了と同時にプロンプト入力ウインドウが開き、適当に質問を入れたらモデル(gpt-oss:20b) がダウンロードされ始め、完了すると応答が返ってきたのでこれで使えるようです。



ollamaというコマンド名でコマンドラインからも使えるので(Cygwinのmintty+bash、screenコマンドを挟んでも 良いし、Emacsのvtermからも一応使えました)、どうにかすればEmacsとかからも使えるんじゃないかなー？ という気がします。ただ、応答がMarkdownで表示されるようなので、普通のターミナルでは なんか読みにくいです😓。
あと、デスクトップのWindows11のタスクマネージャはGPUの使用率表示にCUDAを選べません。 見かけ上 GPUを使っていないようにも見えるのですが、 GPU-Zで負荷を見てみると一応GPUを使っているようです。 Webで検索してみるとズバリな回答があったり (参考ページ)。 再起動が必要みたいですが、今は色々動かしてて再起動したくないので明日試してみよう。

AM中に起床。

掃除したり洗濯したり。

D言語で以下のような構造体のコンストラクタを書いたのですが、何故かエラーで怒られたり。

$ cat -n struct_test.d
     1  import std.stdio;
     2  import std.string;
     3
     4  struct Test{
     5    int x;
     6
     7    this(){
     8      x=3;
     9    }
    10  }

$ dmd struct_test.d
struct_test.d(7): Error: constructor `struct_test.Test.this` default constructor for structs only allowed with `@disable`, no body, and no parameters
  this(){
  ^

AM中に起床。

Emacsハングの件。というかCygwinハングの件。 straceでアタッチしたままほったらかしておいたところハングしてました。 ダメなのか？と思い Process Explorer で見てみたところ何故かメインスレッドがサスペンド状態 になっていました。Resumeで再開してみたらそのままSegfaultになったり。なんだこりゃ？🤔 straceでアタッチしていたのがダメなのか？とも思ったので、今度はただ起動しておくだけにしてみたり。 どうなるか....？

12時間ほど見てみたのですが、straceでアタッチしていた時のようにサスペンド状態にはならなかったり。 なにやら動きが変わるのかも知れませんが確認ムズい🥺。
一旦区切りとして、Cygwinのパッチは以下のような感じ。

diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index f79978f73..bb45b0148 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -961,7 +961,7 @@ _cygtls::interrupt_now (CONTEXT *cx, siginfo_t& si, void *handler,
       if (!inside_kernel (cx, true))
        {
          HANDLE h_veh = AddVectoredExceptionHandler (0, singlestep_handler);
-         cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
+//       cx->EFlags |= 0x100; /* Set TF (setup single step execution) */
          SetThreadContext (*this, cx);
          suspend_on_exception = true;
          in_singlestep_handler = false;
diff --git a/winsup/cygwin/mm/cygheap.cc b/winsup/cygwin/mm/cygheap.cc
index 1c9b8037b..c34ff8c26 100644
--- a/winsup/cygwin/mm/cygheap.cc
+++ b/winsup/cygwin/mm/cygheap.cc
@@ -743,6 +743,8 @@ init_cygheap::find_tls (int sig, bool& issig_wait)
   while (++ix < (int) nthreads)
     {
       /* Only pthreads have tid set to non-0. */
+      if (threadlist[ix].thread->locked () != false)
+       continue;
       threadlist[ix].thread->lock ();
       if (!threadlist[ix].thread->tid
          || !threadlist[ix].thread->initialized)

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

Emacsハングの件。というかCygwinハングの件。 先日のコンパイルのオプティマイズレベルを上げたものでもハング再現しないようだったり。 そういや既にロックしてたらスキップするみたいなコードなのですが、一度発生したらロックしっぱなしなのか、 ぶつかりさえしなければアンロックされているのか、が気になったので調べてみる事に。 と言っても、デバッガ上で動かすと動きが変わってしまいそうなので、デバッグprintを使おうと思ったのですが、 普通のはどれも大量に使用されているようだったので、special_printf()というのを使って 「strace --mask=special ...」でメッセージを絞る感じで観察しようと思ったり。 しかし、「strace --mask=special emacs-w32」で最初から strace に乗せると、メッセージが出ていなくても 異常に遅かったので、起動を済ませた後で 「strace --mask=special -p プロセスID」でアタッチする方式で網掛け。 さて、どうなるか....？

網掛けメッセージはわりとすぐに出力されたり。ただ、持続したりはしないみたい。 ついでにシグナル番号と思われるものも表示してみていたところ、どうやら SIGALRM を受けた時に 既にロックされている場面に遭遇しているようでした。killコマンドで SIGALRM を送ったらどうなる？ と何の気なしに「while true; do kill -s SIGALRM pid; done」で送りまくってみたら、 デバッグメッセージが流れるように表示されたり😅。 もしかして再現を加速できる？と思ったので Cygwin 3.6.2-1 かつ オリジナル emacs-w32 で試してみた のですが、動きが遅くなったりはするもののハングにまでは至らず。むぅ。

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

Emacsハングの件。というかCygwinハングの件。 先日加えたCygwinの改造を適用してEmacsを立ち上げっぱなしにしていたのですが、 26時間以上ハング再現しないという状況です。 対処方法として正しいか否かは別にして、ひとまず避けられているみたい。 一旦止めて コンパイルのオプティマイズレベルをO0からO2に戻したものに差し替えて しばらく様子を見てみよう。

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

Emacsハングの件。もう一度Cygwinのソースコードを眺めたり。 ロック制御している箇所の一つは winsup/cygwin/mm/cygheap.cc:init_cygheap::find_tls() の中なのですが、 もう一つ winsup/cygwin/local_includes/cygtls.h 内で定義されるクラス _cygtls の中の get_signal_arrived()というメソッドがありました。 なんとなく、シグナルが到着したら何かするって感じみたいです。 昨日の改造コードは既にロックがかかっていればそのままにするってロジックにしたのですが、 なんかダメかもなぁ？って感じだったかも。 そこで、find_tls()の方を ロックがかかっていたらそのスレッドは無視して次のスレッドを チェックするようなロジックにしてみたり。まぁこれも直している事になっているのか分かりませんが、 二重にロックしようとして脱出できなくなる事は無くなるハズ？という期待です。 そもそも、一つのスレッドで find_tls() と get_signal_arrived() を同時に実行する事は無い のだとすると、find_tls()を実行するスレッドAと、get_signal_arrived()を実行するスレッドBが ちゃんと切り替われば、ロックが脱出できなくなることは無いハズと考えられます。 しかし、実際にロック処理で脱出できなくなっているので、 「lock()～unlock()」の組がどの瞬間にも複数重ならないようにしたらどうなるか？ という感じです。

Emacsハングとは関係無い話。ELISPの message関数を使ってデバッグしていて、何故かELISPエラーと なって、なんで？ってなりました。最小コードで示すと「(message "100%")」でエラーとなりました。 message関数の1番目の引数はフォーマットストリングなので「%」がダメって事でした。 実際には文字列の入っている変数を 何の気なしに「(message strvar)」とかやってしまってたのですが、 習慣的に「(message "%s" strvar)」と書く癖を付ける必要があるかもなぁ？とは思ったりも。 修行が足りません🥺。

タケモトピアノのCMがリニューアルでHD化されとる。

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

先日のロックコードのループにカウンタを設けて、あるカウント回数に達したら exit するようなコードにして ハングではなく終了するか？という網掛け確認してみたり。.....すぐに再現せず。

時間はかかりましたが一応 網にはかかったり。やっぱりlockを脱出できない場合があるみたい。 で、ロックを実行するコードを眺めていて思ったのですが、自分でロックをかけて用事が終わったら 自分でアンロックするという前提のコードになっているのですが、既にロックがかかっている場合は 脱出できない状況に必ず陥ると思われます。なので、ロックがかかっていない場合に限り ロックをかけるという風にしてはどうか？と思ったり。

コードを変更して実行。ひとまずハング再現待ち。と言ってもハングしない状況になるので、 どこでロックされたか分からないのに別の所でロックを外す事になるけど、それで変にならないか？という 確認になるかも知れませんが。

ん～～、なんかダメでした。何故かハングが再現する場合と、exitする網掛けに引っかかる場合があって、 なんで？な感じ。

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

Emacsハングの件。 Emacsをgdbに乗せずに直実行したところでハングが再現した後、以下のような操作でどこで止まっているかを 調べてみたり。

1. Process Explorer で予めCPUをバグ食いしているスレッドIDを調べておく。
2. 「gdb -p プロセスID」でアタッチする。
3. 「info threads」のスレッド一覧と、1.のスレッドIDを付き合わせて、「thread #id」でスレッドを切り替える。
4. 「si」コマンドで命令単位のステップ実行をしばらく繰り返して、Cygwin上のコード領域に脱出する。

  void lock ()
  {
    while (InterlockedExchange (&stacklock, 1))
      {
#ifdef __x86_64__
        __asm__ ("pause");
#else
#error unimplemented for this target
#endif
        Sleep (0);
      }
  }

AM中に起床。

掃除したり洗濯したり。

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

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

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

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;
}

$ 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__) */
}

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

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

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

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

調べごとをして終了。

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

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

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

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

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

1. gdb上で Emacsを実行。
2. Ctrl-Zなどで適当にSIGSTOPで「info threads」でスレッドの一覧を表示。
3. Process Explorerで対象となるEmacsのプロセスを探して、右クリック→Propertiesの Threadsタブを開く。
4. 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

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

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)

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]

  :
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 ?? ()
  :

(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)

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と同等

$ 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

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

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

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

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

先日の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]

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]

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

先日、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

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

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)

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

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

特に何も掴めず🥺。

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相当 | 発生する    | 野良ビルド | ハングする                   |

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の方は見ている範囲ではハング再現はせず。再現しないのが期待ですが、一応一晩放置で様子見する事に。

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対応を無効化する。

   :
   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

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有効よりは大分長持ち。
  

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

$ 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;

• --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 はハング再現する。

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パッチだけを無しにしても再現する。
  

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)

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はどういう学習をしたんだ？とは思ったりも。

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

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

AM中に起床。

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

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

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

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

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

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

調べごとをして終了。

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

Web巡回して終了。

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

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

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

AM中に起床。

掃除したり洗濯したり。

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



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

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

AM中に起床。

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

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

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