Gauche:Bugs

Gauche:Bugs

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

reset/shift と call/cc の組み合わせで SEGV (0.9.8)

hamayama(2019/09/07 08:01:16 UTC): どうも自分には直せないみたいなので、まずは挙げておきます。 

(use gauche.partcont)
(define k1 #f)
(define k2 #f)
(define (f1) (call/cc (^[k] (set! k1 k)))
             (shift k (set! k2 k))
             (display "[f01]"))
(define (f2) (display "[f02]"))
(reset (f1) (f2))
(reset (k1))

発生条件があります。
(1) (reset (f1)) として、(f1) を末尾呼び出しにしたとき ((f2) を消したとき) は、
SEGV にはならず、以下のエラーが出る。
「*** ERROR: attempt to return from a ghost continuation.」 ... (A)
(2) (shift k (set! k2 k)) を消すと、SEGV にはならず、エラー (A) が出る。
(3) (k1) を reset で囲わなければ、SEGV にはならず、REPL が終了する。
(4) (reset (reset (f1) (f2))) のように reset でもう一段囲うと、SEGV にはならない。
→ (k1) の reset より段数が多ければ大丈夫なよう。。。

(1)-(4) は、仕様の範囲内かと思うのですが、上の例ではそれらのチェックをすり抜けている感じです。

hamayama(2019/09/14 05:21:55 UTC): 以下で対策を行いました。
https://github.com/shirok/Gauche/pull/518

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

hamayama(2019/06/09 03:09:07 UTC): インストールと簡単な動作確認を実施しました。
Windows 8.1 (64bit) : 64bit 版と 32bit 版のインストーラでインストール OK
Windows XP SP3 : 32bit 版のインストーラでインストール OK です。

tls のテストに失敗する (0.9.8_rc1)

hamayama(2019/06/07 11:36:54 UTC): 以下の件です。
https://twitter.com/SaitoAtsushi/status/1136905446285930497
https://gist.github.com/SaitoAtsushi/46f53e03331c0723e057753b6850ff5d

どうもこちらで再現しないため、いくつか確認したい点があります。

(1) openssl.exe をサーバモードで起動できるか 

cd /c/work/Gauche/ext/tls/axTLS/ssl/test
openssl s_server -cipher DEFAULT@SECLEVEL=1 -accept 19002 -quiet -cert axTLS.x509_1024.pem -key axTLS.key_1024.pem

のようにして、openssl.exe をサーバモードで起動します。
別の画面を開いて、 

netstat -a -n | grep 19002

のようにして、サーバ が ポート 19002 で LISTEN できているかを確認します。
(例えば、ウィルス対策ソフトがブロックしている等があるかもしれない。。。)

(2) openssl.exe の種類
where openssl で、どの openssl.exe が使用されているかを確認します。
MinGW の openssl.exe については、
https://github.com/shirok/Gauche/pull/468 で、
MinGW の openssl.exe が固まらないように、winpty をかませるようにしました。
この対策が悪さをしている可能性もあります。
例えば、MinGW の openssl.exe をリネームして使えないようにして、
MSYS2 の openssl.exe を使うようにしたら、成功するでしょうか。

齊藤 (2019/06/08 00:58:24 UTC):

hamayama(2019/06/08 01:13:28 UTC): 回答ありがとうございます。
これは、where openssl で openssl.exe のリストを取得して、
Msys のものを優先的に起動する (kick_openssl.sh 内でフルパスで指定する)
方がよさそうですね。。。ちょっと検討してみます。

hamayama(2019/06/08 04:36:31 UTC): うーむ、Msys のものを使うようにしたら、逆にエラーが出るようになってしまった。。。
( could not start socket on 19002 )

hamayama(2019/06/08 04:50:42 UTC): ssltest.c の以下のところで fd < 0 をチェックしてエラーにしているのですが、
https://github.com/shirok/Gauche/blob/a085214948c1f9b737a37a1a503e8170b2d0bd28/ext/tls/axTLS/ssl/test/ssltest.c#L1678
どうも winsock の SOCKET は unsigned で、INVALID_SOCKET 以外の値は正常値なもよう。。。
https://docs.microsoft.com/en-us/windows/desktop/winsock/socket-data-type-2

hamayama(2019/06/09 03:09:07 UTC): 以下で修正してみました(発生の頻度の違いがちょっと気になりますが。。。)。
https://github.com/shirok/Gauche/pull/479

齊藤 (2019/06/09 15:30:49 UTC): 私の手元ではその変更を適用して (コンパイルは ./DIST gen からやり直してます) も rfc.tls は failed になってしまいました。
ところで気になるのは、 ssltest.log に残される invalid digest とか Unsupported digest とかいった形のエラーになって現れるのはどういう理屈か判明しているのでしょうか？
パイプやソケットの接続の都合で固まってしまったり入出力のエラーになるというのなら話はわかるのですが、ハッシュが違うことを表す (んですよね？) メッセージを私は理解できていません。

Shiro(2019/06/09 18:42:14 UTC): このメッセージなら想定内です。これは無効な証明書が含まれたバンドルを読むテストで、無効な証明書に出会うとこのメッセージが出力されますが、有効な証明書がひとつあればokというテストなので。 

invalid digest: 2a 86 48 ce 38 04 03 
Error: Invalid X509 ASN.1 file (Unsupported digest)
invalid digest: 2a 86 48 ce 3d 04 03 03 
Error: Invalid X509 ASN.1 file (Unsupported digest)
All Certificate tests passed

hamayama(2019/06/09 20:26:08 UTC): 参考用に成功時の ssltest.log を以下のページに生成してみました (AppVeyor) 。
https://ci.appveyor.com/project/Hamayama/gauche/builds/25153825/job/bkv3n51i42vv0d2a/artifacts
(1) エラーの内容は変わらず ( could not start socket on 19002 ) でしょうか。
(2) 念のため、以下のファイルの状況 (内容、日付が更新されているか) を確認してほしい。
ext/tls/axTLS/ssl/test/ssltest.c (ソース)
ext/tls/axTLS/ssl/test/ssltest.mod.c (ソースを自動変換したもの)
ext/tls/axTLS/ssl/test/ssltest.mod.o (オブジェクト)
ext/tls/axTLS/ssl/ssltest.exe (実行ファイル)
ext/tls/ssltest.log (ログ)
(3) Msys の openssl.exe だと、相変わらず成功するでしょうか。
(全テスト実行しなくても cd ext/tls → make check で確認できると思います)
(4) winpty --version でバージョンが知りたい (こちらは 0.4.3)。

齊藤(2019/06/10 01:52:44 UTC):

  1. エラーの内容は could not start socket on 19002 です。
  2. 各種ファイルは更新されています。
  3. Msys の openssl.exe であれば成功します。
  4. winpty はインストールしていませんでした。

つまらないことにお手数をおかけしてすいません。
winpty が必要というのはドキュメントに書いてあるのを見落としていました。
ただ、エラーメッセージを工夫する余地はあるかもしれません。

Shiro(2019/06/10 03:59:37 UTC): winptyを入れたら通りました? それならconfigureで チェックして無かったらメッセージ出してテストスキップでいいかな?

齊藤(2019/06/10 04:53:14 UTC): はい。 winpty を入れたら passed になりました。

hamayama(2019/06/17 14:26:09 UTC): #480 #481 #482 で、winpty が見付からないときはメッセージを出すようにしました。

Invalid formal parameter (926e29f)

このようなコードを実行するとエラーになります。 

(import (scheme base)
        (scheme write))

(define-syntax apply-values
  (syntax-rules ()
    ((_ f e)
     (call-with-values (lambda() e)
       (lambda lst (apply f lst))))))

(display (apply-values list (values 1 2 3)))

エラーの内容は 

*** ERROR: Invalid formal parameter: #<identifier r7rs.user#lst.31b4430>
    While compiling "./test.scm" at line 10: (display (apply-values list (values 1 2 3)))
    While loading "./test.scm" at line 10
Stack Trace:
_______________________________________

です。

import に (gauche base) を追加する、またはマクロを使わない形で 

(display
 (call-with-values (lambda() (values 1 2 3))
   (lambda lst (apply list lst))))

とすると問題なく動作するようです。

MinGW-w64 (32bit) 環境で srfi-144 (flonum) のテストエラー (0.9.8_pre1)

hamayama(2019/04/16 10:23:14 UTC): テスト結果は以下になります。64bit 環境では発生しません。
https://ci.appveyor.com/project/Hamayama/gauche/builds/23869905/job/cr3gkpm8ua5yh7t9#L1808 

Testing extension srfi modules ...                               failed.
discrepancies found.  Errors are:
test (flsign-bit negzero): expects 1 => got 512
test (flsign-bit (flonum -2)): expects 1 => got 512
test (flsign-bit neginf): expects 1 => got 512
test (flnormalized? fl-least): expects #f => got #t
test (fldenormalized? fl-least): expects #t => got #f

最初の3件については、C の signbit が負のときに非0を返すとのことなので、直せそうです。

後の2件については、MinGW-w64 (32bit) 環境 の fpclassify のバグのようで、
ちょっとよい対応方法が思いつきませんでした。
(fxam と fstsw という 8087 の 80bit用の命令が使われていて、
小さい数が FP_NORMAL と判定されてしまうようです。。。)

＜参考URL＞
https://stackoverflow.com/questions/31714128/why-is-isnormal-saying-a-value-is-normal-when-it-isnt/31715338#answer-31715338
https://sourceforge.net/p/mingw-w64/bugs/367/

hamayama(2019/04/17 10:05:52 UTC): 本件は修正済みです。

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/09/14 05:21:55 UTC
WiLiKi 0.8.1 running on Gauche 0.9.8