SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Just launch valgrind: valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all -v <application> SOFTWARE/OS VERSIONS Linux/OPENWRT. Using 3.22 valgrind. arch all 1 arch noarch 1 arch mipsel_24kc 10 ADDITIONAL INFORMATION I tried using valgrind on ARM and it works perfectly. But on mipsel, i can't use it. Logs: valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all -v modbus_server -s modbus ==15521== Memcheck, a memory error detector ==15521== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==15521== Using Valgrind-3.22.0-bd4db67b1d-20231031 and LibVEX; rerun with -h for copyright info ==15521== Command: modbus_server -s modbus ==15521== --15521-- Valgrind options: --15521-- --tool=memcheck --15521-- --leak-check=full --15521-- --show-leak-kinds=all --15521-- -v --15521-- Contents of /proc/version: --15521-- Linux version 5.10.206 (app@runner-ju9hssqs-project-352-concurrent-0) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 8.4.0 r16279-5cc0535800) 8.4.0, GNU ld (GNU Binutils) 2.34) #0 SMP Tue Jan 9 12:59:51 2024 --15521-- --15521-- Arch and hwcaps: MIPS32, LittleEndian, MIPS-baseline-dsp --15521-- Page sizes: currently 4096, max supported 65536 --15521-- Valgrind library directory: /usr/lib/valgrind --15521-- Reading syms from /usr/sbin/modbus_server --15521-- Reading syms from /lib/libc.so --15521-- Reading syms from /usr/lib/valgrind/memcheck-mips32-linux --15521-- object doesn't have a dynamic symbol table --15521-- Scheduler: using generic scheduler lock implementation. --15521-- Reading suppressions file: /usr/lib/valgrind/default.supp ==15521== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-15521-by-root-on-??? ==15521== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-15521-by-root-on-??? ==15521== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-15521-by-root-on-??? ==15521== ==15521== TO CONTROL THIS PROCESS USING vgdb (which you probably ==15521== don't want to do, unless you know exactly what you're doing, ==15521== or are doing some strange experiment): ==15521== /usr/lib/valgrind/../../bin/vgdb --pid=15521 ...command... ==15521== ==15521== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==15521== /path/to/gdb modbus_server ==15521== and then give GDB the following command ==15521== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=15521 ==15521== --pid is optional if only one valgrind process is running ==15521== --15521-- Reading syms from /usr/lib/valgrind/vgpreload_core-mips32-linux.so --15521-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-mips32-linux.so --15521-- REDIR: 0x4030398 (NONE:free) redirected to 0x48cd564 (free) ==15521== Invalid read of size 4 ==15521== at 0x48CD578: free (vg_replace_malloc.c:985) ==15521== by 0x408AFEC: map_library (dynlink.c:774) ==15521== by 0x408C8D4: load_library (dynlink.c:1090) ==15521== by 0x408DC3C: load_preload (dynlink.c:1272) ==15521== by 0x408DC3C: __dls3 (dynlink.c:1844) ==15521== by 0x408D248: __dls2 (dynlink.c:1650) ==15521== by 0x40126CC: ??? (in /lib/libc.so) ==15521== Address 0x260c8 is not stack'd, malloc'd or (recently) free'd ==15521== ==15521== ==15521== Process terminating with default action of signal 11 (SIGSEGV) ==15521== Access not within mapped region at address 0x260C8 ==15521== at 0x48CD578: free (vg_replace_malloc.c:985) ==15521== by 0x408AFEC: map_library (dynlink.c:774) ==15521== by 0x408C8D4: load_library (dynlink.c:1090) ==15521== by 0x408DC3C: load_preload (dynlink.c:1272) ==15521== by 0x408DC3C: __dls3 (dynlink.c:1844) ==15521== by 0x408D248: __dls2 (dynlink.c:1650) ==15521== by 0x40126CC: ??? (in /lib/libc.so) ==15521== If you believe this happened as a result of a stack ==15521== overflow in your program's main thread (unlikely but ==15521== possible), you can try to increase the size of the ==15521== main thread stack using the --main-stacksize= flag. ==15521== The main thread stack size used in this run was 8388608. ==15521== ==15521== HEAP SUMMARY: ==15521== in use at exit: 0 bytes in 0 blocks ==15521== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==15521== ==15521== All heap blocks were freed -- no leaks are possible ==15521== ==15521== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==15521== ==15521== 1 errors in context 1 of 1: ==15521== Invalid read of size 4 ==15521== at 0x48CD578: free (vg_replace_malloc.c:985) ==15521== by 0x408AFEC: map_library (dynlink.c:774) ==15521== by 0x408C8D4: load_library (dynlink.c:1090) ==15521== by 0x408DC3C: load_preload (dynlink.c:1272) ==15521== by 0x408DC3C: __dls3 (dynlink.c:1844) ==15521== by 0x408D248: __dls2 (dynlink.c:1650) ==15521== by 0x40126CC: ??? (in /lib/libc.so) ==15521== Address 0x260c8 is not stack'd, malloc'd or (recently) free'd ==15521== ==15521== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault
You need to understand where the invalid free is happening. Seeing a redirect for free but not malloc is unusual.
(In reply to Paul Floyd from comment #1) > You need to understand where the invalid free is happening. > > Seeing a redirect for free but not malloc is unusual. you mean in my code, or in libc?
The redirect is likely to be from either the link loader ld.so or from libc. If it is from ld.so it might be a phony implmentation in which malloc returns some global or stack memory and free does nothing. Possibly there is a bug in ld.so where such a no-op phony free is getting called on a pointer not "allocated" by the matching phony malloc.
Updated musl. Now i am getting: ==12556== Memcheck, a memory error detector ==12556== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==12556== Using Valgrind-3.22.0-bd4db67b1d-20231031 and LibVEX; rerun with -h for copyright info ==12556== Command: modbus_server ==12556== --12556-- Valgrind options: --12556-- -v --12556-- Contents of /proc/version: --12556-- Linux version 5.10.199 (app@runner-ffjpezdj-project-352-concurrent-0) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 8.4.0 r16279-5cc0535800) 8.4.0, GNU ld (GNU Binutils) 2.34) #0 SMP Thu Jan 4 12:38:22 2024 --12556-- --12556-- Arch and hwcaps: MIPS32, LittleEndian, MIPS-baseline-dsp --12556-- Page sizes: currently 4096, max supported 65536 --12556-- Valgrind library directory: /usr/lib/valgrind --12556-- Reading syms from /usr/sbin/modbus_server --12556-- Reading syms from /lib/libc.so --12556-- Reading syms from /usr/lib/valgrind/memcheck-mips32-linux --12556-- object doesn't have a dynamic symbol table --12556-- Scheduler: using generic scheduler lock implementation. --12556-- Reading suppressions file: /usr/lib/valgrind/default.supp ==12556== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-12556-by-root-on-??? ==12556== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-12556-by-root-on-??? ==12556== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-12556-by-root-on-??? ==12556== ==12556== TO CONTROL THIS PROCESS USING vgdb (which you probably ==12556== don't want to do, unless you know exactly what you're doing, ==12556== or are doing some strange experiment): ==12556== /usr/lib/valgrind/../../bin/vgdb --pid=12556 ...command... ==12556== ==12556== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==12556== /path/to/gdb modbus_server ==12556== and then give GDB the following command ==12556== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=12556 ==12556== --pid is optional if only one valgrind process is running ==12556== --12556-- Reading syms from /usr/lib/valgrind/vgpreload_core-mips32-linux.so --12556-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-mips32-linux.so ==12556== Conditional jump or move depends on uninitialised value(s) ==12556== at 0x4080018: stpcpy (stpcpy.c:20) ==12556== by 0x40805CC: strcpy (strcpy.c:5) ==12556== by 0x40952B8: load_library (dynlink.c:1224) ==12556== by 0x40955C0: load_direct_deps (dynlink.c:1283) ==12556== by 0x40955C0: load_deps (dynlink.c:1300) ==12556== by 0x40955C0: load_deps (dynlink.c:1296) ==12556== by 0x4095ED8: __dls3 (dynlink.c:1962) ==12556== by 0x4095A88: __dls2 (dynlink.c:1765) ==12556== by 0x4012B6C: ??? (in /lib/libc.so) ==12556== vex: priv/guest_mips_toIR.c:23393 (disInstr_MIPS_WRK_10): Assertion `mode64' failed. vex storage: T total 48294856 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==12556== at 0x580B7DB4: show_sched_status_wrk (in /usr/lib/valgrind/memcheck-mips32-linux) ==12556== by 0x580B7DA0: show_sched_status_wrk (in /usr/lib/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 12556) ==12556== at 0x4040DD: main (modbusd.c:71) client stack range: [0x7E83C000 0x7E83CFFF] client SP: 0x7E83CCC8 valgrind stack range: [0x426D2000 0x427D1FFF] top usage: 11980 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.