MALLOC_CHECK_ and gdb

[Bin Chen]

Hi,

I am debugging the buggy program which is fulfilled by malloc and free,
sometime it crashes in a curious place. I have found that some weird
problems are caused by freeing a wrong address. This makes the program
running, but will encounter strange behavior then.

Now I know MALLOC_CHECK_ can make the glibc print out the wrong free,
but the printed infomation is not enough. I want to attach gdb to the
process when the MALLOC_CHECK_'s check point is meet. This can give me
a backtrace when the wrong free occurs.

Any way to do this? Any help appreciated!

ABAI

[Emmanuel Fleury]

Post by Bin Chen
I am debugging the buggy program which is fulfilled by malloc and free,
sometime it crashes in a curious place. I have found that some weird
problems are caused by freeing a wrong address. This makes the program
running, but will encounter strange behavior then.
Now I know MALLOC_CHECK_ can make the glibc print out the wrong free,
but the printed infomation is not enough. I want to attach gdb to the
process when the MALLOC_CHECK_'s check point is meet. This can give me
a backtrace when the wrong free occurs.
Any way to do this? Any help appreciated!

Use valgrind: http://valgrind.org/

Regards

[Yao Qi]

Post by Emmanuel Fleury

Post by Bin Chen
I am debugging the buggy program which is fulfilled by malloc and

free,

Post by Bin Chen
sometime it crashes in a curious place. I have found that some weird
problems are caused by freeing a wrong address. This makes the program
running, but will encounter strange behavior then.
Now I know MALLOC_CHECK_ can make the glibc print out the wrong free,
but the printed infomation is not enough. I want to attach gdb to the
process when the MALLOC_CHECK_'s check point is meet. This can give me
a backtrace when the wrong free occurs.
Any way to do this? Any help appreciated!

Use valgrind: http://valgrind.org/

Yes, valgrind is very good at checking the problems of memory allocation
and release.

Valgrind has been shipped in most of the distros, and you could simply
run your program prefixed by valgrind in command line without rebuild
or relink you program. For example,

$valgrind path/to/your/program

It will produce a report about the memory leak in your program. I think
it is what you what.

Post by Emmanuel Fleury
Regards

[Bin Chen]

Post by Yao Qi

Post by Bin Chen
I am debugging the buggy program which is fulfilled by malloc and

free,

Post by Bin Chen
sometime it crashes in a curious place. I have found that some weird
problems are caused by freeing a wrong address. This makes the program
running, but will encounter strange behavior then.
Now I know MALLOC_CHECK_ can make the glibc print out the wrong free,
but the printed infomation is not enough. I want to attach gdb to the
process when the MALLOC_CHECK_'s check point is meet. This can give me
a backtrace when the wrong free occurs.
Any way to do this? Any help appreciated!

Use valgrind:http://valgrind.org/Yes, valgrind is very good at checking the problems of memory allocation

and release.
Valgrind has been shipped in most of the distros, and you could simply
run your program prefixed by valgrind in command line without rebuild
or relink you program. For example,
$valgrind path/to/your/program
It will produce a report about the memory leak in your program. I think
it is what you what.

Thanks for your suggestion, but actually, we are developing a large
embedded system, it consists of many applications so that I can't
afford to start every application like this.

What I am going to find is a general solution, that machanism/tools
resides in my root filesystem, and it is only loaded to memory when the
program suffering something wrong, such as segment fault. Use the segv
handler to attach the gdbserver to itself is a case matched my
requirement.

So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?

Anyway, I will first check the valgrind manual to see if it can do
things like.

Post by Yao Qi

Regards--

Yao Qi
GNU/Linux Developer

[Yao Qi]

Post by Yao Qi
checking the problems of memory allocation

Post by Yao Qi
and release.
Valgrind has been shipped in most of the distros, and you could simply
run your program prefixed by valgrind in command line without rebuild
or relink you program. For example,
$valgrind path/to/your/program
It will produce a report about the memory leak in your program. I

think

Post by Yao Qi
it is what you what.

Thanks for your suggestion, but actually, we are developing a large
embedded system, it consists of many applications so that I can't
afford to start every application like this.

If you develop your system on ARM, valgrind is still useful, since it is
supported on ARM. However, I am afraid valgrind on ARM is not as strong
as it on other platforms.

Post by Yao Qi
What I am going to find is a general solution, that machanism/tools
resides in my root filesystem, and it is only loaded to memory when the
program suffering something wrong, such as segment fault. Use the segv
handler to attach the gdbserver to itself is a case matched my
requirement.

If your problem is *only* segment fault, core file may help you.

$ ulimit -c unlimited
$ ./path/to/your/program (a core file will be dumped by kernel)
$ copy core file to your host
$ ./gdb ./path/to/your/program corefile
$ run "bt" gdb, and backtrace may help you to identify the errors.

I never did cross-debugging with core file, but I think it would be
right. Free to correct me if I am wrong.

Post by Yao Qi
So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?

If I understand correctly, you could try LD_PRELOAD, and write free() in
a shared object to interpose the actual free() in glibc.

http://developers.sun.com/solaris/articles/lib_interposers.html

[Paul Pluzhnikov]

Post by Yao Qi
If you develop your system on ARM, valgrind is still useful,

It is? That's big news to me.

According to http://valgrind.org/info/platforms.html,
ARM is *not* supported currently, and is *low* on porting plans.

Do you know something I don't, or do you just not know what you
are talking about?

Cheers,

[Bin Chen]

Post by Yao Qi

Post by Yao Qi
checking the problems of memory allocation

Post by Yao Qi
and release.
Valgrind has been shipped in most of the distros, and you could simply
run your program prefixed by valgrind in command line without rebuild
or relink you program. For example,
$valgrind path/to/your/program
It will produce a report about the memory leak in your program. I

think

Post by Yao Qi
it is what you what.

Thanks for your suggestion, but actually, we are developing a large
embedded system, it consists of many applications so that I can't
afford to start every application like this.If you develop your system on ARM, valgrind is still useful, since it is

supported on ARM. However, I am afraid valgrind on ARM is not as strong
as it on other platforms.

Post by Yao Qi
What I am going to find is a general solution, that machanism/tools
resides in my root filesystem, and it is only loaded to memory when the
program suffering something wrong, such as segment fault. Use the segv
handler to attach the gdbserver to itself is a case matched my
requirement.If your problem is *only* segment fault, core file may help you.

If I free a wrong addresss, the program will run as normal then, but
may has segv later in a weird place( the effect of the prior free).
That means the segv address is not the place that you did the wrong
thing.

Post by Yao Qi
$ ulimit -c unlimited
$ ./path/to/your/program (a core file will be dumped by kernel)
$ copy core file to your host
$ ./gdb ./path/to/your/program corefile
$ run "bt" gdb, and backtrace may help you to identify the errors.
I never did cross-debugging with core file, but I think it would be
right. Free to correct me if I am wrong.

Post by Yao Qi
So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?If I understand correctly, you could try LD_PRELOAD, and write free() in

a shared object to interpose the actual free() in glibc.
http://developers.sun.com/solaris/articles/lib_interposers.html
--
Yao Qi
GNU/Linux Developer

[Paul Pluzhnikov]

Post by Bin Chen
So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?

Sure: since you can modify libc source, you can make it do whatever
you want.

Post by Bin Chen
Anyway, I will first check the valgrind manual to see if it can do
things like.

VG can fork a debugger when it detects a problem, but the program
must run under VG from the beginning, and VG overhead is significant,
so it doesn't sound like VG is a viable solution for you.

Cheers,

[Bin Chen]

Post by Paul Pluzhnikov

Post by Bin Chen
So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?Sure: since you can modify libc source, you can make it do whatever

you want.

No, I really want a clean way, not so dirty.

Post by Paul Pluzhnikov

Post by Bin Chen
Anyway, I will first check the valgrind manual to see if it can do
things like.VG can fork a debugger when it detects a problem, but the program

must run under VG from the beginning, and VG overhead is significant,
so it doesn't sound like VG is a viable solution for you.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[John Reiser]

Post by Bin Chen

Post by Paul Pluzhnikov

Post by Bin Chen
So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?

Sure: since you can modify libc source, you can make it do whatever
you want.

No, I really want a clean way, not so dirty.

The source to glibc-2.3.5/malloc contains a mechanism to hook the external
entries malloc, free, realloc, and memalign. So that is not so dirty.

The work comes when you must duplicate the logic to detect "wrongly-free"
in order for the hook to be as selective as you desire.

--

[Bin Chen]

Post by John Reiser

Post by Paul Pluzhnikov

Post by Bin Chen
So what I want to know is, can I add a hook to wrongly-free so that I
can pause at the free point and then attach the gdbserver to my self
then I can get far more infomation about my trapping scenario?

Sure: since you can modify libc source, you can make it do whatever
you want.

No, I really want a clean way, not so dirty.The source to glibc-2.3.5/malloc contains a mechanism to hook the external

entries malloc, free, realloc, and memalign. So that is not so dirty.
The work comes when you must duplicate the logic to detect "wrongly-free"
in order for the hook to be as selective as you desire.

The MALLOC_CHECK_ has done the detection part, if I add a hook to
free, can I easily reuse what MALLOC_CHECK_ has done?

Post by John Reiser
--

[Paul Pluzhnikov]

Post by Bin Chen
The MALLOC_CHECK_ has done the detection part, if I add a hook to
free, can I easily reuse what MALLOC_CHECK_ has done?

Use the Source, Luke.
It's no use asking questions like above -- to answer it we'd have
to look at the source anyway; so why don't you do it yourself?

That said, my guess (without digging into the source) is that the
answer is no.

Cheers,