SUMMARY *** RUN command "valgrind --leak-check=full --show-reachable=yes --trace-children=yes /usr/bin/nr_ping_monitor&" report error: admin@OpenWrt:/# valgrind --leak-check=full --show-reachable=yes --trace-childre n=yes /usr/bin/nr_ping_monitor& admin@OpenWrt:/# ==5820== Memcheck, a memory error detector ==5820== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==5820== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==5820== Command: /usr/bin/nr_ping_monitor ==5820== ==5820== Conditional jump or move depends on uninitialised value(s) ==5820== at 0x4074630: ??? (in /lib/libc.so) ==5820== by 0x4085A9C: ??? (in /lib/libc.so) ==5820== ==5820== Conditional jump or move depends on uninitialised value(s) ==5820== at 0x4073ABC: ??? (in /lib/libc.so) ==5820== by 0x4074088: ??? (in /lib/libc.so) ==5820== ==5820== Conditional jump or move depends on uninitialised value(s) ==5820== at 0x4074650: ??? (in /lib/libc.so) ==5820== by 0x4085A9C: ??? (in /lib/libc.so) ==5820== vex: priv/guest_mips_toIR.c:23393 (disInstr_MIPS_WRK_10): Assertion `mode64' failed. vex storage: T total 42549728 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==5820== at 0x5803F988: ??? (in /usr/lib/valgrind/memcheck-mips32-linux) ==5820== by 0x5803F974: ??? (in /usr/lib/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 5820) ==5820== at 0x48E3C79: ??? (in /lib/libuci.so) ==5820== by 0x48FDF00: ??? (in /usr/lib/libjet_nvram.so) client stack range: [0x7E840000 0x7E841FFF] client SP: 0x7E840C60 valgrind stack range: [0x425C5000 0x426C4FFF] top usage: 5752 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. *** STEPS TO REPRODUCE 1. run valgrind to check memory leak OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: admin@OpenWrt:/# cat /proc/version Linux version 4.14.195 (jli@ubuntu) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11208-ce6496d796)) #0 SMP Sun Sep 6 16:19:39 2020 admin@OpenWrt:/# (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
arch: mips32 sourceCode: http://sourceware.org/pub/valgrind/ version: 3.20.0.tar.bz2 sha256sum: 8536c031dbe078d342f121fa881a9ecd205cb5a78e639005ad570011bdb9f3c6
Created attachment 158474 [details] with the "-v -v -d -d" options to run the valgrind
The code is case 0x0A: { /* LDL */ /* Load Doubleword Left - LDL; MIPS64 */ vassert(mode64); Can you tell whether it is expected to execute this opcode on mips32?
It should not go to the case, I don't know why it goes to the case on my mips32 OS.
Is there any progress? What can I do?