valgrind2

{root@Pineapple:~_1}$ valgrind --leak-check=full --log-file=./valgrind2.log -v wash -i wlan1mon^C
{root@Pineapple:~_1}$ cat valgrind2.log
==2899== Memcheck, a memory error detector
==2899== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2899== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun with -h for copyright info
==2899== Command: wash -i wlan1mon
==2899== Parent PID: 25551
==2899==
--2899--
--2899-- Valgrind options:
--2899--    --leak-check=full
--2899--    --log-file=./valgrind2.log
--2899--    -v
--2899-- Contents of /proc/version:
--2899--   Linux version 4.14.134 (@4708b150a871) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r0+10558-a2cbcfcdff)) #0 Sat Aug 31 00:30:39 2019
--2899--
--2899-- Arch and hwcaps: MIPS32, BigEndian, MIPS-baseline-dspr2
--2899-- Page sizes: currently 4096, max supported 65536
--2899-- Valgrind library directory: /usr/lib/valgrind
--2899-- Reading syms from /usr/bin/wash
--2899-- Reading syms from /lib/libc.so
--2899-- Scheduler: using generic scheduler lock implementation.
--2899-- Reading suppressions file: /usr/lib/valgrind/default.supp
==2899== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-2899-by-root-on-???
==2899== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-2899-by-root-on-???
==2899== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-2899-by-root-on-???
==2899==
==2899== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2899== don't want to do, unless you know exactly what you're doing,
==2899== or are doing some strange experiment):
==2899==   /usr/lib/valgrind/../../bin/vgdb --pid=2899 ...command...
==2899==
==2899== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2899==   /path/to/gdb wash
==2899== and then give GDB the following command
==2899==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=2899
==2899== --pid is optional if only one valgrind process is running
==2899==
--2899-- Reading syms from /usr/lib/libpcap.so.1
==2899== Conditional jump or move depends on uninitialised value(s)
==2899==    at 0x4072884: stpcpy (stpcpy.c:20)
==2899==    by 0x4072E34: strcpy (strcpy.c:5)
==2899==    by 0x4084768: load_library (dynlink.c:1130)
==2899==    by 0x4084A6C: load_direct_deps (dynlink.c:1189)
==2899==    by 0x4084A6C: load_deps (dynlink.c:1206)
==2899==    by 0x4084A6C: load_deps (dynlink.c:1202)
==2899==    by 0x4085280: __dls3 (dynlink.c:1842)
==2899==    by 0x4084E74: __dls2 (dynlink.c:1647)
==2899==    by 0x400D8AC: ??? (in /lib/libc.so)
==2899==
--2899-- Reading syms from /lib/libgcc_s.so.1
vex mips->IR: unhandled instruction bytes: 0x4 0x99 0x47 0x9A

vex: priv/guest_mips_toIR.c:1304 (jmp_lit32): Assertion `dres->whatNext == Dis_Continue' failed.
vex storage: T total 31918008 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==2899==    at 0x5803DB98: ??? (in /usr/lib/valgrind/memcheck-mips32-linux)
==2899==    by 0x5803DB84: ??? (in /usr/lib/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 2899)
==2899==    at 0x409B61: main (main.c:9)
client stack range: [0x7EE1B000 0x7EE1BFFF] client SP: 0x7EE1BC78
valgrind stack range: [0x42CC6000 0x42DC5FFF] top usage: 9484 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.