MALLOC_CHECK_ and gdb - Linux

This is a discussion on MALLOC_CHECK_ and gdb - Linux ; 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, ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: MALLOC_CHECK_ and gdb

  1. MALLOC_CHECK_ and gdb

    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


  2. Re: MALLOC_CHECK_ and gdb

    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

  3. Re: MALLOC_CHECK_ and gdb

    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

  4. Re: MALLOC_CHECK_ and gdb



    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



  5. Re: MALLOC_CHECK_ and gdb

    "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

  6. Re: MALLOC_CHECK_ and gdb

    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.

  7. Re: MALLOC_CHECK_ and gdb

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

  8. Re: MALLOC_CHECK_ and gdb



    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



  9. Re: MALLOC_CHECK_ and gdb



    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.



  10. Re: MALLOC_CHECK_ and gdb

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

    --

  11. Re: MALLOC_CHECK_ and gdb



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



  12. Re: MALLOC_CHECK_ and gdb

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

+ Reply to Thread