I am having a hard time tracking down a bug in native C code within my Android application. This code sits in Wireshark, which I've ported to Android. I have run this same code on x86 numerous times under Valgrind and GDB and can never find a problem with it. However, when it runs on Android, it seems to behave differ开发者_StackOverflow社区ently and cause segmentation faults every so often (e.g., after running ~100 times).
To be honest, I do not understand the syntax of the code that well, so I'm having a hard time understanding what assumptions might have been made about an x86 machine that do not hold about an ARM-based processor.
Essentially, what it tries to do is bypass constantly allocating new memory and freeing it, by placing memory in to a "bucket" and allowing it to be reused. Whether or not this is actually better in terms of performance is a separate question. I'm simply trying to adopt pre-existing code. But, to do so, it has a couple main macros:
#define SLAB_ALLOC(item, type) \
if(!type ## _free_list){ \
int i; \
union type ## slab_item *tmp; \
tmp=g_malloc(NITEMS_PER_SLAB*sizeof(*tmp)); \
for(i=0;i<NITEMS_PER_SLAB;i++){ \
tmp[i].next_free = type ## _free_list; \
type ## _free_list = &tmp[i]; \
} \
} \
item = &(type ## _free_list->slab_item); \
type ## _free_list = type ## _free_list->next_free;
#define SLAB_FREE(item, type) \
{ \
((union type ## slab_item *)item)->next_free = type ## _free_list; \
type ## _free_list = (union type ## slab_item *)item; \
}
Then, a couple supporting macros for specific types:
#define SLAB_ITEM_TYPE_DEFINE(type) \
union type ## slab_item { \
type slab_item; \
union type ## slab_item *next_free; \
};
#define SLAB_FREE_LIST_DEFINE(type) \
union type ## slab_item *type ## _free_list = NULL;
#define SLAB_FREE_LIST_DECLARE(type) \
union type ## slab_item *type ## _free_list;
Does anyone recognize any assumptions on x86 that might not fly on an Android phone? Eventually what happens is, SLAB_ALLOC() is called and it returns something from the list. Then, following code attempts to use the memory, and the application segfaults. This leads me to believe it's accessing invalid memory. It happens unpredictably, but it always happens in the first attempt to use memory that SLAB_ALLOC() returns.
Is it possible you're simply running out of memory? The SLAB_ALLOC
macro calls g_malloc
which aborts if the allocation fails.
精彩评论