Gauche:Bugs

Gauche:Bugs

Gaucheのversionと、できれば日付もいれといて下さい。日付は[[$date]]で入れられます。

32bit版の Windows で GC 8.0 の動作が不安定 (0.9.7 リリースより後の HEAD)

hamayama(2019/01/12 09:37:35 UTC): 現象としては、ビルド中や make check 中に、
Fatal error in GC「Unexpected mark stack overflow」というメッセージが出て落ちます。
少し調べた感じでは、libatomic_ops の使用有無や configure の設定とは無関係で、
基本的なところで何か変わっている印象です。
ソースもずいぶん変わっていて、ちょっとすぐには切り分けができなさそうです。
暫定対策としては、GC を gc-7.6.10 + libatomic_ops-7.6.8 に差し替えれば、動作します。
(gc フォルダを入れ替えて、gc フォルダの中に libatomic_ops フォルダを入れる)
ただし、差し替える場合、現状の Gauche HEAD では、Gauche 側も 一部修正が必要になります。
(Gauche側の修正に関しては、プルリクエスト #422 を出しました)

hamayama(2019/01/14 08:58:17 UTC): ある程度調べて、GC側にあげておきました。
https://github.com/ivmai/bdwgc/issues/260
現状、まだ切り分けが不十分です。。。

hamayama(2019/01/23 11:48:24 UTC): 以下で修正されました。
https://github.com/shirok/Gauche/pull/438

ただ、テスト中に別の問題が見つかっていて、そちらは未解決です。
https://github.com/ivmai/bdwgc/issues/262
(Gauche の動作とは関係ないかもしれません)

hamayama(2019/02/09 06:06:18 UTC): 以下で対策されました。
https://github.com/shirok/Gauche/pull/445

GC の libatomic_ops 関連 (0.9.7 リリースより後の HEAD)

hamayama(2019/01/07 06:20:57 UTC): 下記URLの件ですが、以前 GC を調査したときに、
次期バージョンでは (Cコンパイラが対応していれば) libatomic_ops なしで
GC のビルドが可能になるという情報がありました。
https://twitter.com/dico_leque/status/1081896341754630144
ログを見ると、Gauche 側の configure では、
checking which libatomic_ops to use... internal
となっており、GC 側では、
checking which libatomic_ops to use... none
となっているので、この不一致が関係しているのではないでしょうか。
(自分の環境ではビルドはできていますが。。。)
例えば、tools/gc-configure.gnu-gauche.in に
--with-libatomic-ops=no \
を追加して、GC 内の libatomic_ops のみを使用するようにしたら、
とりあえずはビルドできるかもしれません (none と no とで意味が変わるようです)。

アンダースコアの束縛 (0.9.7)

齊藤(2018/12/28 08:35:14 UTC): R7RS によれば、アンダースコア (_) は (scheme base) や (scheme r5rs) で束縛されている識別子ということになっていますが、現在の Gauche ではそうなっていないようです。

Gauche の Windows 用インストーラ (0.9.7)

hamayama(2018/12/22 10:16:14 UTC): 0.9.7 リリースおめでとうございます。
Windows 8.1 (64bit) : 64bit 版と 32bit 版のインストーラでインストール OK
Windows XP SP3 : 32bit 版のインストーラでインストール OK です。
(バグはありませんが、一応記録として残しておきます)

IPv6 のデフォルト有効化について (0.9.7_pre2)

hamayama(2018/12/03 12:54:08 UTC): コミット 64e57dc (2018-12-3) で、IPv6 のデフォルト有効が明記されましたが、
現状、src/mingw-dist.sh では、configure のオプションに --enable-ipv6=no を指定しています。

これは、IPv6 を有効にしたバイナリを、IPv6 が無効に設定されている PC で実行すると、
(make-server-socket 'inet 8080) でエラーになったためだと思います。
(家の Windows PC では、IPv6 の ON/OFF を、ドライバの設定画面で選択できます)

本件は、対策方法がありますが、確か、何か気になる点がありました。
(だいぶ忘れかけていますが。。。)

まず、確か、(make-server-socket (make <sockaddr-in> :host :any :port 8080)) のように
IPv4 を指定すると、エラーは出なくなります。
だた、それだと IPv4 用のプログラムになります。

また、以下のように ipv6-capable を上書きする方法もあったように思いますが、
これは、たまたまチェックに失敗したら、以後は IPv4 になります。 

(with-module gauche.net
  (set! ipv6-capable
        (and (global-variable-bound? 'gauche.net 'sys-getaddrinfo)
             (guard (ex ((<system-error> ex) #f))
               (socket-close (make-socket AF_INET6 SOCK_STREAM))
               #t))))

結局、Windows のインストーラでは、トラブルの元になると考え、
--enable-ipv6=no に設定したように思います。
(必要なユーザは --enable-ipv6=yes で個別にビルドしてもらうということで)

今考えると、ビルドは --enable-ipv6=yes で行い、
何らかの方法で、[IPv4 のみ] / [IPv6 のみ] / [IPv4 と IPv6 の両方に対応] のような
選択を可能にして、Windows の場合は デフォルト設定を [IPv4 のみ] にしておくのが
一案かなとも思いますが。。。

hamayama(2018/12/07 13:18:40 UTC): すいません。再度確認したところ、特にエラーとなることはありませんでした。
確認した環境は、以下の4つです。
(1) Windows 8.1 (64bit) で IPv6 をドライバの設定画面で有効にした場合
(2) Windows 8.1 (64bit) で IPv6 をドライバの設定画面で無効にした場合
(3) Windows 8.1 (64bit) で (2) に加えて、レジストリで IPv6 を無効にした場合 (DisabledComponents: 0xff)
( https://support.microsoft.com/en-us/help/929852/guidance-for-configuring-ipv6-in-windows-for-advanced-users )
(4) Windows XP SP3 (IPv4のみ)

以下のページによると、Windows Vista 以降では、IPv6 を無効に設定しても、
Loopback インターフェース だけは無効化できないようです。
https://blogs.msdn.microsoft.com/shintak/2015/01/12/ipv6/
このため、(make-server-socket 'inet 8080) で [::]:8080 がオープンできないというケースはありませんでした。
ただ、ドライバでは IPv6 が無効になっているため、外部から接続することはできませんが。。。

Windows XP SP3 については、getaddrinfo が IPv4 のアドレスだけを返すため、
0.0.0.0:8080 が正常にオープンされました。
以下のページによると、Windows XP では IPv6 がなくても getaddrinfo が使えるようです。
http://www.geekpage.jp/programming/winsock/getaddrinfo.php

結局、src/mingw-dist.sh でも --enable-ipv6=yes でよさそうです。
(2) (3) のケースで、IPv4 のアドレスを優先する方法があるとうれしいかとも思いますが。。。
((3) のURLにある「Prefer IPv4 over IPv6 (DisabledComponents: 0x20)」の設定をしても、
getaddrinfo の返す順番は変わらないようでした)

hamayama(2018/12/11 13:17:53 UTC): とりあえず試験的に以下のようにしてみたところ、
IPv4 でオープンされて外部から接続できることが確認できました。 

(use gauche.net)

(with-module gauche.net
  (define (make-sockaddrs host port :optional (proto 'tcp))
    (let* ([socktype (case proto
                       [(tcp) SOCK_STREAM]
                       [(udp) SOCK_DGRAM]
                       [else (error "unsupported protocol:" proto)])]
           [port (x->string port)]
           [hints (make-sys-addrinfo :flags AI_PASSIVE :socktype socktype)])
      (map (cut slot-ref <> 'addr)
           (sort (sys-getaddrinfo host port hints)
                 string<?
                 (lambda (ai) (x->string (~ ai 'family))))))))

(make-server-socket 'inet 8080)

Gauche の Windows 用インストーラ (仮) (0.9.6_rc1)

hamayama(2018/07/02 16:43:17 UTC): インストールを実施しました。
Windows 8.1 (64bit) : 64bit 版と 32bit 版のインストーラでインストール
Windows XP SP3 : 32bit 版のインストーラでインストール
以下は気が付いた点です。

(1)64bit版について、mbedTLS を使おうとすると、libgcc_s_seh-1.dll がないというエラー
(依存関係をツールでみると、libmbedcrypto.dll が libgcc_s_seh-1.dll に依存しているようでした) 

gosh> (use rfc.tls)
gosh> (default-tls-class <mbed-tls>)
*** ERROR: failed to link C:\Program Files (x86)\Gauche\lib\gauche-0.9\0.9.6_rc1
\x86_64-w64-mingw32/rfc--tls--mbed.dll dynamically: error code 126
    While loading "C:\\Program Files (x86)\\Gauche\\share\\gauche-0.9\\0.9.6_rc1
\\lib/rfc/tls/mbed.scm" at line 39
Stack Trace:
_______________________________________
  0  <mbed-tls>
        [unknown location]
  1  (eval expr env)
        at "C:\\Program Files (x86)\\Gauche\\share\\gauche-0.9\\0.9.6_rc1\\lib/g
auche/interactive.scm":267

32bit版の方は問題ありませんでした。
使っている mbedTLS は MSYS2 の pacman で入るものでしょうか?

format ~f の不具合 (0.9.6_pre4)

hamayama(2017/10/22 19:20:43 UTC): 以下のケースが見つかりました。 

(format "~,1f" 123.95)  -> "123.:"
(format "~,2f" 999.995) -> "999.9:"
(format "~,10000f" 1)   -> SEGV

テストに使用したファイルは以下になります。
https://gist.github.com/Hamayama/d99c25902983670ffc0a55c1cfc320e1

hamayama(2017/10/27 19:41:24 UTC): どうも、よく分からなくなってしまったのですが。。。
format ~f の digits とは、固定小数点での指定なのか、正規化後の小数点での指定なのか。。。 

(format "~1,2f" 1.003)      ; -> 1.00    (これは正しい)
(format "~1,2f" 0.003)      ; -> 0.003   (これは 0.00 になるべき?)
(format "~1,2f" 0.0003)     ; -> 3.00e-4 (これは正しい?)
(format "~1,2f" 1)          ; -> 1.00    (これは正しい)
(format "~1,2f" 10)         ; -> 10.00   (これは正しい?)
(format "~1,2f" 1000000000) ; -> 1.00e9  (これは正しい?)

hamayama(2017/10/30 01:28:33 UTC): 大きな浮動小数点数を固定小数点で表示しても意味がないので、
これはこれでよい仕様な気がしてきました。
あとは、指数表示に切り替わる桁数が、カスタマイズできるとうれしいと思います。
あと、上記の (format "~1,2f" 0.003) -> 0.003 だけは、バグのような気がします。

hamayama(2017/11/09 10:39:27 UTC): (format "~1,2f" 0.003) の件は修正済みです。

Windows で gctest.exe がまれに FAIL する (0.9.6_pre2)

hamayama(2017/06/05 13:50:34 UTC): make check でまれに gctest.exe が FAIL します。
(Gauche 自体は正常に動作しているようですが)
それで、GCの方に報告してみました。
https://github.com/ivmai/bdwgc/issues/166
最近、libatomic_ops が v7.6.0 に更新されましたが、v7.4.4 に戻してみても現象は同じでした。

hamayama(2017/06/16 10:28:07 UTC): 切り分けの結果、gctest.exe 内の
GC_malloc_explicitly_typed という API のテストで SEGV が発生すると分かりました。
この API は Gauche では未使用であるため、Gauche の本体の実行には影響がないと思います。
(gctest.exe で、このテストだけスキップすることは現状できないようです。。。)

また、開発最新版の GC v7.7.0 では、
gctest.exe に GC_MALLOC_WORDS という API のテストも追加されており、
そこでも SEGV が発生するようでした。将来取り込まれるのであれば、要注意かと。。。
(ただし、以前発生していた GCJサポートのテストで SEGV が発生する件については、
修正されているようでした)

hamayama(2017/06/21 07:03:09 UTC): その後、発生行の切り分けができて、GC v7.7.0 では直りました。
Issue #166: MinGW: gctest.exe fails infrequently in typed alloc
https://github.com/ivmai/bdwgc/issues/166

また、GC_MALLOC_WORDS の不具合についても、GC v7.7.0 では直りました。
Issue #167: MinGW: gctest fails with SIGSEGV in test_tinyfl
https://github.com/ivmai/bdwgc/issues/167

また、GCJサポートのテストで SEGV が発生する件は、以下で修正されていました。
Issue #137: List reversal produced incorrect list if USE_MUNMAP+GC_GCJ_SUPPORT (Mingw32)
https://github.com/ivmai/bdwgc/issues/137
(この修正は、GitHub上の GC v7.2, v7.4, v7.6 の各ブランチにも水平展開されています。
しかし、ダウンロードページの tar.gz については、古いままのようです。。。)

いずれも、Gauche では未使用のAPIのため、Gauche 本体の実行には影響はありません。
(#166 の関係でまれに gctest が FAIL しますが。。。)

あと、今回の件とは関係ありませんが、気が付いた点として、
GC v7.7 では、include/private/gc_atomic_ops.h というファイルが追加されており、
(Cコンパイラが対応していれば) libatomic_ops なしでビルド可能になっているようです。
(開発版なので安定性等は分かりませんが。。。)

MSYS2/MinGW-w64 32bit 開発環境での Gauche のビルド／テストでエラー (0.9.6_pre2)

hamayama(2017/05/07 14:41:57 UTC): 切り分けができていませんが、とりあえず報告しておきます。
MSYS2/MinGW-w64 32bit 開発環境 でのみ現象が発生します。
MSYS2/MinGW-w64 64bit や MinGW.org (32bitのみ) の開発環境では発生しません。
確認した OS は Windows 8.1 (64bit) です。
印象としては、ほとんど動作していて、ごくまれに文字列が化ける感じ。

調査中のメモは、以下に分離しました。
https://gist.github.com/Hamayama/f248c6a8b8e853a49caf58bf1a02399c
(2017/05/09 10:25:44 UTC)

＜分かってきたこと＞
(1) Gauche v0.9.5 を使って Gauche v0.9.6_pre2 をビルド／テストした場合には発生しない。
(2) (1)で作成した Gauche v0.9.6_pre2 を使って Gauche v0.9.6_pre2 をビルド／テストする際にエラーが出る。
(頻度は、3回ビルド&テストすると1回は出る という程度)
(3) MSYS2/MinGW-w64 32bit の少し古い開発環境 (gcc v6.2.0) でも発生する。

＜今後の予定＞
git bisect を使って、HEAD と v0.9.5 の間で、現象が発生するようになったコミットを探す。
(時間がかかりそうですが、マイペースですすめてみます。。。)

hamayama(2017/05/11 11:59:20 UTC): どうも、今日は、全然再現しなくなってしまいました。。。
昨日までと違うところというと、Windows Update があったので、PC を1回再起動したことです。
引き続き調べてみます。。。

hamayama(2017/05/13 01:18:27 UTC): 昨日は1回だけ再現しました。頻度が低くなって切り分けが難しい。。。
dllの依存関係もツールで確認したが、問題はなさそう。
これまでのエラーを見ると、いずれもファイルのロードのところで文字化けが起きている。
しかし文字列のテストでは、エラーは発生していない。
シェルもしくはシェルから引数を受け取るところで化ける？

hamayama(2017/05/13 15:54:07 UTC): 再現スクリプトができました。

hamayama(2017/05/14 12:33:10 UTC): しばらくスクリプトを動かしていますが大丈夫っぽいです(今40000カウントくらい)。
対応ありがとうございます。齊藤さんもいつも有用な情報ありがとうございます。
(参考 : GC_MALLOC_ATOMIC 関連
http://wiki.monaos.org/pukiwiki.php?Reading%20Gauche%2Fgauche.h%2FSCM_MALLOC_ATOMIC )

tls-input-port からの読み込みで ERROR: argument out of range: 1 (0.9.5, HEAD)

shinya 2017/01/11 23:26:22 UTC: tls-read が 1byte だけ読むとマズいようです

パッチ: 

diff --git a/ext/tls/tls.scm b/ext/tls/tls.scm
index 3d61986..15e3347 100644
--- a/ext/tls/tls.scm
+++ b/ext/tls/tls.scm
@@ -119,15 +119,13 @@
     (set! (~ ip'getb)
           (let ((buf #f) (pos 0) (size 0))
             (^[]
-              (if buf
-                (rlet1 r (string-byte-ref buf pos)
-                  (set! pos (+ pos 1))
-                  (when (= pos size) (set! buf #f)))
-                (begin
-                  (set! buf (tls-read tls))
-                  (set! size (string-size buf))
-                  (set! pos 1)
-                  (string-byte-ref buf 0))))))))
+              (unless buf
+                (set! buf (tls-read tls))
+                (set! size (string-size buf))
+                (set! pos 0))
+              (rlet1 r (string-byte-ref buf pos)
+                (set! pos (+ pos 1))
+                (when (= pos size) (set! buf #f))))))))
 
 (define (make-tls-output-port tls)
   (rlet1 op (make <virtual-output-port>)

Windows で HEAD のビルドエラー (0.9.5)

hamayama(2016/12/13 08:12:57 UTC): Gauche の HEAD (ec3c709) をビルドして、その Gauche でさらに HEAD をビルドすると、以下のエラーが出ます。
リリース版の Gauche v0.9.5 を使ってビルドした場合には発生しません。
lib/gauche/interpolate.scm を見ると、string-interpolate は定義されているようですが。。。
OS: Windows 8.1 (64bit), 開発環境: MSYS2/MinGW-w64 

make[2]: ディレクトリ '/c/Gauche/Gauche/ext/util' に入ります
../../src/gosh -ftest ../../src/precomp -e -P -o util--match ../../libsrc/util/match.scm
*** ERROR: Autoloaded symbol string-interpolate is not defined in the module gauche.interpolate
    While loading "../../libsrc/file/util.scm" at line 856
    While compiling "../../lib/gauche/cgen/unit.scm" at line 34: (define-module gauche.cgen.unit (use srfi-13) (use srfi-42) (use util.match) (use file.util) (use gau ...
    While loading "../../lib/gauche/cgen/unit.scm" at line 56
    While compiling "../../lib/gauche/cgen.scm" at line 43: (define-module gauche.cgen (extend gauche.cgen.unit gauche.cgen.literal gauche.cgen.type gauche.cgen. ...
    While loading "../../lib/gauche/cgen.scm" at line 46
    While compiling "../../lib/gauche/cgen/precomp.scm" at line 37: (define-module gauche.cgen.precomp (use srfi-1) (use srfi-13) (use gauche.cgen) (use gauche.cgen.stub ...
    While loading "../../lib/gauche/cgen/precomp.scm" at line 51
    While compiling "./../../src/precomp" at line 40: (use gauche.cgen.precomp)
    While loading "./../../src/precomp" at line 40
Stack Trace:
_______________________________________
make[2]: *** [Makefile:25: util--match.c] エラー 70
make[2]: ディレクトリ '/c/Gauche/Gauche/ext/util' から出ます
make[1]: *** [Makefile:37: util] エラー 2
make[1]: ディレクトリ '/c/Gauche/Gauche/ext' から出ます
make: *** [Makefile:40: all] エラー 1

TLSで接続できないWEBサーバが存在する (0.9.5)

hamayama(2016/10/29 14:44:21 UTC)(2016/10/31 22:03:42 UTC): https://syosetu.org/ に接続しようとすると以下のエラーが発生する件について調べました。 

(use rfc.http)
(http-get "syosetu.org" "/" :secure #t)
*** ERROR: TLS handshake failed: -40

これは、axTLS v2.0.1 がサポートする cipher suite と、WEBサーバがサポートする cipher suite に一致するものが存在しないためのようです。
axTLS v2.0.1 がサポートする cipher suite は、以下の4個になります。 

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)

一方、https://syosetu.org/ については、SSL Server Test ( https://www.ssllabs.com/ssltest/index.html ) のページで確認すると、
これらの cipher suite をサポートしていません。
このため、TLS の client hello メッセージに対して、SSL_ALERT_HANDSHAKE_FAILURE (40) が返って、エラーになります。

また、Gauche v0.9.4 の場合には、axTLS v1.4.9 を使用しており、サポートする cipher suite は、以下の4個になります。 

TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_RC4_128_SHA (0x5)
TLS_RSA_WITH_RC4_128_MD5 (0x4)

このうちの TLS_RSA_WITH_RC4_128_SHA (0x5) については、https://syosetu.org/ でもサポートしているため、通信が成功します。
ただし、RC4 は INSECURE とのことで、現在は使用が推奨されていないようです。

今後どうすればよいかですが。。。
基本的には、TLSのライブラリで、 

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)

のような新しいタイプの cipher suite がサポートされるのがよさそうではあります。
ECDHE は FS (Forward secrecy) という性質を持つ鍵交換プロトコルであり、GCM は 認証付き暗号モードとのことで、
実現が難しいかもしれませんが。。。

あとは、WEBサーバ側に、axTLS v2.0.1 の cipher suite を追加してもらうよう依頼することも考えられます。
ただし、多くのブラウザでは ECDHE 等が使用できるようなので、理由を聞かれるかもしれませんが。。。
(google.com, microsoft.com, www.apple.com 等、多くのサーバは axTLS v2.0.1 の cipher suite をサポートしているのですが。。。)

Topics
Sponsored Links
Search
Recent Changes
More ...
Last modified : 2019/02/09 06:06:18 UTC
WiLiKi 0.8.1 running on Gauche 0.9.7