[#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: Valgrind analysis of [BUG] unknown node type 0

From: Andrew Walrond <andrew@...>
Date: 2004-09-17 11:34:28 UTC
List: ruby-core #3423
On Friday 17 Sep 2004 12:01, ts wrote:
>
> '.local i' : the address will be allocated in bss section, and it will
> zeroed at run-time.
>

Ok; I concur. Infact running the 'fixed' code through Valgrind does not remove 
the errors.

The function causing valgrind to shout


==28001== Conditional jump or move depends on uninitialised value(s)
==28001==    at 0x806FF18: is_pointer_to_heap (gc.c:591)
==28001==    by 0x806FEE1: mark_locations_array (gc.c:609)
==28001==    by 0x80710F8: rb_gc (gc.c:1328)
==28001==    by 0x806FBAC: rb_newobj (gc.c:376)

is

static inline int
is_pointer_to_heap(ptr)
    void *ptr;
{
    register RVALUE *p = RANY(ptr);
    register RVALUE *heap_org;
    register long i;

    if (p < lomem || p > himem) return Qfalse;

    /* check if p looks like a pointer */
    for (i=0; i < heaps_used; i++) {
  heap_org = heaps[i].slot;
  if (heap_org <= p && p < heap_org + heaps[i].limit &&
      ((((char*)p)-((char*)heap_org))%sizeof(RVALUE)) == 0)
      return Qtrue;
    }
    return Qfalse;
}

So if lomem and himem are not the culprits, then it must be 'p'

I'll try following this back up the stack with gdb, to see where it leads...

Andrew

In This Thread