How to Get in Script Whether Valgrind Found Memory Leaks

How to get in script whether valgrind found memory leaks?

You seem to be looking for the --error-exitcode option.

Since it defaults to 0, the return code from Valgrind is the same as that of the process. Set it to a non-zero value instead.

From Valgrind core manual:

--error-exitcode=<number> [default: 0]

Specifies an alternative exit code to return if Valgrind reported any errors in the run. When set to the default value (zero), the
return value from Valgrind will always be the return value of the
process being simulated. When set to a nonzero value, that value is
returned instead, if Valgrind detects any errors. This is useful for
using Valgrind as part of an automated test suite, since it makes it
easy to detect test cases for which Valgrind has reported errors, just
by inspecting return codes.

Getting Valgrind to detect memory leaks from C++ program called by Python Script:

You want to use:

  --trace-children=yes

in your valgrind command line. Alternatively if you don't care about the python script all you can launch your subprocess with valgrind from within the script:

subprocess.call("valgrind --track-origins=yes --leak-check=full -v ./a.out")

How detect whether running under valgrind in make file or shell script?

from a shell:

grep -q '/valgrind' /proc/$$/maps && echo "valgrindage"

This determines if the valgrind preloaded libraries are present in address map of the process. This is reasonably effective, but if you happen to have a non-valgrind related library that shares the '/valgrind' moniker then you will get a false positive (unlikely).

[I changed the grep pattern from vg_preload to /valgrind, as testing on Debian/Ubuntu revealed that the library name was different, while a directory match of valgrind is most likely to succeed.]

Bash script detect memory leaks of C++ programs

Is there any way to detect whether any memory leaks occurred (from the script)?

You can look at the process exit code.

Address Sanitizer will force the program to exit with error code if leaks are detected. This assumes that the program itself correctly exits with error code 0.

Basically I want the aggregate times of those executions that did not leak and disregard those that did.

Measuring time of an instrumented program is pointless.

Valgrind detects memory leak despite the fact memory has been freed

This is your problem:

strBuffer = realloc(strBuffer, numEx);

If your call to realloc() fails, then it returns a null pointer, but does not free the original memory allocation.

You need to check the return value first, then assign it to the original pointer if successful:

char *tmpBuffer = realloc(strBuffer, numEx);
if (!tmpBuffer) {
  free(strBuffer);
  puts("realloc() failed");
  exit(1);
}
else {
  strBuffer = tmpBuffer;
}

---

There are a few other issues with your code, including:

• If strBuffer is NULL, then there is no point passing it to free().

• sizeof() is not a runtime function, so it has no idea how much memory was allocated.

• strBuffer = malloc(sizeof(char)*maxS+1); is a bit sloppy. I think you meant strBuffer = malloc(sizeof(char)*(maxS+1));, but you could just have put strBuffer = malloc(maxS+1); since sizeof(char) is 1 by definition.

`bash` is leaking memory, where do I report it?

As mentioned by @oguz_ismail in the comments, bug-bash@gnu.org is the appropriate place to report the bug.

However, a certain format for the email is required/requested, when you need to report a bug.

All bug reports should include:

• The version number of Bash.
• The hardware and operating system.
• The compiler used to compile Bash.
• A description of the bug behaviour.
• A short script or ‘recipe’ which exercises the bug and may be used to reproduce it.

You can find ALL the details at:
https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html

Finally, there is a helper script built into bash itself. Call bashbug from the command line, and it will populate most of the requirements, leaving you to fill out the description and the steps required to reproduce the bug.

$ bashbug

GNU nano 5.2                                                               /tmp/bbug.1414628/bbug1                                                                          
From: zak
To: bug-bash@gnu.org
Subject: [50 character or so descriptive subject here (for reference)]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-SmNvvg/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-secu>
uname output: Linux pop-os 5.11.0-7614-generic #15~1618626693~20.10~ecb25cd-Ubuntu SMP Thu Apr 22 16:00:45 UTC  x86_64 x86_64 x86_64 GNU/Linux
...

Once you have filled in the template, you will be prompted if you would like to send the email. It's okay if you don't have an email client connected, it will store the completed form at ~/dead.bashbug and you can copy paste it into your email client.

Valgind: non-zero exit code only if memory is definitely lost

I suspect the exit status 1 comes from the program itself. I can reproduce this with:

$ valgrind --error-exitcode=1 --tool=memcheck --leak-check=full \
  --errors-for-leak-kinds=definite --show-leak-kinds=definite \
  --track-origins=yes /bin/false

This does not look like something that can be changed in the current sources:

   case VgSrc_ExitProcess: /* the normal way out (Darwin) */
      /* Change the application return code to user's return code,
         if an error was found */
      if (VG_(clo_error_exitcode) > 0 
          && VG_(get_n_errs_found)() > 0) {
         VG_(client_exit)( VG_(clo_error_exitcode) );
      } else {
         /* otherwise, return the client's exit code, in the normal
            way. */
         VG_(client_exit)( VG_(threads)[tid].os_state.exitcode );
      }

And this exitcode member is set from the sys_exit_group wrapper in coregrind/m_syswrap/syswrap-linux.c, without any way to tweak it.

Considering this, I think your best bet (without patching valgrind) is to select an exit status different from any exit status your program might use, and use that as an indicator of a valgrind error.

Memory leak when C program ran from bash script

valgrind ./run will debug the shell and not your program.

Take a look at the output, see how it mentions (e.g.)

==4518== by 0x41C482: main (in /usr/bin/bash)

_{[Emphasis mine]}

If you want to debug your program, you need to run valgrind in the script:

arg1=thing1
arg2=thing2

valgrind ./Coupled $thing1 $thing2

---

Related Topics