#70 -fsanitize flag support

[Bohdan Tkhir]

Hi !
When I am compiling Ngpsice with -fsanitize=address LD and C Flags I'm getting errors like ;
ngspice/src/misc/alloc.c:111: undefined reference to rpl_realloc

It's great tool , can it be supported ?

Thank you!

[Holger Vogt]

There are no plans to do so.

What about running ngspice wit valgrind? This is what I use to find memory leaks or check for read beyond bounds.

[Holger Vogt]

As a quick check I have just compiled ngspice with the -fsanitize=address flag on macOS Catalina, 10.15. It compiles and links out-of-the-box, and runnng ngspice yields some additional output. So it might be a question of an appropriate setup of the compile environment, not of additional tweaking ngspice.

[Bohdan Tkhir]

Sorry for long pause
About Valgrind - it's external app , it's great possibility to check critical things like incorrect work with event_alloc or analog_allog "out-of-the-box".
So it just propose to see errors in terminal just in time.
Thanks for reply anyway

[Holger Vogt]

I have been able to compile ngspice on Linux (SUSE 15.1, 64 bit, at least for now until it started compiling the code models, when it detected a memory leak in cmpp and stopped) by editing ngspice/configure.ac lines 635 ff., commenting out #AC_FUNC_MALLOC and #AC_FUNC_REALLOC:

# Checks for library functions.
AC_FUNC_ALLOCA
#AC_FUNC_MALLOC
#AC_FUNC_REALLOC
AC_FUNC_CLOSEDIR_VOID
AC_FUNC_SELECT_ARGTYPES
AC_FUNC_SETVBUF_REVERSED
AC_FUNC_VPRINTF

This has been reported in https://github.com/maxmind/libmaxminddb/issues/144.

Do you know a switch to tell sanitize just to move on, not to stop?

[Bohdan Tkhir]

You can try to set ASAN_OPTIONS=halt_on_error=0 env variable.
But it's experimental thing, so it can be unstable.
I will try to do one thing with Ngspice cinfig file and place results here

[Bohdan Tkhir]

Yes, it worked!
I've removed #define malloc rplmalloc and #define realloc rplrealloc from config.h to skip errors with "undefined reference". Is it dangerous or it's hard to tell?

To continue compiling during leaks just before compiling type :
export ASAN_OPTIONS=halt_on_error=0

[Francesco Lannutti]

Hi guys,
so, do we have a bug in NGSPICE to use this feature or not? I didn't understand the outcome here.

Thank you,
Fra

[Holger Vogt]

It is about AC_FUNC_MALLOC, see https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Particular-Functions.html.

Cited from this manual:

— Macro: AC_FUNC_MALLOC
If the malloc function is compatible with the GNU C library malloc (i.e., ‘malloc (0)’ returns a valid pointer), define HAVE_MALLOC to 1. Otherwise define HAVE_MALLOC to 0, ask for an AC_LIBOBJ replacement for ‘malloc’, and define malloc to rpl_malloc so that the native malloc is not used in the main project.

Typically, the replacement file malloc.c should look like (note the ‘#undef malloc’):


     #if HAVE_CONFIG_H
     # include <config.h>
     #endif
     #undef malloc

     #include <sys/types.h>

     void *malloc ();

     /* Allocate an N-byte block of memory from the heap.
        If N is zero, allocate a 1-byte block.  */

     void *
     rpl_malloc (size_t n)
     {
       if (n == 0)
         n = 1;
       return malloc (n);
     }

We check for the GNU compatible malloc, and obviously normally (Linux, Cygwin, MINGW, macOS ...) it is. With the -fsanitize option, it seems to not be compatible, because the test fails. For this case we should have provided the function as cited from the website above. Same for realloc().

If we never use malloc(n) with n=0, then we do not need to do the AC_FUNC_MALLOC check. If we always have a GNU compatible malloc(), again we don't need it. If I look at alloc.c, we use tmalloc(n) which checks for n==0, returning NULL, so not being GNU compatible (and thus not needing AC_FUNC_MALLOC ). There are some spurious plain malloc() in the code (XSPICE, or newly added code from Jim). Probably we can skip AC_FUNC_MALLOC.

[Francesco Lannutti]

Hi Holger,
ok, but can we assume we don't enter into this case or do we force a code style to avoid such situation?

Thank you,
Fra