[#3419] Valgrind analysis of [BUG] unknown node type 0 — Andrew Walrond <andrew@...>

Hello list,

19 messages 2004/09/17
[#3422] Re: Valgrind analysis of [BUG] unknown node type 0 — ts <decoux@...> 2004/09/17

>>>>> "A" == Andrew Walrond <andrew@walrond.org> writes:

[#3423] Re: Valgrind analysis of [BUG] unknown node type 0 — Andrew Walrond <andrew@...> 2004/09/17

On Friday 17 Sep 2004 12:01, ts wrote:

[#3424] Re: Valgrind analysis of [BUG] unknown node type 0 — ts <decoux@...> 2004/09/17

>>>>> "A" == Andrew Walrond <andrew@walrond.org> writes:

[#3425] Re: Valgrind analysis of [BUG] unknown node type 0 — Andrew Walrond <andrew@...> 2004/09/17

On Friday 17 Sep 2004 12:37, ts wrote:

[#3426] Re: Valgrind analysis of [BUG] unknown node type 0 — ts <decoux@...> 2004/09/17

>>>>> "A" == Andrew Walrond <andrew@walrond.org> writes:

[#3428] Re: Valgrind analysis of [BUG] unknown node type 0 — Andrew Walrond <andrew@...> 2004/09/17

On Friday 17 Sep 2004 13:05, ts wrote:

[#3429] Re: Valgrind analysis of [BUG] unknown node type 0 — ts <decoux@...> 2004/09/17

>>>>> "A" == Andrew Walrond <andrew@walrond.org> writes:

Re: [PATCH] dir.c --- Dir.chdir error handling

From: nobu.nokada@...
Date: 2004-09-10 01:22:47 UTC
List: ruby-core #3372
Hi,

At Fri, 10 Sep 2004 06:03:28 +0900,
H.Yamamoto wrote in [ruby-core:03369]:
> >Well, I meant just about preventing a work object from GC;
> >making the argument `data2' of rb_ensure() volatile.
> 
> I don't know well, but
> 
>   VALUE v = ......
> 
>   /* GC happened!! before assigned to volatile */
> 
>   rb_ensure(......, v); /* v is volatile VALUE */
> 
> is safe?

In that case, v should be stored somewhere in the function and
subsequent function calls, perhaps on the stack or in a
register, anyway possible to be restored and scannable by GC.
Otherwise it can't be used at calling rb_ensure().  So I think
it's safe.

There is a potential danger only when the VALUE is no longer
used after any use of its internal pointer.  Since data2 in
rb_ensure() is used only once at calling e_proc, it may not be
a "barrier" in the proc and the proc has to keep it in mind.

-- 
Nobu Nakada

In This Thread