[#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

Re: question about frame_unique

From: "Meinrad Recheis" <meinrad.recheis@...>
Date: 2007-05-01 15:45:57 UTC
List: ruby-core #11068
On 5/1/07, Paul Brannan <pbrannan@atdesk.com> wrote:
>
> 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


the question is: what does this mean for long running applications in ruby?

In This Thread

Prev Next