Debugging memory allocation crash

[contemplating zombie]

Hi,

Thank you for the suggestions.

On Thu, Dec 29, 2011 at 6:40 AM, Mulyadi Santosa
<mulyadi.santosa at gmail.com> wrote:
> Hi.....
>
> Nice name you have :)

Thank you, coming up with that was a no-brainer ;)

> On Thu, Dec 29, 2011 at 11:27, contemplating zombie
> <contemplatingzombie at gmail.com> wrote:
>> Hi,
>>
>> I have written a kernel module that does frequent memory allocs,
>> reallocs and deallocs. The code randomly crashes at one of the two
>> memory allocation parts - either in krealloc() or in
>> kmem_cache_alloc_notrace (called by kmalloc()). However, when I
>> analyzed both the crash points instructions using gdb, they both
>> turned out to be at the same location in slab_alloc().
>
> alright, all we know is that  kmalloc and family eventually use slabs.
>
> So, I suspect:
> 1. either there are flaws in slab management
> OR
> 2. you somehow corrupt the slab

I think number 1 is highly unlikely. I am focusing on number 2.

> Since you don't let us see the code, I'll ask you back:
> 1. do you think somehow you feed data bigger than one allocated?
> 2. do you somehow do double free?

I think this could be the culprit. I am putting printk's before every
alloc/free to check if this is happening.

> 3. regarding realloc...I personally don't really think it's better
> than alloc-free-alloc cycle. So, have you tried to convery your
> realloc call into alloc-free-alloc?

I will try this too, although I do not think this would be an issue.

> About the GPF, i just sense it might be a terrible memory corrupt
> somewhere somehow, And usually, the root is overflow...

I agree. Just that don't know how to pinpoint it reliably.

-ctmzb