[vz-users] vzlogger stürzt immer ab

Matthias Behr mbehr at mcbehr.de
Wed Mar 11 20:37:19 CET 2015


Hmm. So eine valgrind Warnung habe ich noch nicht gesehen. Da ist definitiv was faul.

> Am 11.03.2015 um 05:42 schrieb oderwas at gmx.net:
> 
> Hallo Matthias,
> 
> hier der valgrind-Auszug,
> 
> Http und HTtp sind beide auch abgestürzt.
> 
> # valgrind --leak-check=full /usr/local/bin/vzlogger 
> ==18661== Memcheck, a memory error detector
> ==18661== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
> ==18661== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
> ==18661== Command: /usr/local/bin/vzlogger
> ==18661== 
> disInstr(arm): unhandled instruction: 0xF26EE1FE
>                 cond=15(0xF) 27:20=38(0x26) 4:4=1 3:0=14(0xE)
> ==18661== valgrind: Unrecognised instruction at address 0x4aa0600.
> ==18661==    at 0x4AA0600: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0)
> ==18661== Your program just tried to execute an instruction that Valgrind
> ==18661== did not recognise.  There are two possible reasons for this.
> ==18661== 1. Your program has a bug and erroneously jumped to a non-code
> ==18661==    location.  If you are running Memcheck and you just saw a
> ==18661==    warning about a bad jump, it's probably your program's fault.
> ==18661== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==18661==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==18661==    you are not sure, please let us know and we'll try to fix it.
> ==18661== Either way, Valgrind will now raise a SIGILL signal which will
> ==18661== probably kill your program.
> disInstr(arm): unhandled instruction: 0xEE190F1D
>                 cond=14(0xE) 27:20=225(0xE1) 4:4=1 3:0=13(0xD)
> ==18661== valgrind: Unrecognised instruction at address 0x4aa0608.
> ==18661==    at 0x4AA0608: ??? (in /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0)
> ==18661== Your program just tried to execute an instruction that Valgrind
> ==18661== did not recognise.  There are two possible reasons for this.
> ==18661== 1. Your program has a bug and erroneously jumped to a non-code
> ==18661==    location.  If you are running Memcheck and you just saw a
> ==18661==    warning about a bad jump, it's probably your program's fault.
> ==18661== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==18661==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==18661==    you are not sure, please let us know and we'll try to fix it.
> ==18661== Either way, Valgrind will now raise a SIGILL signal which will
> ==18661== probably kill your program.
> disInstr(arm): unhandled instruction: 0xF1010200
>                 cond=15(0xF) 27:20=16(0x10) 4:4=0 3:0=0(0x0)
> ==18661== valgrind: Unrecognised instruction at address 0x4842588.
> ==18661==    at 0x4842588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so)
> ==18661== Your program just tried to execute an instruction that Valgrind
> ==18661== did not recognise.  There are two possible reasons for this.
> ==18661== 1. Your program has a bug and erroneously jumped to a non-code
> ==18661==    location.  If you are running Memcheck and you just saw a
> ==18661==    warning about a bad jump, it's probably your program's fault.
> ==18661== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==18661==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==18661==    you are not sure, please let us know and we'll try to fix it.
> ==18661== Either way, Valgrind will now raise a SIGILL signal which will
> ==18661== probably kill your program.
> ==18661== 
> ==18661== Process terminating with default action of signal 4 (SIGILL): dumping core
> ==18661==  Illegal opcode at address 0x4842588
> ==18661==    at 0x4842588: ??? (in /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so)
> ==18661== 
> ==18661== HEAP SUMMARY:
> ==18661==     in use at exit: 37,881 bytes in 1,143 blocks
> ==18661==   total heap usage: 1,750 allocs, 607 frees, 45,232 bytes allocated
> ==18661== 
> ==18661== 22 bytes in 1 blocks are definitely lost in loss record 6 of 34
> ==18661==    at 0x4833970: malloc (vg_replace_malloc.c:263)
> ==18661==    by 0x4DB6343: strdup (strdup.c:42)
> ==18661==    by 0x57EFB: Config_Options::config_parse(MapContainer&) (Config_Options.cpp:120)
> ==18661==    by 0x45AC3: main (vzlogger.cpp:357)
> ==18661== 
> ==18661== 803 bytes in 14 blocks are possibly lost in loss record 28 of 34
> ==18661==    at 0x4833F2C: operator new(unsigned int) (vg_replace_malloc.c:282)
> ==18661==    by 0x4CE29C7: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/arm-linux-gnueabihf/libstdc++.so.6.0.20)
> ==18661== 
> ==18661== LEAK SUMMARY:
> ==18661==    definitely lost: 22 bytes in 1 blocks
> ==18661==    indirectly lost: 0 bytes in 0 blocks
> ==18661==      possibly lost: 803 bytes in 14 blocks==18661==    still reachable: 37,056 bytes in 1,128 blocks
> ==18661==         suppressed: 0 bytes in 0 blocks
> ==18661== Reachable blocks (those to which a pointer was found) are not shown.
> ==18661== To see them, rerun with: --leak-check=full --show-reachable=yes
> ==18661== 
> ==18661== For counts of detected and suppressed errors, rerun with: -v
> ==18661== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
> Illegal instruction

Gruß

Matthias Behr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5256 bytes
Desc: not available
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20150311/21b13a2c/attachment.bin>


More information about the volkszaehler-users mailing list