Bjørn Mork <bj...@mork.no> writes: > Aleksander Morgado <aleksan...@aleksander.es> writes: > >>> Bu can't I just run valgrind on the MIPS CPU? Any hints on how to use >>> valgrind? It's one of those tools I've been thing that I should >>> explore, but never have.. >>> >> >> I have no idea if you can run valgrind on that setup, just give it a >> try maybe? If we're interested in finding invalid read/writes in >> memory (ignoring leaks), the valgrind call would be basically this: >> # G_SLICE=always-malloc valgrind --log-file=valgrind.log >> /usr/sbin/ModemManager --debug >> >> The valgrind.log file would contain the errors reported. > > OK, that seemed too easy. Don't know how to progress here: > > root@finn:~# G_SLICE=always-malloc valgrind --log-file=valgrind.log > /tmp/ModemManager --debug > Illegal instruction
Or maybe it wasn't? I should have looked at the log: root@finn:~# G_SLICE=always-malloc valgrind --log-file=/tmp/valgrind.log /usr/sbin/ModemManager --debug Illegal instruction root@finn:~# cat /tmp/valgrind.log ==7163== Memcheck, a memory error detector ==7163== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7163== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==7163== Command: /usr/sbin/ModemManager --debug ==7163== Parent PID: 4753 ==7163== ==7163== Conditional jump or move depends on uninitialised value(s) ==7163== at 0x4079498: ??? (in /lib/libc.so) ==7163== by 0x408A4CC: ??? (in /lib/libc.so) ==7163== ==7163== Conditional jump or move depends on uninitialised value(s) ==7163== at 0x4078A7C: ??? (in /lib/libc.so) ==7163== by 0x4078FA0: ??? (in /lib/libc.so) ==7163== vex mips->IR: unhandled instruction bytes: 0x65 0x80 0xDA 0x6 ==7163== valgrind: Unrecognised instruction at address 0x4de9115. ==7163== at 0x4DE9115: g_cache_insert (in /usr/lib/libglib-2.0.so.0.6800.1) ==7163== by 0x4089440: ??? (in /lib/libc.so) ==7163== Your program just tried to execute an instruction that Valgrind ==7163== did not recognise. There are two possible reasons for this. ==7163== 1. Your program has a bug and erroneously jumped to a non-code ==7163== location. If you are running Memcheck and you just saw a ==7163== warning about a bad jump, it's probably your program's fault. ==7163== 2. The instruction is legitimate but Valgrind doesn't handle it, ==7163== i.e. it's Valgrind's fault. If you think this is the case or ==7163== you are not sure, please let us know and we'll try to fix it. ==7163== Either way, Valgrind will now raise a SIGILL signal which will ==7163== probably kill your program. ==7163== ==7163== Process terminating with default action of signal 4 (SIGILL) ==7163== Illegal opcode at address 0x4DE9115 ==7163== at 0x4DE9115: g_cache_insert (in /usr/lib/libglib-2.0.so.0.6800.1) ==7163== by 0x4089440: ??? (in /lib/libc.so) ==7163== ==7163== HEAP SUMMARY: ==7163== in use at exit: 0 bytes in 0 blocks ==7163== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==7163== ==7163== All heap blocks were freed -- no leaks are possible ==7163== ==7163== Use --track-origins=yes to see where uninitialised values come from ==7163== For lists of detected and suppressed errors, rerun with: -s ==7163== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) I guess this could point to the problem? Or just mean that only crazy people run valgrind on MIPS ;-) Bjørn _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
