1. Forum
  2. Usenet
  3. COMP.SYS.TANDEM

  • Looking for a Memory Check Tool

    From Randall@21:1/5 to All on Tue Dec 7 13:49:16 2021
    Hi All,

    I have an Open Source (native C) project that has some memory issue. It is generating a SIGSEGV if a free() is called on a specific pointer. This is usually the result of the heap being corrupted. Sadly, there are about 1M calls to malloc() and free()
    done in this project. Does anyone know a tool that can catch C pointer and heap issues?

    TIA,
    Randall

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to Randall on Tue Dec 7 13:50:16 2021
    On Tuesday, December 7, 2021 at 4:49:17 p.m. UTC-5, Randall wrote:
    Hi All,

    I have an Open Source (native C) project that has some memory issue. It is generating a SIGSEGV if a free() is called on a specific pointer. This is usually the result of the heap being corrupted. Sadly, there are about 1M calls to malloc() and free()
    done in this project. Does anyone know a tool that can catch C pointer and heap issues?

    TIA,
    Randall

    Oh... and Valgrind is not an option because it depends on gcc, which does not work on NonStop. This is a Native OSS project.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JShepherd@21:1/5 to All on Wed Dec 8 17:05:55 2021
    In article <153cd7f7-0553-4f0b-8ad6-c57c6af203ebn@googlegroups.com>, rsbecker@nexbridge.com says...

    Hi All,

    I have an Open Source (native C) project that has some memory issue. It is = >generating a SIGSEGV if a free() is called on a specific pointer. This is u= >sually the result of the heap being corrupted. Sadly, there are about 1M ca= >lls to malloc() and free() done in this project. Does anyone know a tool th= >at can catch C pointer and heap issues?

    TIA,
    Randall


    Native inspect has an option to do malloc/free tracking and
    heap checking when using ZRTCDLL as a UL.

    Another option is to call heap_check_always(2);
    as the first thing in main(). There might be a ENV var
    to trigger that as well.

    Also, You should always have the define set

    add define =_ERASE_ON_FREE_,Class MAP, FILE ON

    as it causes the heap manager to init memory to a known pattern
    on a free() so dereferences after a free() can be easier to find.
    Having =_ERASE_ON_FREE_ set exposed a number of
    "reference after free" problems in early versiona ODBC/MX.


    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02784099

    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02131733

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to JShepherd on Wed Dec 8 12:13:01 2021
    On Wednesday, December 8, 2021 at 12:05:57 p.m. UTC-5, JShepherd wrote:
    In article <153cd7f7-0553-4f0b...@googlegroups.com>,
    rsbe...@nexbridge.com says...

    Hi All,

    I have an Open Source (native C) project that has some memory issue. It is = >generating a SIGSEGV if a free() is called on a specific pointer. This is u= >sually the result of the heap being corrupted. Sadly, there are about 1M ca= >lls to malloc() and free() done in this project. Does anyone know a tool th= >at can catch C pointer and heap issues?

    TIA,
    Randall
    Native inspect has an option to do malloc/free tracking and
    heap checking when using ZRTCDLL as a UL.

    Another option is to call heap_check_always(2);
    as the first thing in main(). There might be a ENV var
    to trigger that as well.

    Also, You should always have the define set

    add define =_ERASE_ON_FREE_,Class MAP, FILE ON

    as it causes the heap manager to init memory to a known pattern
    on a free() so dereferences after a free() can be easier to find.
    Having =_ERASE_ON_FREE_ set exposed a number of
    "reference after free" problems in early versiona ODBC/MX.


    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02784099

    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02131733

    Thanks. Sadly, nothing was found out of this. All I get is a SIGSEGV during the atexit() processing. It's frustrating.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gustavo Cavazos@21:1/5 to Randall on Fri Dec 10 12:09:03 2021
    Hi Randall.

    Take a look at:
    http://www.hexco.de/rmdebug/

    It might help.

    gc

    On Wednesday, December 8, 2021 at 2:13:02 PM UTC-6, Randall wrote:
    On Wednesday, December 8, 2021 at 12:05:57 p.m. UTC-5, JShepherd wrote:
    In article <153cd7f7-0553-4f0b...@googlegroups.com>,
    rsbe...@nexbridge.com says...

    Hi All,

    I have an Open Source (native C) project that has some memory issue. It is =
    generating a SIGSEGV if a free() is called on a specific pointer. This is u=
    sually the result of the heap being corrupted. Sadly, there are about 1M ca=
    lls to malloc() and free() done in this project. Does anyone know a tool th=
    at can catch C pointer and heap issues?

    TIA,
    Randall
    Native inspect has an option to do malloc/free tracking and
    heap checking when using ZRTCDLL as a UL.

    Another option is to call heap_check_always(2);
    as the first thing in main(). There might be a ENV var
    to trigger that as well.

    Also, You should always have the define set

    add define =_ERASE_ON_FREE_,Class MAP, FILE ON

    as it causes the heap manager to init memory to a known pattern
    on a free() so dereferences after a free() can be easier to find.
    Having =_ERASE_ON_FREE_ set exposed a number of
    "reference after free" problems in early versiona ODBC/MX.


    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02784099

    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02131733
    Thanks. Sadly, nothing was found out of this. All I get is a SIGSEGV during the atexit() processing. It's frustrating.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randall@21:1/5 to gustavo...@nuwavetech.com on Sat Dec 11 10:40:01 2021
    On Friday, December 10, 2021 at 3:09:04 p.m. UTC-5, gustavo...@nuwavetech.com wrote:
    Hi Randall.

    Take a look at:
    http://www.hexco.de/rmdebug/

    It might help.

    gc
    On Wednesday, December 8, 2021 at 2:13:02 PM UTC-6, Randall wrote:
    On Wednesday, December 8, 2021 at 12:05:57 p.m. UTC-5, JShepherd wrote:
    In article <153cd7f7-0553-4f0b...@googlegroups.com>, rsbe...@nexbridge.com says...

    Hi All,

    I have an Open Source (native C) project that has some memory issue. It is =
    generating a SIGSEGV if a free() is called on a specific pointer. This is u=
    sually the result of the heap being corrupted. Sadly, there are about 1M ca=
    lls to malloc() and free() done in this project. Does anyone know a tool th=
    at can catch C pointer and heap issues?

    TIA,
    Randall
    Native inspect has an option to do malloc/free tracking and
    heap checking when using ZRTCDLL as a UL.

    Another option is to call heap_check_always(2);
    as the first thing in main(). There might be a ENV var
    to trigger that as well.

    Also, You should always have the define set

    add define =_ERASE_ON_FREE_,Class MAP, FILE ON

    as it causes the heap manager to init memory to a known pattern
    on a free() so dereferences after a free() can be easier to find.
    Having =_ERASE_ON_FREE_ set exposed a number of
    "reference after free" problems in early versiona ODBC/MX.


    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02784099

    https://support.hpe.com/hpesc/public/docDisplay? docLocale=en_US&docId=c02131733
    Thanks. Sadly, nothing was found out of this. All I get is a SIGSEGV during the atexit() processing. It's frustrating.

    Thanks Gustavo. I opened a case with GNSC on this one. It might be a real thing.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)