track memory allocation - VxWorks

This is a discussion on track memory allocation - VxWorks ; Hi Is there anyway to track the memory allocation (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools or libraries ? Thanks T...

+ Reply to Thread
Results 1 to 15 of 15

Thread: track memory allocation

  1. track memory allocation

    Hi
    Is there anyway to track the memory allocation
    (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools or
    libraries ?
    Thanks


    T



  2. Re: track memory allocation

    There are lots of tools for that, bothh from windriver, 3rd parties,
    and freeware.

    Search the vxWorks FAQ for "memTrack" and you'll find a couple of
    pieces for source to put into your build.

    Good luck,
    lc
    void wrote:
    > Hi
    > Is there anyway to track the memory allocation
    > (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools or
    > libraries ?
    > Thanks
    >
    >
    > T



  3. Re: track memory allocation

    what about new/delete, have you an idea if something like memTrack exists ?
    can you give me some 3rd parties/freeware tools names ?

    Regards.

    "LarryC" a écrit dans le message de news:
    1149374186.125816.186680@i39g2000cwa.googlegroups. com...
    > There are lots of tools for that, bothh from windriver, 3rd parties,
    > and freeware.
    >
    > Search the vxWorks FAQ for "memTrack" and you'll find a couple of
    > pieces for source to put into your build.
    >
    > Good luck,
    > lc
    > void wrote:
    >> Hi
    >> Is there anyway to track the memory allocation
    >> (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools
    >> or
    >> libraries ?
    >> Thanks
    >>
    >>
    >> T

    >




  4. Re: track memory allocation


    void wrote:
    > what about new/delete, have you an idea if something like memTrack exists?
    > can you give me some 3rd parties/freeware tools names ?
    >
    > Regards.
    >
    > "LarryC" a écrit dans le message de news:
    > 1149374186.125816.186680@i39g2000cwa.googlegroups. com...
    > > There are lots of tools for that, bothh from windriver, 3rd parties,
    > > and freeware.
    > >
    > > Search the vxWorks FAQ for "memTrack" and you'll find a couple of
    > > pieces for source to put into your build.
    > >
    > > Good luck,
    > > lc
    > > void wrote:
    > >> Hi
    > >> Is there anyway to track the memory allocation
    > >> (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools
    > >> or
    > >> libraries ?
    > >> Thanks
    > >>
    > >>
    > >> T

    > >



    Hi,
    Theres a tool by name memscope.I have not used it.But have seen people
    using it for problems you have reported.But its not free.You have to
    buy from windriver.
    Regards,
    s.subbarayan


  5. Re: track memory allocation

    >From the VxWorks FAQ...

    Q: How do I find memory leaks?

    A: The following message was written in de newsgroup by Richard Dickson
    dickson@jlab.org for a 68K architecture system:

    I coded up some diagnostic code myself to help me find memory leaks
    caused by the use of malloc, calloc, and free. I have attached the two
    c source files (both pretty small) for this. They may not be great, but
    then again I think they generally work (and are free). Compile both
    source files and then enter:

    ld find_malloc
    ld
    in that order *before* loading any of your source code. This diagnostic
    replaces malloc, calloc, and free with versions that keep some
    statistics. You can then enter "memTrack" at the command line to get
    info on a per task basis about memory used.

    Use at your own risk

    findMalloc.c
    memTrack.c

    source is provided in link from the FAQ.

    There are both static and dynamic memory analyzers - Try Polyscope,
    KlockWorks, and
    Coverity for the static type. Tons more for RT checking, though the
    free one above should do the job for my things.

    lc

    ssubbarayan wrote:
    > void wrote:
    > > what about new/delete, have you an idea if something like memTrack exists ?
    > > can you give me some 3rd parties/freeware tools names ?
    > >
    > > Regards.
    > >
    > > "LarryC" a écrit dans le message de news:
    > > 1149374186.125816.186680@i39g2000cwa.googlegroups. com...
    > > > There are lots of tools for that, bothh from windriver, 3rd parties,
    > > > and freeware.
    > > >
    > > > Search the vxWorks FAQ for "memTrack" and you'll find a couple of
    > > > pieces for source to put into your build.
    > > >
    > > > Good luck,
    > > > lc
    > > > void wrote:
    > > >> Hi
    > > >> Is there anyway to track the memory allocation
    > > >> (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools
    > > >> or
    > > >> libraries ?
    > > >> Thanks
    > > >>
    > > >>
    > > >> T
    > > >

    >
    >
    > Hi,
    > Theres a tool by name memscope.I have not used it.But have seen people
    > using it for problems you have reported.But its not free.You have to
    > buy from windriver.
    > Regards,
    > s.subbarayan



  6. Re: track memory allocation

    you'll say that i'm lazy, but i really tried to find the website of
    KlockWorks Polyscope & Coverity without a success, can any one pm me
    (qos1(at)free(dot)fr).
    Best regards.

    "LarryC" a écrit dans le message de news:
    1149437113.756587.221310@i39g2000cwa.googlegroups. com...
    >From the VxWorks FAQ...


    Q: How do I find memory leaks?

    A: The following message was written in de newsgroup by Richard Dickson
    dickson@jlab.org for a 68K architecture system:

    I coded up some diagnostic code myself to help me find memory leaks
    caused by the use of malloc, calloc, and free. I have attached the two
    c source files (both pretty small) for this. They may not be great, but
    then again I think they generally work (and are free). Compile both
    source files and then enter:

    ld find_malloc
    ld
    in that order *before* loading any of your source code. This diagnostic
    replaces malloc, calloc, and free with versions that keep some
    statistics. You can then enter "memTrack" at the command line to get
    info on a per task basis about memory used.

    Use at your own risk

    findMalloc.c
    memTrack.c

    source is provided in link from the FAQ.

    There are both static and dynamic memory analyzers - Try Polyscope,
    KlockWorks, and
    Coverity for the static type. Tons more for RT checking, though the
    free one above should do the job for my things.

    lc

    ssubbarayan wrote:
    > void wrote:
    > > what about new/delete, have you an idea if something like memTrack
    > > exists ?
    > > can you give me some 3rd parties/freeware tools names ?
    > >
    > > Regards.
    > >
    > > "LarryC" a écrit dans le message de news:
    > > 1149374186.125816.186680@i39g2000cwa.googlegroups. com...
    > > > There are lots of tools for that, bothh from windriver, 3rd parties,
    > > > and freeware.
    > > >
    > > > Search the vxWorks FAQ for "memTrack" and you'll find a couple of
    > > > pieces for source to put into your build.
    > > >
    > > > Good luck,
    > > > lc
    > > > void wrote:
    > > >> Hi
    > > >> Is there anyway to track the memory allocation
    > > >> (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra
    > > >> tools
    > > >> or
    > > >> libraries ?
    > > >> Thanks
    > > >>
    > > >>
    > > >> T
    > > >

    >
    >
    > Hi,
    > Theres a tool by name memscope.I have not used it.But have seen people
    > using it for problems you have reported.But its not free.You have to
    > buy from windriver.
    > Regards,
    > s.subbarayan




  7. Re: track memory allocation


    On 4 Jun 2006, larry@ciummo.com wrote:

    >> From the VxWorks FAQ...


    > Q: How do I find memory leaks?


    > A: The following message was written in de newsgroup by Richard
    > Dickson dickson@jlab.org for a 68K architecture system:


    I think only really works for an 68K. That is fairly important. I
    don't know many people using the 68K architecture now. Maybe x86,
    PowerPc, ARM, MIPS.

    I think that Johan also put notes on replacing the allocator with Doug
    Lea's allocator. "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt5.html#5.4A"

    After you have "hi-jacked" the allocator, you can modify many
    debugging mallocs (dmalloc, etc) and use them to track memory use.
    This requires a little work.

    I have used memScope. It is fairly easy to get running, but it
    doesn't always give the best information. I like dmalloc as you can
    insert "memory check points" in your code to make sure that some
    sequence of events did not result in any memory leaks. Using tools
    like Purify, memScope, and Insure seem to lead to a lot of dead ends.
    For instance, UGL might "cache" glyphs that are used to draw
    characters. The DNS code may "cache" resolved names, etc. Most of
    these tools will report these circumstances as "leaks". It usually
    takes me several days to convince people otherwise.

    SeaWeed systems offered a memLib replacement for vxWorks. I don't see
    it on their web sight though. The OP also didn't say what version of
    vxWorks.

    hth,
    Bill Pringlemeir.

    --
    Little girls, like butterflies need no excuses. - Robert Heinlein
    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  8. Re: track memory allocation

    Try www.parasoft.com, www.klocwork.com, and www.coverity.com. These
    are the "static" ones - they are all basically source code analyzers.

    lc
    void wrote:
    > Hi
    > Is there anyway to track the memory allocation
    > (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools or
    > libraries ?
    > Thanks
    >
    >
    > T



  9. Re: track memory allocation

    calloc/malloc/realloc.... all are based on memParLib with functions like
    memPartAlloc or
    memPartAlignedAlloc. You can hook the call to these functions by patching
    this library.
    Normally you should have the memPartLib.c.
    This library is part of libos.o. So once you have recompiled the
    memPartLib.c you have to update libos.a using "ar???? dv libos.a
    mempartlib.o " and "ar???? ruv libos.a mempartlib.o"
    Hope this help.
    Pat

    "void" wrote in message
    news:4481e5c6$0$13025$626a54ce@news.free.fr...
    > Hi
    > Is there anyway to track the memory allocation
    > (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools or
    > libraries ?
    > Thanks
    >
    >
    > T
    >




  10. Re: track memory allocation

    Hi,
    Isn't there any free alternative to memScope ?

    BR.
    TAA

    PatrickC a écrit :

    > calloc/malloc/realloc.... all are based on memParLib with functions like
    > memPartAlloc or
    > memPartAlignedAlloc. You can hook the call to these functions by patching
    > this library.
    > Normally you should have the memPartLib.c.
    > This library is part of libos.o. So once you have recompiled the
    > memPartLib.c you have to update libos.a using "ar???? dv libos.a
    > mempartlib.o " and "ar???? ruv libos.a mempartlib.o"
    > Hope this help.
    > Pat
    >
    > "void" wrote in message
    > news:4481e5c6$0$13025$626a54ce@news.free.fr...
    > > Hi
    > > Is there anyway to track the memory allocation
    > > (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra toolsor
    > > libraries ?
    > > Thanks
    > >
    > >
    > > T
    > >



  11. Re: track memory allocation

    Seems that nobody has delivered any free tool for doing this.
    Memscope is very powerfull but unfortunately the liscence price
    is TOO much .....




    "taa" wrote in message
    news:1149844597.449430.277460@y43g2000cwc.googlegr oups.com...
    Hi,
    Isn't there any free alternative to memScope ?

    BR.
    TAA

    PatrickC a écrit :

    > calloc/malloc/realloc.... all are based on memParLib with functions like
    > memPartAlloc or
    > memPartAlignedAlloc. You can hook the call to these functions by patching
    > this library.
    > Normally you should have the memPartLib.c.
    > This library is part of libos.o. So once you have recompiled the
    > memPartLib.c you have to update libos.a using "ar???? dv libos.a
    > mempartlib.o " and "ar???? ruv libos.a mempartlib.o"
    > Hope this help.
    > Pat
    >
    > "void" wrote in message
    > news:4481e5c6$0$13025$626a54ce@news.free.fr...
    > > Hi
    > > Is there anyway to track the memory allocation
    > > (malloc/calloc/realloc/new/delete/free ..) in wxworks ? any extra tools
    > > or
    > > libraries ?
    > > Thanks
    > >
    > >
    > > T
    > >




  12. Re: track memory allocation


    > On 4 Jun 2006, larry@ciummo.com wrote:
    >
    > >> From the VxWorks FAQ...

    >
    > > Q: How do I find memory leaks?

    >
    > > A: The following message was written in de newsgroup by Richard
    > > Dickson dickson@jlab.org for a 68K architecture system:

    >
    > I think only really works for an 68K. That is fairly important. I
    > don't know many people using the 68K architecture now. Maybe x86,
    > PowerPc, ARM, MIPS.
    >
    > I think that Johan also put notes on replacing the allocator with Doug
    > Lea's allocator.
    > "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt5.html#5.4A"
    >
    > After you have "hi-jacked" the allocator, you can modify many
    > debugging mallocs (dmalloc, etc) and use them to track memory use.
    > This requires a little work.
    >
    > I have used memScope. It is fairly easy to get running, but it
    > doesn't always give the best information. I like dmalloc as you can
    > insert "memory check points" in your code to make sure that some
    > sequence of events did not result in any memory leaks. Using tools
    > like Purify, memScope, and Insure seem to lead to a lot of dead ends.
    > For instance, UGL might "cache" glyphs that are used to draw
    > characters. The DNS code may "cache" resolved names, etc. Most of
    > these tools will report these circumstances as "leaks". It usually
    > takes me several days to convince people otherwise.
    >
    > SeaWeed systems offered a memLib replacement for vxWorks. I don't see
    > it on their web sight though. The OP also didn't say what version of
    > vxWorks.
    >
    > hth,
    > Bill Pringlemeir.
    >
    > --
    > Little girls, like butterflies need no excuses. - Robert Heinlein
    > vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"


    Well the code is based on replacing "on the fly" code in VxWorks loaded
    libraries. Basically what's done is thet at the function entry a asm-jmp
    to the new tracking software is placed and the new tracking function
    jumps back just after the jump. Since there are assembler opcodes
    involved it only works for the processor that understands these opcodes.
    An expicienced embedded software professional should be able to port
    this in just a few minutes to any other architecture......

    Well I use a 68k based boards..

    Gr,
    Renee

    --


  13. Re: track memory allocation

    >> On 4 Jun 2006, larry@ciummo.com wrote:

    >>>> From the VxWorks FAQ...


    >>> Q: How do I find memory leaks?


    >>> A: The following message was written in de newsgroup by Richard
    >>> Dickson dickson@jlab.org for a 68K architecture system:


    >> I think only really works for an 68K. That is fairly important. I
    >> don't know many people using the 68K architecture now. Maybe x86,
    >> PowerPc, ARM, MIPS.


    >> I think that Johan also put notes on replacing the allocator with
    >> Doug Lea's allocator.
    >> "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt5.html#5.4A"


    [snip]

    >> Bill Pringlemeir.


    On 9 Jun 2006, member1134@nomx.sysadminforum.com wrote:

    > Well the code is based on replacing "on the fly" code in VxWorks
    > loaded libraries. Basically what's done is thet at the function
    > entry a asm-jmp to the new tracking software is placed and the new
    > tracking function jumps back just after the jump. Since there are
    > assembler opcodes involved it only works for the processor that
    > understands these opcodes. An expicienced embedded software
    > professional should be able to port this in just a few minutes to
    > any other architecture......


    All the more reason not to do it this way. Self modifying code is not
    good. On more advanced architectures, you have cache and MMU
    problems. It isn't so easy to just change the "asm-jmp". Extracting
    and modifying the symbols in memPartLib and memLib seems to be a
    better route. It should be possible to combine this idea with the
    original tracking code. However, there are many open source memory
    debugging packages that can also be adapted when you can replace the
    vxWorks allocator.

    Fwiw,
    Bill Pringlemeir.

    --
    Little girls, like butterflies need no excuses. - Robert Heinlein
    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  14. Re: track memory allocation [cross]

    I would like to find anyexmple of what you call "here are many open
    source memory
    > debugging packages that can also be adapted when you can replace the
    > vxWorks allocator", any links ?


    TA.

    Bill Pringlemeir a écrit :

    > >> On 4 Jun 2006, larry@ciummo.com wrote:

    >
    > >>>> From the VxWorks FAQ...

    >
    > >>> Q: How do I find memory leaks?

    >
    > >>> A: The following message was written in de newsgroup by Richard
    > >>> Dickson dickson@jlab.org for a 68K architecture system:

    >
    > >> I think only really works for an 68K. That is fairly important. I
    > >> don't know many people using the 68K architecture now. Maybe x86,
    > >> PowerPc, ARM, MIPS.

    >
    > >> I think that Johan also put notes on replacing the allocator with
    > >> Doug Lea's allocator.
    > >> "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt5.html#5.4A"

    >
    > [snip]
    >
    > >> Bill Pringlemeir.

    >
    > On 9 Jun 2006, member1134@nomx.sysadminforum.com wrote:
    >
    > > Well the code is based on replacing "on the fly" code in VxWorks
    > > loaded libraries. Basically what's done is thet at the function
    > > entry a asm-jmp to the new tracking software is placed and the new
    > > tracking function jumps back just after the jump. Since there are
    > > assembler opcodes involved it only works for the processor that
    > > understands these opcodes. An expicienced embedded software
    > > professional should be able to port this in just a few minutes to
    > > any other architecture......

    >
    > All the more reason not to do it this way. Self modifying code is not
    > good. On more advanced architectures, you have cache and MMU
    > problems. It isn't so easy to just change the "asm-jmp". Extracting
    > and modifying the symbols in memPartLib and memLib seems to be a
    > better route. It should be possible to combine this idea with the
    > original tracking code. However, there are many open source memory
    > debugging packages that can also be adapted when you can replace the
    > vxWorks allocator.
    >
    > Fwiw,
    > Bill Pringlemeir.
    >
    > --
    > Little girls, like butterflies need no excuses. - Robert Heinlein
    > vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"



  15. Re: track memory allocation [cross]


    Bill Pringlemeir a écrit :

    >>>> I think that Johan also put notes on replacing the allocator with
    >>>> Doug Lea's allocator.
    >>>> "http://www.xs4all.nl/~borkhuis/vxworks/vxw_pt5.html#5.4A"


    [snip]

    >> It should be possible to combine this idea with the original
    >> tracking code. However, there are many open source memory
    >> debugging packages that can also be adapted when you can replace
    >> the vxWorks allocator.


    On 14 Jun 2006, TAllaoua@gmail.com wrote:
    > I would like to find anyexmple of what you call "here are many open
    > source memory


    Google "open source memory debugging". Dmalloc was also mentioned in
    this thread. As you can't seem to use google, "http://dmalloc.com/".
    Also, a good list is maintained by the Mozilla developers.

    "http://www.mozilla.org/projects/xpcom/MemoryTools.html"
    "https://www.mozilla.org/performance/tools.html"

    A little research would find these (third link with google search
    suggested). I hope you still look around and report if you use
    anything and how to give the code back.

    I used the memory tracing routine that comes with Doug Lea's
    allocator. It was the first link I mentioned above and also is in the
    vxWorks FAQ. This requires a file system. I think I replaced all
    fprintf with logMsg and used the shell and ethernet to capture the
    data. The solution you wish to use will depend on system resources.
    Do you have a fast CPU? Do you have a fast communication link to a
    PC? Do you have lots of embedded storage? If none of the above, you
    will not be able to do memory debugging on the target.

    You can also re-compile code on a PC and run it there using off the
    self PC memory tools.

    Hth,
    Bill Pringlemeir.

    --
    He who does not bellow the truth when he knows the truth makes himself
    the accomplice of liars and forgers. - Charles Peguy

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

+ Reply to Thread