| Is a prototype for malloc() in scope which returns a "void *"? In the absence of a prototype, the compiler will assume the function returns an "int" and allow the result to be truncated.
What warning options are you building with? Is malloc() imlemented in the same file as fnA()? Is a prototype visible to fnA()?
Shantonu Sen
Sent from my Mac Pro
On Nov 30, 2009, at 2:29 PM, mogambo wrote: Actually, after a few sessions of two-machine debugging, this is I found out something very interesting. Here's how the code sort of looks (don't ask why "malloc" is not just #define'd to _MALLOC):
void fnA(..) { if (p == NULL) { p = (struct foo *)malloc(sizeof(struct foo)); memset(p, 0, sizeof(struct foo)); <== trap, cause p is invalid
} : }
void *malloc(size_t x) { char *p = NULL; p = _MALLOC(x, M_TEMP, M_WAITOK | M_ZERO) : return p;
}
Here are the excerpts from the gdb session: (gdb) finish Run till exit from #0 _MALLOC (size=56, type=<value temporarily unavailable, due to optimizations>, flags=4) at /SourceCache/xnu/xnu-1486.2.11/bsd/kern/kern_malloc.c:557
0xffffff7f8143bc6a in malloc (x=56) at cache.c:422 422 p = _MALLOC(x, M_TEMP, M_WAITOK|M_ZERO); Value returned is $3 = (void *) 0xffffff80102178c8
(gdb) p sizeof(p) $4 = 8 (gdb) n 423 if (p == NULL) (gdb) p p $5 = 0xffffff80102178c8 ""
(gdb) n 430 return p; (gdb) p p $8 = 0xffffff80102178c8 "" (gdb) n 431 }
(gdb) fnA (....) (gdb) p p $9 = (struct foo *) 0x102178c8
So, malloc() returns 0xffffff80102178c8, however, the caller receives 0x102178c8. There seems to be some more stack funkiness happening here. I am already building with explicit -mno-red-zone flag.
Any ideas? On Mon, Nov 30, 2009 at 12:31 PM, mogambo <email@hidden> wrote:
And, while I am on the subject of corruption, is there a kernel memory debugger in Mac OS/bsd? I have seen this questions being asked on the forum, but did not find any answers.
I was wondering if there were any debug flags or something to turn on some sort of memory fencing. I am debugging a problem where the pointer returned by _MALLOC is invalid (e.g. 0x122aae48) and I get a trap fault. The size of allocation is 56 bytes, so I would expect allocation out of kalloc.64 zone. zprint in gdb shows the following for kalloc.64:
ZONE COUNT TOT_SZ MAX_SZ ELT_SZ ALLOC_SZ NAME 0xffffff80031105c8 56461 3aa000 445800 64 1000 kalloc.64 CX
Thanks!
|