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
> 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;
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>
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.
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
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.
>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.