Не удается запустить Valgrind в программе Veins/omnet, работающей в кластере на базе Linux (ОС Cent)?

Я использую OMNeT++(4.6) и Veins(4.4) для разработки своего проекта. После обновления в венах MAC уровня программа вылетает и я хочу найти место ошибки. Поскольку я не могу найти ошибку с помощью отладки, я попытался установить Valgrind для любых утечек памяти. Я успешно установил valgrind в кластере и проверил с помощью следующей команды

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

Я проверил valgrind с помощью простой программы утечки памяти c, и valgrind отлично работает в кластере и генерирует выходные данные.

Обычно я запускаю симуляции вен в кластере с помощью следующей команды. В командной строке я ввожу расположение файла omnet.ini и запускаю следующую команду.

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

Файл run_release получен из вен run и имеет следующий код

#!/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)

Когда я попытался включить valgrind для проверки симуляции вен, используя следующие параметры команды.

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

Во всех случаях в файле valgrind-out.txt создается следующий файл журнала valgrind.

==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 ([email protected]) (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)

Из этого журнала я понимаю, что я не могу использовать Valgrind для проверки ошибок в моей симуляции Veins, хотя я могу вызвать ее. Я пробовал запускать Valgrind как на работающей, так и на аварийной версии Veins, но вывод лога один и тот же. В то время как симуляция успешно работает с рабочей версией Veins, она продолжает падать с аварийной версией. Как я могу эффективно использовать Valgrind для определения причины сбоя в симуляции Veins?

может кто-нибудь помочь определить правильную команду или я что-то упустил?