[#17055] Set#map! vs. map — "David A. Black" <dblack@...>

Hi --

23 messages 2008/06/03

[#17084] Enumerable::Enumerator#with_memo — "Akinori MUSHA" <knu@...>

Hi,

36 messages 2008/06/03
[#17168] Re: Enumerable::Enumerator#with_memo — David Flanagan <david@...> 2008/06/09

Akinori MUSHA wrote:

[#17173] Re: Enumerable::Enumerator#with_memo — "Jeremy Kemper" <jeremy@...> 2008/06/10

On Mon, Jun 9, 2008 at 12:11 PM, David Flanagan <david@davidflanagan.com> wrote:

[#17192] Re: Enumerable::Enumerator#with_memo — "Martin DeMello" <martindemello@...> 2008/06/10

On Mon, Jun 9, 2008 at 10:57 PM, Jeremy Kemper <jeremy@bitsweat.net> wrote:

[#17162] Release Plan: Ruby 1.9.0-2 — SASADA Koichi <ko1@...>

Hi,

44 messages 2008/06/09
[#17254] Re: Release Plan: Ruby 1.9.0-2 — SASADA Koichi <ko1@...> 2008/06/15

Hi,

[#17273] Re: Release Plan: Ruby 1.9.0-2 — Ryan Davis <ryand-ruby@...> 2008/06/16

[#17276] Re: Release Plan: Ruby 1.9.0-2 — Kouhei Sutou <kou@...> 2008/06/16

Hi,

[#17312] Re: Release Plan: Ruby 1.9.0-2 — Ryan Davis <ryand-ruby@...> 2008/06/18

[#17346] Re: Release Plan: Ruby 1.9.0-2 — Kouhei Sutou <kou@...> 2008/06/19

Hi,

[#17167] Mail count in Subject — "Dirk Traulsen" <dirk.traulsen@...>

Hi!

20 messages 2008/06/09
[#17169] Re: Mail count in Subject — "Warren Brown" <warrenb@...> 2008/06/09

All,

[#17171] Re: Mail count in Subject — Urabe Shyouhei <shyouhei@...> 2008/06/10

Warren Brown wrote:

[#17327] A plea for a release process — Brian Ford <brixen@...>

Hi all,

15 messages 2008/06/18

[#17377] Re: Ruby 1.9.0/1.8.7/1.8.6/1.8.5 new releases (Security Fix) — "Bill Kelly" <billk@...>

Hi,

12 messages 2008/06/23

[#17393] URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — "Igal Koshevoy" <igal@...>

All currently available versions of MRI Ruby are either vulnerable to

104 messages 2008/06/24
[#17416] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Urabe Shyouhei <shyouhei@...> 2008/06/28

Sorry for a late reply but I think I've fixed this issue. Can someone

[#17417] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/28

Urabe Shyouhei wrote:

[#17419] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Urabe Shyouhei <shyouhei@...> 2008/06/28

Igal Koshevoy wrote:

[#17422] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/29

Urabe Shyouhei wrote:

[#17426] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Urabe Shyouhei <shyouhei@...> 2008/06/29

Igal Koshevoy wrote:

[#17438] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/29

Urabe Shyouhei wrote:

[#17499] We'll release 1.8.6/1.8.7 this Friday — Urabe Shyouhei <shyouhei@...> 2008/07/02

Hello, I think current 1.8.6/1.8.7 is stable than p230/p22, so I decided

[#17504] Re: We'll release 1.8.6/1.8.7 this Friday — "Vladimir Sizikov" <vsizikov@...> 2008/07/02

Hi Urabe,

[#17506] Re: We'll release 1.8.6/1.8.7 this Friday — Charles Oliver Nutter <charles.nutter@...> 2008/07/02

Vladimir Sizikov wrote:

[#17521] Re: We'll release 1.8.6/1.8.7 this Friday — Urabe Shyouhei <shyouhei@...> 2008/07/03

Charles Oliver Nutter wrote:

[#17544] Re: We'll release 1.8.6/1.8.7 this Friday — Igal Koshevoy <igal@...> 2008/07/03

Urabe Shyouhei wrote:

[#17545] Re: We'll release 1.8.6/1.8.7 this Friday — Charles Oliver Nutter <charles.nutter@...> 2008/07/03

Igal Koshevoy wrote:

[#17806] Re: We'll release 1.8.6/1.8.7 this Friday — "Michal Suchanek" <hramrach@...> 2008/07/16

On 02/07/2008, Charles Oliver Nutter <charles.nutter@sun.com> wrote:

[#17851] Re: We'll release 1.8.6/1.8.7 this Friday — Tanaka Akira <akr@...> 2008/07/19

In article <a5d587fb0807160533r4534fabdg257b4a9523b15f1e@mail.gmail.com>,

[#17852] Re: We'll release 1.8.6/1.8.7 this Friday — Federico Builes <federico.builes@...> 2008/07/19

[#17855] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/19

On Sat, Jul 19, 2008 at 02:18:05PM +0900, Federico Builes wrote:

[#17857] Re: We'll release 1.8.6/1.8.7 this Friday — Federico Builes <federico.builes@...> 2008/07/19

[#17860] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/19

On Sun, Jul 20, 2008 at 12:43:46AM +0900, Federico Builes wrote:

[#17939] Re: We'll release 1.8.6/1.8.7 this Friday — Kurt Stephens <ks@...> 2008/07/24

When will we see a new 1.8.6 release?

[#17940] Re: We'll release 1.8.6/1.8.7 this Friday — Nobuyoshi Nakada <nobu@...> 2008/07/24

Hi,

[#17941] Re: We'll release 1.8.6/1.8.7 this Friday — "Vladimir Sizikov" <vsizikov@...> 2008/07/24

Hi,

[#17945] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/24

On Fri, Jul 25, 2008 at 02:04:15AM +0900, Vladimir Sizikov wrote:

[#17946] Re: We'll release 1.8.6/1.8.7 this Friday — Jeremy Henty <onepoint@...> 2008/07/24

On Fri, Jul 25, 2008 at 04:35:43AM +0900, Jeremy Henty wrote:

[#17947] Re: We'll release 1.8.6/1.8.7 this Friday — Federico Builes <federico.builes@...> 2008/07/24

Jeremy,

[#17948] Re: We'll release 1.8.6/1.8.7 this Friday — Nobuyoshi Nakada <nobu@...> 2008/07/25

Hi,

[#17953] Re: We'll release 1.8.6/1.8.7 this Friday — "Daniel Luz" <dev@...> 2008/07/25

On Thu, Jul 24, 2008 at 9:19 PM, Nobuyoshi Nakada <nobu@ruby-lang.org>

[#17423] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Tanaka Akira <akr@...> 2008/06/29

In article <48662E99.7030508@pragmaticraft.com>,

[#17424] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Federico Builes <federico.builes@...> 2008/06/29

[#17429] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — Igal Koshevoy <igal@...> 2008/06/29

Federico Builes wrote:

[#17431] Re: URGENT: Possible fixes for segfaults and vulnerabilities available for review in ruby-talk — "M. Edward (Ed) Borasky" <znmeb@...> 2008/06/29

Igal Koshevoy wrote:

[#17427] 1.8 release management — Yukihiro Matsumoto <matz@...>

Hi,

43 messages 2008/06/29
[#17455] Re: 1.8 release management — Stephen Bannasch <stephen.bannasch@...> 2008/06/30

Let me describe some simple questions about Ruby 1.8.6 that are not

[#17458] Re: 1.8 release management — Urabe Shyouhei <shyouhei@...> 2008/06/30

For what I know,

[#17547] Re: 1.8 release management — "Wilson Bilkovich" <wilsonb@...> 2008/07/03

On 6/30/08, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#17549] Re: 1.8 release management — Igal Koshevoy <igal@...> 2008/07/03

Wilson Bilkovich wrote:

[#17555] Re: 1.8 release management — "Luis Lavena" <luislavena@...> 2008/07/03

On Thu, Jul 3, 2008 at 4:41 PM, Igal Koshevoy <igal@pragmaticraft.com> wrote:

[#17585] Re: 1.8 release management — Urabe Shyouhei <shyouhei@...> 2008/07/04

Luis Lavena wrote:

[#17588] Re: 1.8 release management — Igal Koshevoy <igal@...> 2008/07/04

Urabe Shyouhei wrote:

[#17589] Re: 1.8 release management — Urabe Shyouhei <shyouhei@...> 2008/07/04

Igal Koshevoy wrote:

[#17591] Re: 1.8 release management — Igal Koshevoy <igal@...> 2008/07/04

Urabe Shyouhei wrote:

[#17593] Re: 1.8 release management — "Vladimir Sizikov" <vsizikov@...> 2008/07/04

Hi,

[ruby-core:17220] VM::InstructionSequence to_a->load->to_a != to_a

From: Adam Strzelecki <ono@...>
Date: 2008-06-11 15:43:10 UTC
List: ruby-core #17220
Hello,

There's apparently a bug in VM::InstructionSequence.load code, coz  
code generated with to_a, loaded back and again to_a is not the same  
as one emitted just with to_a.
Of course label names differ, but also local_size and args_size are  
different for blocks (instructions seems to be OK).

After my initial enthusiasm, I realised that  
VM::InstructionSequence.load doesn't work as it should at all.  
Actually it is not possible to call any function/method with argument  
with current code.

Here's sample test showing the differences:

-----------------------------------------------------
#!/usr/bin/env ruby-1.9
require 'zlib'

code = VM::InstructionSequence.compile_file 'test.rb'

STDOUT.puts code.to_a.inspect.gsub(/, \[/, ",\n\t[")
code = VM::InstructionSequence.load code.to_a

STDERR.puts code.to_a.inspect.gsub(/, \[/, ",\n\t[")
-----------------------------------------------------


I've compared STDOUT & STDERR using samples/test.rb & I got plenty of  
local_size differences like:
-	["YARV", 1, 1, 1, {:arg_size=>1, :local_size=>2, :stack_max=>2},  
"block in <main>", "test.rb", :block,
+	["YARV", 1, 1, 1, {:arg_size=>1, :local_size=>1, :stack_max=>2},  
"block in <main>", "test.rb", :block,

It seems that iseq_build_from_ary @ compile.c is broken, I'm not sure  
about to_a.

I've did some fixes (diff below):

1) Regardless of iseq->type it seems that local_size is always  
local_table_size + 1, also in original code opt (=1) is added twice to  
local_size (= local_table_size = opt + RARRAY_LEN(locals))
2) It should be iseq->arg_opts = RARRAY_LEN(arg_opt_labels)

With those fixes I've managed to limit the differences of to_a->load- 
 >to_a != to_a, but still those are not the same. Also I've managed to  
call methods with args from restored with VM::InstructionSequence.load  
code, but it seems it does works weird (slow + hungs).

Best regards,
-- 
Adam

Index: compile.c
===================================================================
--- compile.c	(revision 17097)
+++ compile.c	(working copy)
@@ -4983,22 +4983,16 @@
  		    VALUE exception, VALUE body)
  {
      int i;
-    int opt = 0;
      ID *tbl;
      struct st_table *labels_table = st_init_numtable();

      DECL_ANCHOR(anchor);

      INIT_ANCHOR(anchor);
-    if (iseq->type == ISEQ_TYPE_METHOD ||
-	iseq->type == ISEQ_TYPE_TOP ||
-	iseq->type == ISEQ_TYPE_CLASS) {
-	opt = 1;
-    }

-    iseq->local_table_size = opt + RARRAY_LEN(locals);
+    iseq->local_table_size = RARRAY_LEN(locals);
      iseq->local_table = tbl = (ID *)ALLOC_N(ID *, iseq- 
 >local_table_size);
-    iseq->local_size = opt + iseq->local_table_size;
+    iseq->local_size = 1 + iseq->local_table_size;

      for (i=0; i<RARRAY_LEN(locals); i++) {
  	VALUE lv = RARRAY_PTR(locals)[i];
@@ -5025,7 +5019,8 @@
  	iseq->arg_post_len = FIX2INT(arg_post_len);
  	iseq->arg_post_start = FIX2INT(arg_post_start);
  	iseq->arg_block = FIX2INT(arg_block);
-	iseq->arg_opt_table = (VALUE *)ALLOC_N(VALUE,  
RARRAY_LEN(arg_opt_labels));
+        iseq->arg_opts = RARRAY_LEN(arg_opt_labels);
+	iseq->arg_opt_table = (VALUE *)ALLOC_N(VALUE, iseq->arg_opts);

  	if (iseq->arg_block != -1) {
  	    iseq->arg_size = iseq->arg_block + 1;
@@ -5037,7 +5032,7 @@
  	    iseq->arg_size = iseq->arg_rest + 1;
  	}
  	else {
-	    iseq->arg_size = iseq->argc + iseq->arg_opts;
+	    iseq->arg_size = iseq->argc + (iseq->arg_opts ? iseq->arg_opts -  
1 : 0);
  	}

  	for (i=0; i<RARRAY_LEN(arg_opt_labels); i++) {


In This Thread

Prev Next