This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sun, 2003-07-13 at 23:01, Martin Schlemmer wrote: > On Sun, 2003-07-13 at 20:58, Ulrich Drepper wrote: > > > I never suggested hardware failures. And the older glibc can very well > > produce a different memory layout which causes a memory corruption to be > > not noticable. > > > > Ok, I plugged a few holes, and if you look at: > > ---------------------------- > #0 0x405ee1e1 in malloc_consolidate (av=0x406a37e0) at malloc.c:4355 > #1 0x405eda58 in _int_malloc (av=0x406a37e0, bytes=25) at malloc.c:3794 > #2 0x405ece0b in __libc_malloc (bytes=504) at malloc.c:3293 > #3 0x4053424e in g_malloc (n_bytes=504) at gmem.c:136 > ---------------------------- > > Where __libc_malloc() here is public_mALLOc(), it looks like > __libc_malloc() (public_mALLOc()) is called as: > > __libc_malloc(504) > > but then it ends up with the arg set to 25 which it uses to call > __int_malloc()? Beside some other checks added, I changed: > > ---------------------------- > Void_t* > public_mALLOc(size_t bytes) > { > mstate ar_ptr; > Void_t *victim; > > __malloc_ptr_t (*hook) __MALLOC_P ((size_t, __const __malloc_ptr_t)) = > __malloc_hook; > if (hook != NULL) > return (*hook)(bytes, RETURN_ADDRESS (0)); > > arena_get(ar_ptr, bytes); > if(!ar_ptr) > return 0; > victim = _int_malloc(ar_ptr, bytes); > if(!victim) { > ---------------------------------- > > to: > > ---------------------------------- > Void_t* > public_mALLOc(size_t bytes) > { > mstate ar_ptr; > Void_t *victim; > size_t tmp_bytes = bytes; > > __malloc_ptr_t (*hook) __MALLOC_P ((size_t, __const __malloc_ptr_t)) = > __malloc_hook; > if (hook != NULL) > return (*hook)(bytes, RETURN_ADDRESS (0)); > > arena_get(ar_ptr, tmp_bytes); > if(!ar_ptr) > return 0; > victim = _int_malloc(ar_ptr, bytes); > if(!victim) { > ------------------------------ > > in an attempt to ensure that arena_get() will not clobber > 'bytes'. > > Can this be some sort of issue with how args are passed to > functions (gcc/kernel side) ? > > I am not the greatest of debuggers, so a hand would be appreciated. > The same seem to be evident for public_fREe(). Problem with how arguments are passed to weak aliases? Thanks, -- Martin Schlemmer
Attachment:
signature.asc
Description: This is a digitally signed message part
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |