[#25035] 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...>

こんにちは。

16 messages 2004/12/03
[#25070] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — nobu@... 2004/12/06

なかだです。

[#25071] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...> 2004/12/06

In message <200412060607.iB667giF007533@sharui.nakada.niregi.kanuma.tochigi.jp>

[#25089] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — nobu@... 2004/12/07

なかだです。

[#25090] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...> 2004/12/07

In message <200412070015.iB70FAiF012770@sharui.nakada.niregi.kanuma.tochigi.jp>

[#25093] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — akira yamada / やまだあきら <akira@...> 2004/12/07

2004-12-07 (火) の 12:27 +0900 に Takahiro Kambe さんは書きました:

[#25041] temporal locking already locked string on simultaneous write — Tanaka Akira <akr@...17n.org>

同じ文字列をほぼ同時に IO に書き込むと、temporal locking already

13 messages 2004/12/04
[#25042] Re: temporal locking already locked string on simultaneous write — Yukihiro Matsumoto <matz@...> 2004/12/04

まつもと ゆきひろです

[#25043] Re: temporal locking already locked string on simultaneous write — Tanaka Akira <akr@...17n.org> 2004/12/04

In article <1102133507.339625.10453.nullmailer@x31.priv.netlab.jp>,

[#25096] double free problem — "Akinori MUSHA" <knu@...>

 ご無沙汰しております。

15 messages 2004/12/07
[#25099] Re: double free problem — Yukihiro Matsumoto <matz@...> 2004/12/07

Hi,

[#25101] non-stdio buffering — Tanaka Akira <akr@...17n.org>

えぇと、今回 1.9 でなにが起きたのかを私が把握している範囲でまとめてお

18 messages 2004/12/07

[#25152] 1.8 reopen problem with duplex popen — Tanaka Akira <akr@...17n.org>

次のように、1.8 で双方向 popen な IO を reopen するとエラーになること

11 messages 2004/12/10

[#25158] core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org>

NetBSD 2.0 で次のようにすると core を吐きます。

18 messages 2004/12/11
[#25159] Re: core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org> 2004/12/11

In article <87hdmsivva.fsf@serein.a02.aist.go.jp>,

[#25163] Re: core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org> 2004/12/12

In article <87ekhwiv7g.fsf@serein.a02.aist.go.jp>,

[#25165] Re: core dump on NetBSD 2.0 — nobu@... 2004/12/13

なかだです。

[#25167] Re: core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org> 2004/12/13

In article <200412130040.iBD0e8Qh003275@sharui.nakada.niregi.kanuma.tochigi.jp>,

[#25193] 1.8.2 release schedule — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

15 messages 2004/12/14

[#25299] Re: リリース準備 — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

20 messages 2004/12/24
[#25301] Re: リリース準備 — TAKAHASHI Masayoshi <maki@...> 2004/12/24

高橋征義です。

[#25302] test_readline.rb blocks on BSD again — GOTOU Yuuzou <gotoyuzo@...>

In message <20041223175402.3116FC6718@lithium.ruby-lang.org>,

15 messages 2004/12/24
[#25314] Re: test_readline.rb blocks on BSD again — GOTOU Yuuzou <gotoyuzo@...> 2004/12/24

In message <20041224.131211.846943951.gotoyuzo@sawara.does.notwork.org>,

[#25315] Re: test_readline.rb blocks on BSD again — Yukihiro Matsumoto <matz@...> 2004/12/24

まつもと ゆきひろです

[#25317] Re: test_readline.rb blocks on BSD again — WATANABE Hirofumi <eban@...> 2004/12/25

わたなべです。

[ruby-dev:25356] Re: 1.9.0でbcc版がコンパイルできない

From: "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
Date: 2004-12-27 10:14:36 UTC
List: ruby-dev #25356
山本です。

>問題を最小限にしてみると、
># sample.rb --------------------------------------------------
>until false
>end
>#-------------------------------------------------------------
>で
>C:\>miniruby.exe sample.rb
>で、再現できました。until,while構文の解析でこけているみたいです。

どうも__int64周りのコンパイラのバグのようです。デバッガでトレースしたところ

parse.c 6759: {COND_POP();;}

  mov eax,[ebp+0x08]
  mov edx,[eax+0x2c]
  mov eax,[eax+0x28] # eax にアドレス eax+0x28 の数値(64bit整数の下位32bit)を読み込む
  shrd eax,edx,0x01  # eax に格納された数値に対しシフト演算
  shr edx,1
  mov [eax+0x2c],edx # 落ちる。eax がアドレスを指していないため
  mov [eax+0x28],eax

となり、落ちました。落ちる行の前に

  mov eax,[ebp+0x08]

が必要なはずですが、そうなっていません。

落ちないようにする方法としては、

Index: parse.y
===================================================================
RCS file: /src/ruby/parse.y,v
retrieving revision 1.364
diff -u -w -b -p -r1.364 parse.y
--- parse.y	20 Dec 2004 01:52:06 -0000	1.364
+++ parse.y	27 Dec 2004 07:12:57 -0000
@@ -66,11 +66,7 @@ enum lex_state_e {
     EXPR_TERNARY,		/* alike EXPR_BEG but immediate after ternary op. */
 };
 
-# ifdef HAVE_LONG_LONG
-typedef unsigned LONG_LONG stack_type;
-# else
 typedef unsigned long stack_type;
-# endif
 
 # define BITSTACK_PUSH(stack, n)	(stack = (stack<<1)|((n)&1))
 # define BITSTACK_POP(stack)	(stack >>= 1)

として stack_type に unsigned long を使うか、(普通は unsigned __int64 を使う)

Index: parse.y
===================================================================
RCS file: /src/ruby/parse.y,v
retrieving revision 1.364
diff -u -w -b -p -r1.364 parse.y
--- parse.y	20 Dec 2004 01:52:06 -0000	1.364
+++ parse.y	27 Dec 2004 07:13:44 -0000
@@ -73,7 +73,7 @@ typedef unsigned long stack_type;
 # endif
 
 # define BITSTACK_PUSH(stack, n)	(stack = (stack<<1)|((n)&1))
-# define BITSTACK_POP(stack)	(stack >>= 1)
+# define BITSTACK_POP(stack)	(stack = stack >> 1)
 # define BITSTACK_LEXPOP(stack)	(stack = (stack >> 1) | (stack & 1))
 # define BITSTACK_SET_P(stack)	(stack&1)

とすると、落ちなくなります。

/////////////////////////////////////

より単純なコードでも落とせます。ただし、これは bcc32 に -Od をつけないと落ちません。(bcc32 -v -Od)

#include <stdio.h>

struct hoge
{
    unsigned __int64 value;
};

void test(void)
{
        struct hoge a;
        
        struct hoge *p = &a;
        
        p->value = 0;

        p->value = (p->value<<1)|(1);

        p->value >>= 1; /* 落ちる */
}

int main()
{
        /* hook for debuging */
        puts("press enter");
        getc(stdin);

        test();
}

落ちる部分の生成コードは

  mov eax,[ebp-0x0c]
  mov edx,[eax+0x04]
  mov eax,[eax]
  shrd eax,edx,0x01
  shr edx,1
  mov [eax+0x04],edx # 落ちる
  mov [eax],eax

です。

ポインタを介さず、a.value を p->value の代わりに使うと、落ちなくなります。
(ruby_1_8 が落ちないのはこのあたりに理由が?)

  mov eax,[ebp-0x08]
  mov edx,[ebp-0x04]
  shrd eax,edx,0x01
  shr edx,1
  mov [ebp-0x04],edx
  mov [ebp-0x08],eax

また、 p->value = (p->value<<1)|(1); を削除しても落ちなくなります。

  mov ecx,[ebp-0x0c]
  mov eax,[ecx]
  mov edx,[ecx+0x04]
  shrd eax,edx,0x01
  shr edx,1
  mov [ecx+0x04],edx
  mov [ecx],eax

bcc32 -v でも落ちなくなります。(単純なコードだと最適化される?)

  mov eax,[ecx]
  mov edx,[ecx+0x04]
  shrd eax,edx,0x01
  shr edx,1
  mov [ecx+0x04],edx
  mov [ecx],eax

bcc32のunsigned __int64には他にもこんなバグ
(http://www.web-one.org/new-5015457-4898.html)があるみたいです。
使わないほうがいいのかもしれません。

/////////////////////

余談ですが、parse.c の #line を削除しないとトレースがおかしくなるのに
はまりました。



In This Thread