Bin Chen wrote:
>
> 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
--
Emmanuel Fleury | Office: 261
Associate Professor, | Phone: +33 (0)5 40 00 69 34
LaBRI, Domaine Universitaire | Fax: +33 (0)5 40 00 66 69
351, Cours de la Lib¨¦ration | email: emmanuel.fleury@labri.fr
33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury

Emmanuel Fleury writes:

> Bin Chen wrote:
>>
>> 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/

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.

>
> Regards

--
Yao Qi
GNU/Linux Developer

On Jan 17, 7:24 pm, Yao Qi wrote:
> Emmanuel Fleury writes:
> > Bin Chen wrote:
>
> >> 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/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.
>
>
>
> > Regards--
> Yao Qi
> GNU/Linux Developer

"Bin Chen" writes:


> 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.

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.

>
> 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.

>
> 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/ar...terposers.html


--
Yao Qi
GNU/Linux Developer

Yao Qi writes:

> 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,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

"Bin Chen" writes:

> 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.

> 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.

On Jan 17, 9:35 pm, Yao Qi wrote:
> "Bin Chen" writes:
> > 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.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.
>
>
>
> > 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.

> $ 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.
>
>
>
> > 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/ar...terposers.html
>
> --
> Yao Qi
> GNU/Linux Developer

On Jan 17, 11:16 pm, Paul Pluzhnikov
wrote:
> "Bin Chen" writes:
> > 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.
>
> > 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.

>>>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.

--

On 1ÔÂ18ÈÕ, ÉÏÎç9ʱ02·Ö, John Reiser
wrote:
> >>>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?
>
> --

"Bin Chen" writes:

> 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,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.