Trace "free(): invalid next size (normal)" error on arm-linux board

UNIX for Advanced & Expert Users
1

Hi guys,

i'm running a program on samsumg 6410 arm cpu board. it caused an "free(): invalid next size (normal)" fail.

i try to use gdb for remote debugging:
1, start gdb server on board:

gdbserver 192.168.1.20:1234 ./HostAP 
Process ./HostAP created; pid = 499
Listening on port 1234
Remote debugging from host 192.168.1.177

2, using gdb on linux to connect, then run;

3, i got this on my console of 6410 board:

*** glibc detected *** ./HostAP: free(): invalid next size (normal): 0x0010f060 ***

4, i got this on my linux machine terminal: (hand type in..)

Program received signal SIGABRT, Aborted
[Switching to Thread 503]
0x42ade490 in ?? ()

5, i type "backtrace" command, but got this:

#0 0x42ade490 in ?? ()
Cannot access memory at address 0xa

So, i'm strucked here.. and don't know how to continue the debugging ...

any advice will be appreciated.

thanks in advance.

ss1969

2

The debugger can't tell you exactly what you did when you corrupt your heap, but things like this mean that's what happened. Perhaps you wrote past the end of a block you malloc()-ed, or wrote to memory you'd already freed, that kind of thing.

3

I have faced similar error once.

It happens when you are calling free() system call for a pointer which is already freed.

Try to look for this kind of error in the code.

4

glibc is actually able to report double-frees as double-frees directly, not just as generic heap corruption. He might have an older glibc though, which makes this less certain.

5

you may be correct.

Try to use mtrace for tracing you allocation and free calls.

mtrace - Wikipedia, the free encyclopedia

But for this you need change and recompile the code.

1 Like
6

Yes, i'm using Sourcery G++ Lite 2008 Q3 version for arm-nonelinux-gnueabi 4.3.2.
The reason for I doesn't change to version 2010.09 4.5.1 is, if I use the newer compiler, my program will encounter an error on accessing eproms onboard while nothing difference in codes.
It's weird and I doesn't plan to check it right now.

---------- Post updated at 10:11 AM ---------- Previous update was at 09:39 AM ----------

ThanksI used mtrace, but the result is still strange.
First, i'm sure my code is compiled with -g option.
but after analysis of my mtrace.log, it still reports "Caller" column as addresses ... such as 0x400366c4 etc, but not the code line.

btw, I tried another little program on fedora:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <mcheck.h>

int main (void)
{
    mtrace();

    int * p;
    p = malloc(10);
    free(p);
    free(p);
    return 0;
}

but after glibc detected "double free or corruption", the mtrace.log is still 0 bytes....nothing logged.
Why?

7

That is an excellent question. It doesn't work for me either and I don't know why yet. (yes, I exported MALLOC_TRACE). It even has a mysterious ability to find the current terminal when stdin, stdout, and stderr have all been redirected.

---------- Post updated at 09:03 PM ---------- Previous update was at 08:55 PM ----------

This suggests latent bugs in your code unfortunately. Different optimization methods, etc may foil assumptions in your code that seemed safe but technically aren't -- uninitialized variables being zero, etc. I can't prove this -- and have experienced actual compiler bugs -- but the bug being your own is far, far more likely.

1 Like
8

I think you should call,

muntrace();

only then logs will be flushed to mtrace file i think.

In your case we are not having much to log, so it won't be crossing the buffer size and nothing comes out in the file when the process crashes.

Please try with this change.

It didn't work for me as well. I am sorry.

Could you try valgrind for checking.

1 Like
9

Thank you all replied this thread.
I've found that bug, it's a memcpy() 'size' parameter too big problem. I think the memcpy action itself doesn't caused exception directly, but the following free() or some functions caused the exception and exit.

btw, the ultimate debug method is : printf & remark.

---------- Post updated at 04:25 PM ---------- Previous update was at 04:19 PM ----------

In this case, muntrace() doesn't change the result either... you can try this yourself.

I'll try valgrind, later, if I encountered same kind of bugs.

Thank you for your kindness.

1 Like