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 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.
Thanks,
--
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa
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] |