[#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: Yukihiro Matsumoto <matz@...>
Date: 2004-09-16 00:47:57 UTC
List: ruby-core #3409
Hi,

In message "Re: [PATCH] dir.c --- Dir.chdir error handling"
    on Wed, 15 Sep 2004 18:59:04 +0900, ts <decoux@moulon.inra.fr> writes:

|Y> Interesting.  I'm happy to see the bug fixed.  But I'm not sure what
|Y> was the problem, and how this "fix" changed the situation.  Can you
|Y> (or anybody) explain for me?
|
| Well, this bug is really, really special and you must look at the
| assembler to understand it.

<snip the explanation>

| The modification with `tmp' is to make in sort that it call rb_gc_mark()
| with %ecx to avoid that it retrieve the content of %edi which was
| modified.

I understand (well, sort of).  Thank you very much.  But I still feel
like it's a too much optimization that:

|   * it move heaps in %esi, then in (%ebp - 24) (to make the test) but
|     the problem is that (%ebp - 24) is precisely the address of
|     frame->argv (it's in the stack of mark_locations_array()). This means
|     that it store heaps in frame->argv[0]

Anyway, if assignment to tmp solves the potential problems, I'd happy
to change.  Your code has two changes from gc.c:

  * assignment to tmp from *x
  * call rb_gc_mark() instead of gc_mark()

Are those two changes are both necessary, or just the former?

							matz.

In This Thread