SEGFAULT with MM HEAD when probing

Bjørn Mork bjorn at mork.no
Wed Apr 21 20:04:27 UTC 2021


Bjørn Mork <bjorn at mork.no> writes:

> Aleksander Morgado <aleksander at 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 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 ;-)


Bjørn


More information about the ModemManager-devel mailing list