Hi fadden,
Thank you for your reply.
yes, maybe it is the cause at you said.
About the memPartAlloc message, I think I found out the root cause and
I would like to share with you and would like to have some idea from
you.
At you know, at the current Dalvik allocates heap memory by mmap and
munmap function in 2 functions create_contiguous_mspace_with_name and
destroy_contiguous_mspace in file \system\core\libcutils\mspace.c. And
when porting on Vxwork, I replaced them with calloc and free as below:
mspace create_contiguous_mspace_with_name(size_t starting_capacity,
size_t max_capacity, int locked, char const * name) {
int fd, ret;
struct mspace_contig_state *cs;
char buf[ASHMEM_NAME_LEN] = "mspace";
void *base;
unsigned int pagesize;
mstate m;
if (starting_capacity > max_capacity)
return (mspace)0;
init_mparams();
pagesize = PAGESIZE;
/* Create the anonymous memory that will back the mspace.
* This reserves all of the virtual address space we could
* ever need. Physical pages will be mapped as the memory
* is touched.
*
* Align max_capacity to a whole page.
*/
max_capacity = (size_t)ALIGN_UP(max_capacity, pagesize);
if (name)
snprintf(buf, sizeof(buf), "mspace/%s", name);
base = calloc(1, max_capacity);
/* Make sure that base is at the beginning of a page.
*/
assert(((uintptr_t)base & (pagesize-1)) == 0);
/* Reserve some space for the information that our MORECORE needs.
*/
cs = base;
/* Create the mspace, pointing to the memory we just reserved.
*/
m = create_mspace_with_base(base + sizeof(*cs), starting_capacity,
locked);
if (m == (mspace)0)
goto error;
/* Make sure that m is in the same page as cs.
*/
assert(((uintptr_t)m & (uintptr_t)~(pagesize-1)) == (uintptr_t)
base);
/* Find out exactly how much of the memory the mspace
* is using.
*/
cs->brk = m->seg.base + m->seg.size;
cs->top = (char *)base + max_capacity;
assert((char *)base <= cs->brk);
assert(cs->brk <= cs->top);
/* Prevent access to the memory we haven't handed out yet.
*/
if (cs->brk != cs->top) {
/* mprotect() requires page-aligned arguments, but it's possible
* for cs->brk not to be page-aligned at this point.
*/
char *prot_brk = (char *)ALIGN_UP(cs->brk, pagesize);
/*
if (mprotect(prot_brk, cs->top - prot_brk, PROT_NONE) < 0)
goto error;
*/
}
cs->m = m;
cs->magic = CONTIG_STATE_MAGIC;
return (mspace)m;
error:
free(base);
return (mspace)0;
}
size_t destroy_contiguous_mspace(mspace msp) {
mstate ms = (mstate)msp;
if (ok_magic(ms)) {
struct mspace_contig_state *cs;
size_t length;
const unsigned int pagesize = PAGESIZE;
cs = (struct mspace_contig_state *)((uintptr_t)ms & ~
(pagesize-1));
assert(cs->magic == CONTIG_STATE_MAGIC);
assert(cs->m == ms);
length = cs->top - (char *)cs;
#ifdef VXW
free(cs);
perror("FREE IN destroy_contiguous_mspace\n");
printf("After free in destroy_contiguous_mspace MEMSHOW IS:\n");
return length;
#else
if (munmap((char *)cs, length) != 0)
return length;
#endif
}
else {
USAGE_ERROR_ACTION(ms, ms);
}
return 0;
}
#endif
In the past due to when we call free function in
destroy_contiguous_mspace function, it cause crash when system call
dvmShutdown() so we commented out free function and apparently after
Dalvik exits, we did not free resource so leak memory happened.
So now I need to delete comment in the past and call free in
destroy_contiguous_mspac to free allocated heap memory as the above
implement but it causes crash when call free with stack stace:
stack trace information:
SP:0x879590d0(unknown stack base:0x8fa00000)
0x80e5e9c0:memPartFree + 0x298
0x80e5e9c4:memPartFree + 0x29c -> memPartFree()
0x80c42ca4:destroy_contiguous_mspace + 0x2c -> memPartFree()
0x80cbd9d0:dvmHeapSourceShutdown + 0x50 ->
destroy_contiguous_mspace()
0x80c9f7c8:dvmShutdown + 0x170 -> dvmHeapSourceShutdown()
0x80ca43e0:dvmLookupInternalNativeMethod + 0x25a0 -> dvmShutdown()
0x80c82d48:dvmInterpretStd + 0x4ef8 ->
dvmLookupInternalNativeMethod()
0x80c751a8:dvmInterpret + 0xf8 -> dvmInterpretStd()
0x80ccc358:dvmCallMethodV + 0x168 -> dvmInterpret()
0x80ccc398:dvmCallMethod + 0x28 -> dvmCallMethodV()
0x80cb92c0:dvmCreateInternalThread + 0x358 -> dvmCallMethod()
0x8004c1a0:pthread_testcancel + 0x80 -> dvmCreateInternalThread()
0x80072b68:vxTaskEntry + 0x14 -> pthread_testcancel()
Could you please advice me why I call free as the above implement
cause crash?
Which I need to modify to fix this issue when I use calloc/free
instead of mmap/munmap?
If possible, could you tell me or share me a document about the design
of heap implement in Dalvik?
Thanks so much,
BR
On Jul 25, 3:12 am, fadden <fad...@android.com> wrote:
> On Jul 24, 8:16 am, Mercury <bao...@gmail.com> wrote:
>
> > For memPartAlloc message, I think that maybe when Dalvik exits, it did
> > not free memory so it leads to leak memory and so if we invoke to run
> > several times, it cannot get enough memory to allocate for heap size
> > and cannot start again. So I think that with heap size only 4MB and if
> > I invoke my simple test app many times , maybe Dalvik will be crashed
> > too ( with 32MB heap size, it crashed at 3rd time running).
>
> Dalvik is pretty good about freeing memory allocated with malloc(). I
> use valgrind to find memory leaks, and it's much easier to do so if
> you free everything you allocate.
>
> I glanced through the virtual heap code and it looks like it does try
> to clean up after itself during shutdown, but I haven't tried to
> verify it.
>
> In normal operation, Android application processes do not exit. They
> are simply killed. If the operating system doesn't clean up after
> them, you're going to be in a bad way if you try to run the full app
> framework.
>
> Incidentally, you definitely need to use calloc rather than malloc as
> an mmap() replacement. Storage from ashmem or anonymous mappings is
> zeroed out.
>
> Is it really the case that memory allocated with malloc() on a vxworks
> system is gone forever if the process dies?
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
