Gauche:Bugs
Gaucheのversionと、できれば日付もいれといて下さい。日付は[[$date]]で入れられます。
- Gauche の Windows 用インストーラ (0.9.10_rc1)
- Windows で、mbedTLS が libgcc に依存する (0.9.10_pre2)
- reset/shift と guard の組み合わせで Assertion failed が発生する (0.9.9)
- reset/shift と guard の組み合わせでメモリリークする (0.9.9)
- GitHub Actions の failure (0.9.9 リリースより後の HEAD)
- Scm_RegExec の引数の数が変わった (0.9.9)
- version 0.9.9以前: Gauche:Bugs:log19
- version 0.9.5以前: Gauche:Bugs:log18
- version 0.9.4以前: Gauche:Bugs:log17
- version 0.9.3以前: Gauche:Bugs:log16
- version 0.9.2以前: Gauche:Bugs:log15
- version 0.9.1以前: Gauche:Bugs:log14
- version 0.9以前: Gauche:Bugs:log13
- version 0.8.14以前: Gauche:Bugs:log12
- version 0.8.13以前: Gauche:Bugs:log11
- version 0.8.11以前: Gauche:Bugs:log10
- version 0.8.10以前: Gauche:Bugs:log9
- version 0.8.9以前: Gauche:Bugs:log8
- version 0.8.8以前: Gauche:Bugs:log7
- version 0.8.7以前: Gauche:Bugs:log6
- version 0.8.6以前: Gauche:Bugs:log5
- version 0.8.4以前: Gauche:Bugs:log4
- version 0.8.2以前: Gauche:Bugs:log3
- version 0.8以前: Gauche:Bugs:log2
- version 0.7以前: Gauche:Bugs:log1
- version 0.6以前: Gauche:Bugs:log0
Gauche の Windows 用インストーラ (0.9.10_rc1)
hamayama(2020/11/07 04:02:58 UTC): インストールと簡単な動作確認を実施しました。
Windows 10 (64bit) : 64bit 版と 32bit 版のインストーラでインストール OK
Windows 8.1 (64bit) : 64bit 版のインストーラでインストール OK
Windows XP SP3 : 32bit 版のインストーラでインストール OK です。
(Windows XP SP3 では、gauche.net や rfc.tls 等、一部のモジュールが使用できません)
気になった点としては、インストーラのライセンス表示があります。
(1) libiconv-2.dll はもう含まれていない
(ただし、冒頭の SUMMARY に gauche--charconv.dll についての記述があるので、
LGPL のライセンス文書の表示自体はあった方がよい?)
(2) libmbed*.dll はもう含まれていない
(ただし、rfc--tls--mbed.dll と libgauche-static-0.97.a が、
mbedTLS の内容を含んでいる旨の記述と、
Apache License 2.0 のライセンス文書の表示自体はあった方がよい?)
- Shiro(2020/11/07 07:03:28 UTC): チェックありがとうございます。ライセンスに関しては、
gauche--charconv.dll
がlibiconvを含み、rfc--tls--mbed.dll
が MbedTLSを含むので、文書は必要でヘッダだけ直せば良さそうです。 - 修正pushしました。
- hamayama(2020/12/13 03:12:03 UTC): 0.9.10 リリースおめでとうございます。
(上と同じ環境にインストーラでインストール確認し OK です)
- Shiroども!
Windows で、mbedTLS が libgcc に依存する (0.9.10_pre2)
hamayama(2020/10/15 00:56:37 UTC): 再度確認してみたのですが、今でも、
MSYS2/MinGW-w64 の標準の mbedTLS パッケージは、libgcc に依存しているようです。
(libmbedcrypto.dll が、128bit の除算関数 ( __udivti3 等) を使っているもよう)
このため、mbedTLS を有効にして、Gauche の Windows 用インストーラを作成する場合、
libgcc_s_seh-1.dll (64bit 環境の場合) や libgcc_s_dw2-1.dll (32bit 環境の場合) を、
インストーラに含める必要があります。
これらの dll が見つからないと、TLS の接続時に以下のようなエラーが出ます。
*** ERROR: failed to link C:\Program Files\Gauche\lib\gauche-0.97\0.9.10_pre2\x86_64-w64-mingw32/rfc--tls--mbed.dll dynamically: error code 126 While loading "C:\\Program Files\\Gauche\\share\\gauche-0.97\\0.9.10_pre2\\lib/rfc/tls/mbed.scm" at line 39
対策案のひとつとして、-static-libgcc を付けてビルドした mbedTLS のローカルパッケージを作成して、
以下に置いておきました。
https://github.com/Hamayama/mbedtls-static-libgcc-package
https://github.com/Hamayama/mbedtls-static-libgcc-package/releases
これをインストールした環境で、インストーラを作成すれば、
libgcc の dll を配布する必要はなくなります。
(ただ、mbedTLS の最新版への追従等、忘れそうですが。。。)
<その他 情報等>
mbedTLS のスレッド機能は、pthread を使用しているため、libwinpthread-1.dll も必要です。
これは、前回インストーラに含めておくようにしたため、大丈夫でした。
(Windows ネイティブのスレッドには、現状、対応していないもよう)
<テスト用メモ>
(use rfc.tls) (default-tls-class <mbed-tls>) ;; https://curl.haxx.se/ca/cacert.pem (tls-ca-bundle-path "c:\\work\\ca\\cacert.pem") (use rfc.http) (receive (status header-list body) (http-get "syosetu.org" "/" :secure #t) (print status))
- Shiro(2020/10/15 22:43:55 UTC): あああそうか。ありがとうございます。 利便性を取るか、コンパクトさ(依存関係の少なさ、ライセンスの単純さ)を取るか、ですねぇ。 と言っても後者を望む人なら自力でソースツリーからビルドできそうだから、 インストーラで手軽に試したい人向けには全部載せの利便性重視でいいかもしれない。
- hamayama(2020/10/18 01:34:15 UTC): 本件ですが、いくつか気になる点があります。
(1) 現状、Gauche の本体については、-static-libgcc を付けて静的リンクするようになっていますが、
mbedTLS については、動的リンクにする方針でしょうか。
(静的リンクにすると保守の手間が増えるので、そういう方針ということであれば、問題はないと思います)
(2) 32 bit 版では、libgcc_s_seh-1.dll ではなく libgcc_s_dw2-1.dll を含める必要があります ( dll の名前が異なります)。
(mingw-dist.sh で対応は可能と思います)
(3) ライセンスについては、GPL のランタイムライブラリ例外により問題ないと思いますが、
libgcc の dll の配布にあたっては、ドキュメント等に記載が必要なのかどうかが、
いまいちよく分かりませんでした。
- Shiro(2020/10/18 05:08:52 UTC): そうでした…いろいろ思い出した。 そうなるとむしろmbedtlsのソースをsubmoduleとかでも持っといて一緒にビルドしちゃった方が楽かなあ。それならlibgccスタティックリンクできるし。あるいはmingw版ビルド時だけダウンロードしてビルドするようにしてもいいか。
- Shiro(2020/11/01 06:31:28 UTC): 現在までのコミットで、
./configure --with-tls=mbedtls-internal
とするとMbedTLSをダウンロードしてビルドするようになりました。MinGWでは、mingw-dist.sh --with-mbedtlsとすると同様の動作になります。libgcc.dllへの依存は生じません。ただ、このオプションを使う場合はCMakeが必要です。また、これでビルドした場合、rfc--tls--mbed.{so,dll}
およびlibgauche-static-0.97.a
にMbedTLSのコードが含まれるため、バイナリでの配布はGaucheのBSDLだけでなくMbedTLSのApache License 2.0にも従う必要があります。
reset/shift と guard の組み合わせで Assertion failed が発生する (0.9.9)
hamayama(2020/08/15 12:26:51 UTC): chaton のログ (2ヵ月前ですが。。。)
http://chaton.practical-scheme.net/gauche/a/2020/06/14
<サンプルのリスト>
- pcdemo8.scm ( https://gist.github.com/nkoguro/bcb23f9a1913cfced2817680d3fcfb46 )
エラーになる (Assertion failed) : HEAD 0.9.9
エラーにならない (ただし、dynamic-wind の呼び出しは変) : 0.9.8 0.9.5
- pcdemo9.scm ( https://gist.github.com/nkoguro/a212a14bc6478b68dee5f0790e97ac1f )
pcdemo8.scm と同じ (make-worker はデッドコードだった)。
- pcdemo10.scm ( https://gist.github.com/nkoguro/13ba5257847507e637416aa92a2e889c )
エラーになる (attempt to return from a ghost continuation) : HEAD 0.9.9 0.9.8 0.9.5
hamayama(2020/08/15 12:26:51 UTC): pcdemo8.scm については、#716 で対策しました。
ただ、Assertion failed については 発生しなくなりましたが、想定していた動作とは違うかもしれない。
hamayama(2020/08/15 12:26:51 UTC): pcdemo10.scm については、
(reset (next)) を (reset (next) 1000) にすると、ghost continuation エラーが発生しなくなる。
どうも、guard が reset の 末尾位置にある場合、
部分継続によるジャンプ後にエラー処理して guard を抜けると、ghost continuation エラーになるもよう。
ただ、汎用的な修正方法については、ちょっと分からなかった。
(reset の末尾に強制的に何か挿入するようにしたら、ループ時にメモリリークした)
reset/shift と guard の組み合わせでメモリリークする (0.9.9)
hamayama(2020/06/02 09:08:38 UTC): 以下のページより。
http://chaton.practical-scheme.net/gauche/a/2020/05/30
<サンプルのリスト>
- pcdemo3.scm ( https://gist.github.com/nkoguro/7fd58e919c0ae0050280e874ab22ddf2 )
リークする : HEAD 0.9.9
リークしない : 0.9.8 0.9.5
- pcdemo2.scm ( https://gist.github.com/nkoguro/0ca865b06c1a06d33f32f93e5861a980 )
wrap 手続きから guard を除いたもの。
リークしない : HEAD 0.9.9 0.9.8 0.9.5
- pcdemo4.scm ( https://gist.github.com/nkoguro/fee9551e6cfee0a633eb7991dd16df95 )
スレッドプール版
リークする : HEAD 0.9.9 0.9.8 0.9.5
- loop.scm ( https://gist.github.com/nkoguro/8e5e124837e5ae67a0b8a79e4bb0d218 )
10回ループしてエラーを投げると、10回キャッチされる。
guard の body は末尾再帰にならない件のサンプル
- pcdemo5.scm ( https://gist.github.com/nkoguro/3bfdabdf23e12825c03fd8d2f93c9a7c )
10回ループしてエラーを投げても、1回しかキャッチされない。
guard の body からループしている訳ではないということ。
- pcdemo6.scm ( https://gist.github.com/nkoguro/358531a7600b66df62b24b06ea3ec369 )
(reset (thunk)) と (next) からは戻って来ているという証拠。
- pcdemo7.scm ( https://gist.github.com/nkoguro/c9d94caee4949ddc6e741e8a382ac67c )
Kahua の 旧 partcont を使用したもの。
リークしない : HEAD 0.9.9 0.9.8 0.9.5
(ただし、Kahua の 旧 partcont には、別のリークの問題がある。
http://okmij.org/ftp/continuations/against-callcc.html#memory-leak )
hamayama(2020/06/03 09:46:48 UTC): まずはログをたくさん入れてみました。
- pcdemo3_debug.scm ( https://gist.github.com/Hamayama/9b32c83b76256c86651943d323d8b604 )
wrap-1 の thunk after のログだけ出ない。
また、*err-raise* を #t にして、*dbg-level* を 1 にすると、
0.9.9 では「wrap-2 id=G200060 guard catched」となり、
0.9.8 では「wrap-1 id=G59 guard catched」となる。
hamayama(2020/06/04 10:52:30 UTC): うーむ。pcdemo3.scm については、#529 を revert していくとリークしなくなる。
ただ、そうすると、#529 で修正した問題 (#477 等) が復活する。
両方を解決する方法は、まだ見つからない。。。
印象としては、pcdemo3_debug.scm の wrap-2 内の guard における
vm->handlers (vm.c の with_error_handler の辺り) が、
どこからか参照されていて、GC で回収されない感じ。
hamayama(2020/06/04 10:52:30 UTC): pcdemo4.scm については、#529 を revert してもリークする。
こちらは、0.9.5 でもリークするので、何か別の問題があるもよう。
hamayama(2020/06/05 08:11:01 UTC): pcdemo3.scm については、#696 で対策しました。
hamayama(2020/06/05 08:14:40 UTC): pcdemo4.scm については、#696 を適用後に、
wrap 内の reset の後ろに何か無意味な命令 (数値の1000とか) を入れると、リークしなくなるもよう。
(define (wrap thunk) (lambda () (reset (thunk)) 1000))
(0.9.8 以前でも有効。0.9.9 は不可)
ただ、原因はよく分からない。。。(ログを追加していたら直ってしまった)
GitHub Actions の failure (0.9.9 リリースより後の HEAD)
hamayama(2020/02/25 09:30:59 UTC): Gauche のリポジトリに GitHub Actions の設定を追加して、
自動ビルドのワークフローを動かしているのですが、
現状、しばしば failure が発生しています。
まずは、failure の事例を、以下にまとめてみました。
https://gist.github.com/Hamayama/3cc0e9c0c5283e7fc422360c6e5bd372
全体的に、並列処理とディスクの書き込み (書いてすぐは読めない?) に、
何かあるような印象ですが。。。
- Shiro(2020/02/25 17:16:17 UTC):
gauche/priv
のmkdir failedは見たことがあります。多分raceが生じるタイミングがあるんだと思います。
hamayama(2020/05/17 12:02:44 UTC): 最近 MinGW の gcc のバージョンが 10.1 になり、ビルドが通らなくなっています。
リンカで multiple definition of `GC_xxx' というエラーがたくさん出ていて、どうも原因はこれのようです。
https://gcc.gnu.org/gcc-10/porting_to.html
まずは情報として挙げておきます。
- Shiro(2020/05/22 20:45:10 UTC): https://github.com/shirok/Gauche/commit/4a21718a56696f901af2fe3ed2aa3b52e66de9b4 で修正しました。gc_config_macros.h のソースの記述の解釈がgcc10で変わったらしく、0.9.9のリリースtarballでもダメになります。新しくmingwに入れる人はまずバイナリでインストールしてもらわないと。
- hamayama(2020/05/26 06:16:34 UTC): 対応ありがとうございます。
MSYS2 の安定版に戻すべきかとも思ったのですが、(特に最近は) そういう状況でもないみたいで。。。
- hamayama(2020/05/26 06:16:34 UTC): GithubActions の Windows の image に、
デフォルトで MSYS2 を含める件については、ある程度進んでいるようです (最終調整中?)。
そのうち試してみようと思います。
https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md#msys2
https://github.com/actions/virtual-environments/pulls?q=is%3Apr+msys2+
https://github.com/msys2/msys2-installer/issues/5
- hamayama(2020/08/16 05:10:45 UTC): その後、一時、GitHub Actions の Windows の image に
デフォルトで入っている MSYS2 を使うようにしました。
しかし、update に時間がかかるようになったため、結局、毎回インストールする方式に戻しました。
また、公式の msys2/setup-msys2 という action を使うようにしました。
(関連プルリクエスト #699 #702 #704 #705)
Scm_RegExec の引数の数が変わった (0.9.9)
hamayama(2019/12/19 10:28:22 UTC): どうもこの関数を使っている外部ライブラリがあって、
とりあえず以下のようにしましたが。。。
#if defined(SCM_REGEXP_MULTI_LINE) // for Gauche 0.9.9 or later && SCM_REGMATCHP(Scm_RegExec(SCM_REGEXP(skip_regex), SCM_STRING(next_line_str), SCM_UNDEFINED, SCM_UNDEFINED))) { #else // for Gauche 0.9.8 or earlier && SCM_REGMATCHP(Scm_RegExec(SCM_REGEXP(skip_regex), SCM_STRING(next_line_str)))) { #endif
- Shiro(2019/12/19 19:21:59 UTC): これは見落としでした。ありがとうございます。