[#11073] segfault printing instruction sequence for iterator — <noreply@...>

Bugs item #10527, was opened at 2007-05-02 14:42

14 messages 2007/05/02
[#11142] Re: [ ruby-Bugs-10527 ] segfault printing instruction sequence for iterator — Nobuyoshi Nakada <nobu@...> 2007/05/10

Hi,

[#11188] Re: [ ruby-Bugs-10527 ] segfault printing instruction sequence for iterator — Paul Brannan <pbrannan@...> 2007/05/16

On Thu, May 10, 2007 at 04:51:18PM +0900, Nobuyoshi Nakada wrote:

[#11234] Planning to release 1.8.6 errata — Urabe Shyouhei <shyouhei@...>

Hi all.

17 messages 2007/05/25

question about frame_unique

From: Paul Brannan <pbrannan@...>
Date: 2007-05-01 12:36:51 UTC
List: ruby-core #11066
I was reading the source code for ruby 1.8.6, and a thought occurrred to
me.  Consider:

- Assume we're running on a 32-bit system that has a limit of 2**32-1
  for unsigned long.
- frame_unique starts at 0.  Assume some amount of work has been done
  and it reaches some number, say 20.
- The script makes 2**32-1 method invocations and pushes and pops
  2**32-1 frames.
- frame_unique is incremented 2**32-1 times.  Its value should now be
  19.
- On the next method invocation, when the frame is pushed, frame_unique
  will be incremented to 20, and the next frame's uniq value will be the
  same as the previous frame's.  Ruby can now no longer distinguish
  between the two frames, even though they are distinct frames.

I don't know what the implications are of this, so I don't have a test
case.  It's seems though that in a very long running ruby script that
this could be a real problem.  I don't see any simple way around it,
though.

A similar problem exists with block_unique.

Paul


In This Thread

Prev Next