SEGFAULT with MM HEAD when probing

[Aleksander Morgado]

> >>> 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 at 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 at finn:~# G_SLICE=always-malloc valgrind --log-file=/tmp/valgrind.log /usr/sbin/ModemManager --debug
> Illegal instruction
> root at 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 ;-)
>

I think it's the latter... :D

Could be an endianness issue? that setup is BE right?

-- 
Aleksander
https://aleksander.es