Gauche:Bugs
Gaucheのversionと、できれば日付もいれといて下さい。日付は[[$date]]で入れられます。
- invalid VM instruction (Gauche HEAD 86cee81)
- sys-strftime のタイムゾーン名 (0.9.11-p1)
- 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
invalid VM instruction (Gauche HEAD 86cee81)
齊藤(2022/03/18 03:47:47 UTC): rssmix.cgi を wiliki-server 経由で起動して使っているとき、つまり
gosh wiliki-server ./rssmix.cgi
というコマンドで起動して使っていたときにエラーが出ました。
実行環境は Windows 10 Home (Version 21H1) 64bit 版、 Gauche も 64bit 用にビルドしたものです。
以下はそのときにコンソールに表示されていたログです。 エラー以降は (ブラウザ側で) 何度リロードしても Internal Server Error (gauche-makiki が返しているエラーメッセージ?) と表示されます。
どこに原因があるのかよくわからないのですが "invalid VM instruction code: 1905" とあるところから Gauche 内部のエラーと判断してここで報告することにしました。
2022-03-18T11:44:16+0900: 127.0.0.1 "GET /rssmix.cgi HTTP/1.1" 500 118 "http://localhost:3133/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0" 6.653ms VM 00000000a1b6e640 ----------------------------------------------------------- pc: 00000000a17197e8 [ 1(00000000a17197e0)] (4eac6771) sp: 00000000a1bbf590 [00000000a1bbf000-00000000a1bbf000-00000000a1bd2880] argp: 00000000a1bbf590 val0: 0 ... envs: 00000000a0fe0ac0 #f ... up=00000000a1a6d408 size=2 [ #<closure ((#f #:G820))> #<closure ((#f #:G821))> ] 00000000a1a6d408 #f ... up=00000000a0d83160 size=1 [ (define-class <rssmix> () ((sites :init-keyword :sites :init-value '()) (num-items :init-keyword :num-items :init-value 70) (title :init-keyword :title :init-value "Recent Changes") (db-name :init-keyword :db-name :init-value "/home/shiro/data/rssmix.dbm") (db-type :init-keyword :db-type :init-form <gdbm>) (cache-life :init-keyword :cache-life :init-value 1800) (fetch-timeout :init-keyword :fetch-timeout :init-value 15) (max-title-width :init-keyword :max-title-width :init-value 65) (max-threads :init-keyword :max-threads :init-value 4) (db :init-value #f) (db-lock :init-form (make-mutex)))) ] 00000000a0d83160 #f ... up=00000000a0d8c400 size=2 [ #<closure ((load-from-port read+) port)> #<closure ((load-from-port restore-load-context))> ] 00000000a0d8c400 #f ... up=00000000a0dfdba8 size=8 [ #<read-context 00000000a0dfdbe0> #<read-context 00000000a0943020> 1 permissive () ((#f)) #<iport(closed) ./rssmix.cgi 00000000a1714aa0> #<module gauche.require-base> ] 00000000a0dfdba8 #f ... up=00000000a0dfdb88 size=1 [ #f ] 00000000a0dfdb88 #f ... up=00000000a0d83138 size=1 [ ("C:\\gauche\\share\\gauche-0.98\\0.9.11-p1\\lib") ] 00000000a0d83138 #f ... up=00000000a0d83100 size=3 [ #f ("C:\\gauche\\share\\gauche-0.98\\0.9.11-p1\\lib") () ] 00000000a0d83100 (load-from-port port :key (paths #f) (environment #f)) ... up=0000000000000000 size=2 [ (:environment #f :paths ("C:\\gauche\\share\\gauche-0.98\\0.9.11-p1\\lib")) #<iport(closed) C:\gauche\share\gauche-0.98\site\lib/wiliki/rssmix.scm 00000000a1714770> ] conts: 00000000a1bbf560 env = 00000000a9af93e0 size = 2 base = 00000000a9cb8578 pc = {cproc 00000000a9966010} 00000000a1bbf520 env = 00000000a9af93e0 size = 3 base = 00000000a9cb8578 pc = {cproc 00000000a9968710} 00000000a1bbf4b0 env = 00000000a1bbf498 size = 0 base = 00000000a9cb8578 pc = 00000000a9cc10c0[ 13(00000000a9cc1058)] (00000053) 00000000a1bbf430 env = 00000000a1bbf418 size = 0 base = 00000000a1b3d540 pc = 00000000a1811c10[ 22(00000000a1811b60)] (00001063) 00000000a1bbf3e0 env = 00000000a1bbf3c8 size = 0 base = 00000000a9c73ef8 pc = 00000000a9c8a658[ 17(00000000a9c8a5d0)] (00400036) 00000000a1bbf388 env = 00000000a9af93e0 size = 1 base = 00000000a9c73f50 pc = {cproc 00000000a9943bf0} 00000000a1bbf350 env = 00000000a19561f0 size = 0 base = 00000000a0d6d6c0 pc = 00000000a1885758[ 67(00000000a1885540)] (00400036) 00000000a1bbf2c0 env = 00000000a1bbf2a8 size = 0 base = 00000000a9c3bf08 pc = 00000000a9c41268[ 20(00000000a9c411c8)] (00400036) 00000000a1bbf220 env = 00000000a1bbf208 size = 0 base = 00000000a9c73ef8 pc = 00000000a9c8a658[ 17(00000000a9c8a5d0)] (00400036) 00000000a1bbf1c8 env = 00000000a9af93e0 size = 1 base = 00000000a9c73f50 pc = {cproc 00000000a9943bf0} 00000000a1bbf190 env = 00000000a9af93e0 size = 1 base = 00000000a1302960 pc = {cproc 00000000a9943bf0} 00000000a1bbf158 env = 00000000a9af93e0 size = 1 base = 00000000a1302a80 pc = {cproc 00000000a9943bf0} 00000000a1bbf120 env = 00000000a192dc40 size = 0 base = 00000000a1352780 pc = 00000000a0b22640[ 8(00000000a0b22600)] (00001018) 00000000a1bbf0f0 env = 00000000a9af93e0 size = 1 base = 00000000a1352900 pc = {cproc 00000000a9943bf0} 00000000a1bbf0b8 env = 00000000a1bbf0a0 size = 0 base = 00000000a142f8a0 pc = 00000000a1440e50[ 38(00000000a1440d20)] (0000003e) 00000000a1bbf000 env = 0000000000000000 size = 0 base = 0000000000000000 pc = 00000000a9d9d458 (00000000) C stacks: 00000000ed5ffac0: prev=00000000ed5ffcb0, cont=00000000a1bbf000 00000000ed5ffcb0: prev=0000000000000000, cont=0000000000000000 Escape points: 00000000a1515cc0: cont=00000000a1bbf350, handler=#<closure ((%unwind- ... 00000000a14f2180: cont=00000000a1bbf190, handler=#<closure ((%unwind- ... 00000000a14f24e0: cont=00000000a1bbf158, handler=#<closure ((handle-c ... 00000000a14f2de0: cont=00000000a1bbf120, handler=#<closure ((handle-c ... 00000000a14b2000: cont=00000000a1bbf0b8, handler=#<closure ((job-run! ... dynenv: ((#<closure ((%unwind-protect #f #f))> . #<closure ((%unwind-protect #f #f))>) (#<subr> . #<subr>) (#<closure ((cgi-handler #:loop674 #f r))> . #<closure ((cgi-handler #:loop674 #f r))>) (#<closure ((with-input-from-port with-input-from-port))> . #<closure ((with-input-from-port with-input-from-port))>) (#<closure ((%unwind-protect #f #f))> . #<closure ((%unwind-protect #f #f))>) (#<subr> . #<subr>) (#<subr> . #<subr>) (#<subr> . #<subr>) (#<subr> . #<subr>)) reset-chain-length: 0 Code: 2022-03-18T11:45:55+0900: http handler error "invalid VM instruction code: 1905" 2022-03-18T11:45:55+0900: *** ERROR: invalid VM instruction code: 1905 2022-03-18T11:45:55+0900: Stack Trace: 2022-03-18T11:45:55+0900: _______________________________________ 2022-03-18T11:45:55+0900: 0 (report-error e #f) 2022-03-18T11:45:55+0900: at "C:\\gauche\\share\\gauche-0.98\\site\\lib/makiki.scm":666 2022-03-18T11:45:55+0900: 1 (log-format drain "http handler error ~s\n~a" (~ e 'message) ... 2022-03-18T11:45:55+0900: [unknown location] 2022-03-18T11:45:55+0900: 2 (make-mutex) 2022-03-18T11:45:55+0900: at "C:\\gauche\\share\\gauche-0.98\\site\\lib/wiliki/rssmix.scm":81 2022-03-18T11:45:55+0900: 3 (make <rssmix> :sites '(("WiLiKi" "http://practical-scheme.ne"... 2022-03-18T11:45:55+0900: at "./rssmix.cgi":35 2022-03-18T11:45:55+0900: 4 (%unwind-protect (lambda () (proc `(,script-name))) (lambda ( ... 2022-03-18T11:45:55+0900: expanded from (unwind-protect (proc `(,script-name)) (close-output-port (c 2022-03-18T11:45:55+0900: at "C:\\gauche\\share\\gauche-0.98\\site\\lib/makiki/cgi.scm":74 2022-03-18T11:45:55+0900: 5 ((job-thunk job)) 2022-03-18T11:45:55+0900: at "C:\\gauche\\share\\gauche-0.98\\0.9.11-p1\\lib/control/job.scm":133 2022-03-18T11:45:55+0900: 6 (job-run! job) 2022-03-18T11:45:55+0900: at "C:\\gauche\\share\\gauche-0.98\\0.9.11-p1\\lib/control/thread-pool.scm":96 2022-03-18T11:50:36+0900: 127.0.0.1 "GET /rssmix.cgi HTTP/1.1" 500 118 "http://localhost:3133/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0" 5.413ms "./vminsn.scm", line 791: Assertion failed: (G1197)!=(NULL) "./vminsn.scm", line 791: Assertion failed: (G1197)!=(NULL) "./vminsn.scm", line 791: Assertion failed: (G1197)!=(NULL)
- hamayama(2022/03/19 09:54:14 UTC): #811 で、文字列変換のメモリ確保を修正したので、一応試してもらえますか?
(別な原因かもしれませんが…)
- 齊藤(2022/03/19 17:47:24 UTC): 問題は解消されました。
sys-strftime のタイムゾーン名 (0.9.11-p1)
- 齊藤(2022/03/10 05:36:29 UTC):
今の Gauche の sys-strftime は C 標準ライブラリの strftime を呼出しています。
Windows の strftime はタイムゾーン名を漢字などを含む文字列で結果が返す場合があり、そのとき日本語ロケールにおいては Shift_JIS (CP932) の文字列として返しているようです。
時刻を文字列化するにあたって sys-strftime で、書式指定として %Z を使っていると Windows で動かしたときに文字化けしてしまいます。
sys-strftime はシステムの strftime を呼出す手続きであるということであればこれはこれで一貫した挙動であるとも考えられますが、実際に WiLiKi で sys-strftime を使っている箇所で文字化けしていますので、なんらかの形で修正されることを期待します。
(WiLiKi のバグとして報告するかどうか迷ったのですが、たぶん Gauche としても意図した挙動ではないですよね?)
- hamayama(2022/03/16 00:10:22 UTC): 文字化けについては、プルリクエスト #809 を出しました。
ただ、msvcrt の strftime が、"%T" とか使えないみたいで、微妙ですが…
- Shiro (2022/03/17 09:19:46 UTC): hamayamaさんのパッチをもとに、strftimeの互換レイヤを 入れてみましたが…プラットフォーム独立にするなら独自実装するしかないかもしれません。 それともstrftimeはそういうものと割り切って、互換性が欲しければsrfi-19を使うか。
- 齊藤(2022/03/18 02:34:07 UTC): 当該箇所の問題が解消されていることが確認できました。
私自身には sys-strftime を使う強い動機はなく WiLiKi での問題を辿ったらそこに行き着いたというだけなので sys-strftime (を含む sys- 付き手続き) は基本的にシステムに対する窓口であると割り切る (移植性が必要であれば srfi-19 を活用する) 方針には同意します。
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): これは見落としでした。ありがとうございます。