无法在基于 Linux 的集群（cent OS）上运行的 Veins/o.net 程序上执行 Valgrind？

Question

I am using OMNeT++(4.6) and Veins(4.4) for my project development. After an update in the veins MAC level, the program is crashing and I want to locate the point of error. Since I cannot find the error using debugging, I tried to install Valgrind for any memory leaks. I sucessfully installed the valgrind in the cluster and I verified using the following command

command:
$ valgrind --version
output:
valgrind-3.20.0

I checked valgrind with a simple c memory leak program and valgrind runs perfect in the cluster and generates output.

I usually run my veins simulations in the cluster using the run following command. In the command line, I enter to the location of the o.net.ini file and run following command.

command:
/../veins/run_release omnetpp.ini -c Highway

The file run_release is derived from veins run and has the following code

#!/usr/bin/env python
run_libs = ['src/veins']
run_neds = ['src/veins']

# ^-- contents of out/config.py go here

"""
Runs Veins simulation in current directory
"""

import sys
import os

def relpath(s):
    veins_root = os.path.dirname(os.path.realpath(__file__))
    return os.path.relpath(os.path.join(veins_root, s), '.')

run_libs = [relpath(s) for s in run_libs]
run_neds = [relpath(s) for s in run_neds] + ['.']

lib_flags = ['-l%s' % s for s in run_libs]
ned_flags = ['-n' + ';'.join(run_neds)]

prefix = []

cmdline = prefix + ['/../omnetpp-4.6/bin/opp_run_release'] + lib_flags + ned_flags + sys.argv[1:]

os.execvp('env', ['env'] + cmdline)

When i tried to enable valgrind to check my veins simulation using the following command options.

command option 1:
valgrind -v --tool=memcheck --leak-check=yes --log-file=valgrind-out.txt /../veins/run_release omnetpp.ini -c Highway

command option 2:
valgrind -v --tool=memcheck --leak-check=yes --log-file=valgrind-out.txt /media/home/gokulnath/workspaceOMNET/VeinsBoschUMH/run_release omnetpp.ini -c Highway;. -u Cmdenv

command option 3:
~/valgrind/bin/valgrind -v --tool=memcheck --leak-check=full --track-origins=yes --log-file=valgrind-out.txt /media/home/gokulnath/workspaceOMNET/VeinsBoschUMH/run_release omnetpp.ini -c Highway;. -u Cmdenv

In all the cases, the following valgrind log file is generated in the valgrind-out.txt

==19038== Memcheck, a memory error detector
==19038== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==19038== Using Valgrind-3.20.0-5147d671e4-20221024 and LibVEX; rerun with -h for copyright info
==19038== Command: /../veins/run_release omnetpp.ini -c Highway
==19038== Parent PID: 18758
==19038== 
--19038-- 
--19038-- Valgrind options:
--19038--    -v
--19038--    --tool=memcheck
--19038--    --leak-check=full
--19038--    --track-origins=yes
--19038--    --log-file=valgrind-out.txt
--19038-- Contents of /proc/version:
--19038--   Linux version 3.10.0-693.21.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Wed Mar 7 19:03:37 UTC 2018
--19038-- 
--19038-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-sse3
--19038-- Page sizes: currently 4096, max supported 4096
--19038-- Valgrind library directory: /../valgrind/libexec/valgrind
--19038-- Reading syms from /usr/bin/env
--19038--    object doesn't have a symbol table
--19038-- Reading syms from /usr/lib64/ld-2.17.so
--19038-- Reading syms from /../valgrind/libexec/valgrind/memcheck-amd64-linux
--19038--    object doesn't have a dynamic symbol table
--19038-- Scheduler: using generic scheduler lock implementation.
--19038-- Reading suppressions file: /../valgrind/libexec/valgrind/default.supp
==19038== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-19038-by-..
==19038== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-19038-by-..
==19038== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-19038-..
==19038== 
==19038== TO CONTROL THIS PROCESS USING vgdb (which you probably
==19038== don't want to do, unless you know exactly what you're doing,
==19038== or are doing some strange experiment):
==19038==   /../valgrind/libexec/valgrind/../../bin/vgdb --pid=19038 ...command...
==19038== 
==19038== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==19038==   /path/to/gdb /../veins/run_release
==19038== and then give GDB the following command
==19038==   target remote | /../valgrind/libexec/valgrind/../../bin/vgdb --pid=19038
==19038== --pid is optional if only one valgrind process is running
==19038== 
--19038-- REDIR: 0x40192f0 (ld-linux-x86-64.so.2:strlen) redirected to 0x580cc9e5 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--19038-- REDIR: 0x40190c0 (ld-linux-x86-64.so.2:index) redirected to 0x580cc9ff (vgPlain_amd64_linux_REDIR_FOR_index)
--19038-- Reading syms from /../valgrind/libexec/valgrind/vgpreload_core-amd64-linux.so
--19038-- Reading syms from /../valgrind/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
==19038== WARNING: new redirection conflicts with existing -- ignoring it
--19038--     old: 0x040192f0 (strlen              ) R-> (0000.0) 0x580cc9e5 vgPlain_amd64_linux_REDIR_FOR_strlen
--19038--     new: 0x040192f0 (strlen              ) R-> (2007.0) 0x04c30b20 strlen
--19038-- REDIR: 0x4019270 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c31d10 (strcmp)
--19038-- REDIR: 0x4019e60 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c35da0 (mempcpy)
--19038-- Reading syms from /usr/lib64/libc-2.17.so
==19038== WARNING: new redirection conflicts with existing -- ignoring it
--19038--     old: 0x04ebc950 (memalign            ) R-> (1011.0) 0x04c2fdf2 memalign
--19038--     new: 0x04ebc950 (memalign            ) R-> (1017.0) 0x04c2fdc2 aligned_alloc
==19038== WARNING: new redirection conflicts with existing -- ignoring it
--19038--     old: 0x04ebc950 (memalign            ) R-> (1011.0) 0x04c2fdf2 memalign
--19038--     new: 0x04ebc950 (memalign            ) R-> (1017.0) 0x04c2fd95 aligned_alloc
==19038== WARNING: new redirection conflicts with existing -- ignoring it
--19038--     old: 0x04ebc950 (memalign            ) R-> (1011.0) 0x04c2fdf2 memalign
--19038--     new: 0x04ebc950 (memalign            ) R-> (1017.0) 0x04c2fdc2 aligned_alloc
==19038== WARNING: new redirection conflicts with existing -- ignoring it
--19038--     old: 0x04ebc950 (memalign            ) R-> (1011.0) 0x04c2fdf2 memalign
--19038--     new: 0x04ebc950 (memalign            ) R-> (1017.0) 0x04c2fd95 aligned_alloc
--19038-- REDIR: 0x4ec5f80 (libc.so.6:strcasecmp) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)
--19038-- REDIR: 0x4ec2d00 (libc.so.6:strnlen) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)
--19038-- REDIR: 0x4ec8250 (libc.so.6:strncasecmp) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)
--19038-- REDIR: 0x4ec5760 (libc.so.6:memset) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)
--19038-- REDIR: 0x4ec5710 (libc.so.6:memcpy@GLIBC_2.2.5) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)
--19038-- REDIR: 0x4ec46f0 (libc.so.6:__GI_strrchr) redirected to 0x4c304e0 (__GI_strrchr)
--19038-- REDIR: 0x4ec46b0 (libc.so.6:rindex) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)
--19038-- REDIR: 0x4ec11c0 (libc.so.6:__GI_strcmp) redirected to 0x4c31c20 (__GI_strcmp)
--19038-- REDIR: 0x4ec2c20 (libc.so.6:__GI_strlen) redirected to 0x4c30a80 (__GI_strlen)
--19038-- REDIR: 0x4ec2e20 (libc.so.6:__GI_strncmp) redirected to 0x4c31270 (__GI_strncmp)
--19038-- REDIR: 0x4ec1100 (libc.so.6:__GI_strchr) redirected to 0x4c30610 (__GI_strchr)
--19038-- REDIR: 0x4ec4df0 (libc.so.6:memchr) redirected to 0x4c31db0 (memchr)
--19038-- REDIR: 0x4ecc210 (libc.so.6:strchrnul) redirected to 0x4c358c0 (strchrnul)
--19038-- REDIR: 0x4ebc0c0 (libc.so.6:malloc) redirected to 0x4c2b110 (malloc)
--19038-- REDIR: 0x4ec5930 (libc.so.6:__GI_mempcpy) redirected to 0x4c35ad0 (__GI_mempcpy)
--19038-- REDIR: 0x4eca990 (libc.so.6:__GI_memcpy) redirected to 0x4c329c0 (__GI_memcpy)
--19038-- REDIR: 0x4ebc4c0 (libc.so.6:free) redirected to 0x4c2d696 (free)
--19038-- REDIR: 0x4edb600 (libc.so.6:__GI_strstr) redirected to 0x4c36030 (__strstr_sse2)
--19038-- REDIR: 0x4ebc5a0 (libc.so.6:realloc) redirected to 0x4c2fa7b (realloc)
--19038-- REDIR: 0x4ec5fe0 (libc.so.6:__GI___strcasecmp_l) redirected to 0x4c31840 (__GI___strcasecmp_l)
--19038-- REDIR: 0x4ec2d30 (libc.so.6:__GI_strnlen) redirected to 0x4c30a30 (__GI_strnlen)
--19038-- REDIR: 0x4ec5e20 (libc.so.6:__GI_stpcpy) redirected to 0x4c34660 (__GI_stpcpy)
--19038-- REDIR: 0x4ec2650 (libc.so.6:__GI_strcpy) redirected to 0x4c30c20 (__GI_strcpy)
--19038-- REDIR: 0x4ecc000 (libc.so.6:__GI___rawmemchr) redirected to 0x4c35920 (__GI___rawmemchr)
--19038-- REDIR: 0x4ec10c0 (libc.so.6:index) redirected to 0x4a247cf (_vgnU_ifunc_wrapper)

From this log I understand that I am unable to use Valgrind to check for errors in my Veins simulation even though I am able to call it. I have tried running Valgrind on both a working and a crashing version of Veins but am getting the same log output. While the simulation runs successfully with the working version of Veins, it continues to crash with the crashing version. How can I effectively use Valgrind to locate the cause of the crash in my Veins simulation?

can someone help to identify the correct command or am I missing something?

Answer 1

To execute valgrind update the run script. You can find the updated script in this link

As you can see in the script that you need to update the prefix

prefix = ['valgrind', '--tool=memcheck', '--leak-check=full', '--dsymutil=yes', '--log-file=valgrind.out']

This update will check your veins profram in valgrind.