Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Segfault with map operation on 1.8p5

0 views
Skip to first unread message

Daniel Berger

unread,
Jul 30, 2003, 10:41:33 PM7/30/03
to
Hi all,

The following snippet is a silly thing to do, but I
thought it might be worth mentioning. It segfaults on
1.8p5, but not 1.6.x:

a = [1,2,3,4]
h = {}
a.map{ |e| h[e] = a.shift }

Suse Linux 8.0, btw.

Regards,

Dan

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

K.Sasada

unread,
Jul 30, 2003, 11:52:54 PM7/30/03
to

[ Segfault with map operation on 1.8p5 ]
Thu, 31 Jul 2003 11:41:33 +0900

> The following snippet is a silly thing to do, but I
> thought it might be worth mentioning. It segfaults on
> 1.8p5, but not 1.6.x:
>
> a = [1,2,3,4]
> h = {}
> a.map{ |e| h[e] = a.shift }


This problem is solved by following patch for ruby 1.8.0 p5.


regards,
--
// SASADA Koichi @ namikilab.tuat.ac.jp
//
// Thanks to unak :)


--- array.c.org Thu Jul 31 03:20:06 2003
+++ array.c Thu Jul 31 03:29:54 2003
@@ -1197,9 +1197,8 @@ rb_ary_collect(ary)
return rb_ary_new4(RARRAY(ary)->len, RARRAY(ary)->ptr);
}

- len = RARRAY(ary)->len;
collect = rb_ary_new2(len);
- for (i=0; i<len; i++) {
+ for (i=0; i<RARRAY(ary)->len; i++) {
rb_ary_push(collect, rb_yield(RARRAY(ary)->ptr[i]));
}
return collect;


U.Nakamura

unread,
Jul 31, 2003, 12:04:23 AM7/31/03
to
Hello,

In message "Re: Segfault with map operation on 1.8p5"


on Jul.31,2003 12:52:54, <k...@namikilab.tuat.ac.jp> wrote:
| This problem is solved by following patch for ruby 1.8.0 p5.

Hmmm, this?

--- array.c 25 Jul 2003 05:36:46 -0000 1.128
+++ array.c 31 Jul 2003 04:03:48 -0000
@@ -1192,3 +1192,3 @@ rb_ary_collect(ary)
{
- long len, i;
+ long i;
VALUE collect;
@@ -1199,5 +1199,4 @@ rb_ary_collect(ary)



- len = RARRAY(ary)->len;

- collect = rb_ary_new2(len);


- for (i=0; i<len; i++) {

+ collect = rb_ary_new();
+ for (i = 0; i < RARRAY(ary)->len; i++) {


rb_ary_push(collect, rb_yield(RARRAY(ary)->ptr[i]));

Regards,
--
U.Nakamura <u...@osb.att.ne.jp>

Yukihiro Matsumoto

unread,
Jul 31, 2003, 2:23:21 AM7/31/03
to
Hello,

In message "Re: Segfault with map operation on 1.8p5"

on 03/07/31, "U.Nakamura" <u...@osb.att.ne.jp> writes:

|In message "Re: Segfault with map operation on 1.8p5"
| on Jul.31,2003 12:52:54, <k...@namikilab.tuat.ac.jp> wrote:
|| This problem is solved by following patch for ruby 1.8.0 p5.
|
|Hmmm, this?

Thank you guys for finding and fixing a bug.
Usa, could you commit this fix to the CVS?

matz.

Michal Rokos

unread,
Jul 31, 2003, 1:01:14 PM7/31/03
to
Hello,

while reading the discussion about segfault in Array#map comes to my
mind that this couldn't be so rare segfault...

Please look at suspicious peaces of code. To name it - look at line 261,
and 1570 (in latest CVS). There are potencial segfaults.

While 841 is not a segfault, but could give a garbage like Qundef.

And 1438 could give Qnil...

I think that some king of locking needs to be used (like ARY_TMPLOCK).

I think that the other classes (not just Array) are affected like this
as well.

I hope I'm wrong so correct me, please!

Michal


PS: I'm so sorry that I won't be able to respond back - I'm out of town
for a week... So please, CC me to stay in discussion.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Michal Rokos Czech Technical University, Prague
e-mail: m.r...@sh.cvut.cz icq: 36118339 jabber: ma...@jabber.cz
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Yukihiro Matsumoto

unread,
Jul 31, 2003, 9:26:28 PM7/31/03
to
Hi,

In message "Re: Segfault with map operation on 1.8p5"

on 03/08/01, Michal Rokos <m.r...@sh.cvut.cz> writes:

|Please look at suspicious peaces of code. To name it - look at line 261,
|and 1570 (in latest CVS). There are potencial segfaults.

line 261 will not be a problem. It's in the "initialize" so that the
ary is not yet revealed to the script.

|While 841 is not a segfault, but could give a garbage like Qundef.
|
|And 1438 could give Qnil...

I fixed problems at lines 841, 1438, and 1570, by checking length for
each iteration.

|I think that the other classes (not just Array) are affected like this
|as well.

Yep, I'm going to check. Thank you.

matz.

Daniel Berger

unread,
Aug 1, 2003, 12:40:27 AM8/1/03
to
>Hello,

>while reading the discussion about segfault in
>Array#map comes to my
>mind that this couldn't be so rare segfault...

>Please look at suspicious peaces of code. To name it


- >look at line 261,
>and 1570 (in latest CVS). There are potencial
>segfaults.

>While 841 is not a segfault, but could give a garbage
>like Qundef.

>And 1438 could give Qnil...

>I think that some king of locking needs to be used
>(like ARY_TMPLOCK).

>I think that the other classes (not just Array) are


>affected like this
>as well.

>I hope I'm wrong so correct me, please!

> Michal

Michal,

I think that in general you are correct. Any
operation where the array alters its own length
midstream, while probably not a good idea in general,
could cause unexpected results.

Using reverse_each() as an example (the method you
metnion with line 841), consider the following code
snippet:

a = [1,2,3,4]
a.reverse_each{ |e| puts e; a.shift }

This results in 4,4,4,4 and returns an empty array
where I think it ought to still return 4,3,2,1 (though
still return an empty array).

I dunno how serious this is in general. I couldn't
cause the other methods you mention to segfault, and
odds are only people like me who are intentionally
doing screwy things in their spare time on irb would
even notice there was a problem in the first place.

It's certainly worth reviewing the code for this in
general, though. I should note that my own attempts
to *fix* this code resulted in segfaults or code that
just didn't work right. :(

Anyway, my .02.

0 new messages