With help of GDB-script:
file ./program
b *0x12345
run
while 1
x/i $pc
ni
end
quit
I got a trace protocol of obfuscated program:
...
0x484e0: bx lr
?? ()
0x43d88: b 0x43db8
?? ()
0x43db8: ldr r3, [r11, #-16]
?? ()
0x43dbc: mov r0, r3
?? ()
0x43dc0: sub sp, r11, #12
?? ()
0x43dc4: pop {r4, r5, r11, pc}
?? ()
0x3fb94: ldr r3, [r11, #-8]
?? ()
0x3fb98: mov r0, r3
?? ()
0x3fb9c: sub sp, r11, #4
?? ()
0x3fba0: pop {r11, pc}
?? ()
0x3da68: ldr r3, [r11, #-8]
...
Kris Kaspersky writes, that it is good idea to pass the tracer's protocol through compiler-optimizer for better understanding of this program. But I haven't any idea what compilers and in what way should I use.
P.S. What should I do to get rid of unnecessary lines: "?? ()" ? And what should I do to redirect GDB's out to file?
Edited:
Book: Kris Kaspersky "Искусство дизассемблирования", book in Russian (translation - "Art of disassembling"). Chapter №39, Page 822 (under the listing). I haven't any idea is English analogue exist.
Kris Kaspersky writes, that it is good idea to pass the tracer's protocol through compiler-optimizer for better understanding of this program. But I haven't any idea what compilers and in what way should I use.
I know what compilers are, but still have no idea what you are talking about. If you provide a link to the document you are reading, you might get better answers.
What should I do to get rid of unnecessary lines: "?? ()" ?
Use grep to filter them out, e.g.
grep -v '\?' trace.txt > clean-trace.txt
or
grep '^0x' trace.txt > clean-trace.txt
And what should I do to redirect GDB's out to file?
(gdb) set logging on # output will now be copied to gdb.txt
Related
I have run mos debug-core-dump on my local machine to debug some code running on an ESP32 with Mongoose OS. This is part of the GDB output, possible to get some help interpreting it?
Dump contains FreeRTOS task info
Loaded core dump from last snippet in /core
0x40186bb9 in TwoWire::read (this=0x3ffb6d98 <Wire>)
at /home/harry/MOS/VersionJ_Mongoose/deps/arduino-wire/src/mgos_arduino_wire.cpp:133
133 return (pbyte_to_recv < recv_buf + n_bytes_avail) ? *pbyte_to_recv++ : -1;
#0 0x40186bb9 in TwoWire::read (this=0x3ffb6d98 <Wire>)
at /home/harry/MOS/VersionJ_Mongoose/deps/arduino-wire/src/mgos_arduino_wire---Type <return> to continue, or q <return> to quit---
.cpp:133
#1 0x400d72db in ACS71020::getRaw (this=0x3ffb4b14 <mySensor>,
reg_address=48 '0')
at /home/harry/MOS/VersionJ_Mongoose/src/ACS71020.cpp:115
#2 0x400d7496 in ACS71020::custom_en (this=0x3ffb4b14 <mySensor>)
at /home/harry/MOS/VersionJ_Mongoose/src/ACS71020.cpp:425
#3 0x400d9131 in mgos_app_init ()
at /home/harry/MOS/VersionJ_Mongoose/src/main.cpp:476
#4 0x400d3466 in mgos_init () at /mongoose-os/src/mgos_init.c:29
#5 0x400db5ba in mgos_init2 ()
at /home/harry/MOS/VersionJ_Mongoose/deps/freertos/src/mgos_freertos.c:169
#6 0x4008279b in mgos_task (arg=0x0)
at /home/harry/MOS/VersionJ_Mongoose/deps/freertos/src/mgos_freertos.c:180
here are a couple code snippets referenced (images to show line numbers):
I have a small test programs that talks to a server backend through a library that I have written. The test uses the QTest framework and runs through a bunch of test cases. The latest version of the test program has started to issue a segmentation fault after all of my tests have run. The output is something like:
********* Start testing of TestSequence *********
Config: Using QtTest library 5.6.1, Qt 5.6.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 4.9.1 20140922 (Red Hat 4.9.1-10))
...
Totals: 28 passed, 0 failed, 0 skipped, 0 blacklisted
********* Finished testing of TestSequence *********
RUN FINISHED; Segmentation fault; core dumped; real time: 26s; user: 40ms; system: 290ms
I can get a stack backtrace from the segfault:
#0 0x00007fffe9b3a61e in QDBusMetaType::typeToSignature(int) () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#1 0x00007fffe9b31a9e in qDBusParametersForMethod(QList<QByteArray> const&, QVector<int>&, QString&) () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#2 0x00007fffe9b31fc9 in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#3 0x00007fffe9aff081 in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#4 0x00007fffe9aff8bf in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#5 0x00007fffe9b005c6 in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#6 0x00007fffe9b115af in ?? () from /home/pete/Qt/5.6/gcc_64/plugins/bearer/../../lib/libQt5DBus.so.5
No symbol table info available.
#7 0x00007ffff626cf7a in QObject::event(QEvent*) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#8 0x00007ffff6242b6b in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#9 0x00007ffff6245373 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#10 0x00007ffff6291d83 in ?? () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#11 0x00007ffff45f6e04 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#12 0x00007ffff45f7048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#13 0x00007ffff45f70ec in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
No symbol table info available.
#14 0x00007ffff6292177 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#15 0x00007ffff6240bca in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#16 0x00007ffff607ae4c in QThread::exec() () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#17 0x00007ffff607f769 in ?? () from /home/pete/Qt/5.6/gcc_64/lib/libQt5Core.so.5
No symbol table info available.
#18 0x00007ffff4f19182 in start_thread (arg=0x7fffea796700) at pthread_create.c:312
__res = <optimised out>
pd = 0x7fffea796700
now = <optimised out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737127212800, -4443015154407963459, 1, 0, 140737127213504, 140737127212800, 4443057989164074173, 4443034828799739069}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimised out>
pagesize_m1 = <optimised out>
sp = <optimised out>
freesize = <optimised out>
__PRETTY_FUNCTION__ = \"start_thread\"
#19 0x00007ffff57f047d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
This looks like the fault is outside my code, but presumably something I've done has caused it!
Any insight from the crowd? Or should I report a bug to Qt?
Your problem seems to be related to this bug that affects Qt 5.6.
As mentioned in the trail of comments, it should have been solved in Qt 5.7. You can also apply a few patches to solve it on version 5.6.
The discussion is dated 6/2016 and lasts at the end of September.
I have installed NEOS 1.2.1 via composer,created a new site, everything is dandy.
but after a while i ran across an error where neos told me to use node:repair
okay i did, but with that i ran afoul of the following exception.
it seems it cannot connect or something like that scratches head
My question is why,when other flow commands (presumably without the DB) were executed just fine?
This is running local on Mac with Mamp Pro, does have anyone an idea, what causes this?
TombStone:source lucither$ ./flow node:repair --node-type TYPO3.Neos.NodeTypes:Page
Uncaught Exception: TYPO3\Flow\Persistence\Doctrine\Exception\DatabaseConnectionException
Message
SQLSTATE[HY000] [2002] No such file or directory
More Information
Exception code 2002
File /Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Persistence_Doctrine_Query.php line 230
Reference code 20150106214706a2dfc2
Stack trace
#0 TYPO3\Flow\Persistence\Doctrine\Query_Original::count()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Persistence_Doctrine_Query.php:794
#1 TYPO3\Flow\Persistence\Doctrine\Query::count()
#2 ::call_user_func_array()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Persistence_Doctrine_Query.php:745
#3 TYPO3\Flow\Persistence\Doctrine\Query::Flow_Aop_Proxy_invokeJoinPoint()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Aop/Advice/AdviceChain.php:57
#4 TYPO3\Flow\Aop\Advice\AdviceChain::proceed()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Security_Aspect_PersistenceQueryRewritingAspect.php:102
#5 TYPO3\Flow\Security\Aspect\PersistenceQueryRewritingAspect_Original::rewriteQomQuery()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Aop/Advice/AroundAdvice.php:34
#6 TYPO3\Flow\Aop\Advice\AroundAdvice::invoke()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Aop/Advice/AdviceChain.php:55
#7 TYPO3\Flow\Aop\Advice\AdviceChain::proceed()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Persistence_Doctrine_Query.php:806
#8 TYPO3\Flow\Persistence\Doctrine\Query::count()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Persistence_Doctrine_QueryResult.php:87
#9 TYPO3\Flow\Persistence\Doctrine\QueryResult_Original::count()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_TYPO3CR_Command_NodeCommandController.php:95
#10 TYPO3\TYPO3CR\Command\NodeCommandController_Original::repairCommand()
#11 ::call_user_func_array()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Cli_CommandController.php:240
#12 TYPO3\Flow\Cli\CommandController_Original::callCommandMethod()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Cli_CommandController.php:110
#13 TYPO3\Flow\Cli\CommandController_Original::processRequest()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Mvc_Dispatcher.php:80
#14 TYPO3\Flow\Mvc\Dispatcher_Original::dispatch()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Mvc_Dispatcher.php:298
#15 TYPO3\Flow\Mvc\Dispatcher::dispatch()
#16 ::call_user_func_array()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Mvc_Dispatcher.php:282
#17 TYPO3\Flow\Mvc\Dispatcher::Flow_Aop_Proxy_invokeJoinPoint()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Aop/Advice/AdviceChain.php:57
#18 TYPO3\Flow\Aop\Advice\AdviceChain::proceed()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Security_Aspect_RequestDispatchingAspect.php:75
#19 TYPO3\Flow\Security\Aspect\RequestDispatchingAspect_Original::blockIllegalRequestsAndForwardToAuthenticationEntryPoints()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Aop/Advice/AroundAdvice.php:34
#20 TYPO3\Flow\Aop\Advice\AroundAdvice::invoke()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Aop/Advice/AdviceChain.php:55
#21 TYPO3\Flow\Aop\Advice\AdviceChain::proceed()
/Users/lucither/development/XXX/source/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/TYPO3_Flow_Mvc_Dispatcher.php:313
#22 TYPO3\Flow\Mvc\Dispatcher::dispatch()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Cli/CommandRequestHandler.php:97
#23 TYPO3\Flow\Cli\CommandRequestHandler::handleRequest()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Classes/TYPO3/Flow/Core/Bootstrap.php:108
#24 TYPO3\Flow\Core\Bootstrap::run()
/Users/lucither/development/XXX/source/Packages/Framework/TYPO3.Flow/Scripts/flow.php:55
#25 ::require()
/Users/lucither/development/XXX/source/flow:18
Occasionally I experience some core dumps which i can't figure out why they happen. Typically this happens when assigning av value to a string. Below is the backtrace for one of this cases. A core dump seems to be caused by this line in my c++ code:
m_strValue = "---";
I can't figure out what is going on in this case and I home someone can shed some light over this issue.
Below is the backtrace
#0 0x40227ed4 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1 0x402293d0 in *__GI_abort () at abort.c:92
#2 0x4011a594 in __gnu_cxx::__verbose_terminate_handler () at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3/libstdc++-v3/libsupc++/vterminate.cc:93
#3 0x40118770 in __cxxabiv1::__terminate (handler=<optimized out>) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3/libstdc++-v3/libsupc++/eh_terminate.cc:39
#4 0x40118798 in std::terminate () at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3/libstdc++-v3/libsupc++/eh_terminate.cc:49
#5 0x40118914 in __cxxabiv1::__cxa_throw (obj=<optimized out>, tinfo=<optimized out>, dest=<optimized out>) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3/libstdc++-v3/libsupc++/eh_throw.cc:83
#6 0x400c8de8 in std::__throw_length_error (__s=<optimized out>) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3/libstdc++-v3/src/functexcept.cc:74
#7 0x400fe02c in std::string::_Rep::_S_create (__capacity=4294967293, __old_capacity=<optimized out>, __alloc=<optimized out>) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3-stage3/armv5l-linux-gnueabi/libstdc++-v3/include/bits/basic_string.tcc:552
#8 0x400fe260 in std::string::_M_mutate (this=0x7d3d78, __pos=0, __len1=9, __len2=3) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3-stage3/armv5l-linux-gnueabi/libstdc++-v3/include/bits/basic_string.tcc:479
#9 0x400fe3fc in std::string::_M_replace_safe (this=0x7d3d78, __pos1=0, __n1=<optimized out>, __s=0x62d708 "---", __n2=3) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3-stage3/armv5l-linux-gnueabi/libstdc++-v3/include/bits/basic_string.tcc:684
#10 0x400fe48c in std::string::assign (this=0x7d3d78, __s=<optimized out>, __n=3) at /home/habbjack/ssd/workspace/builder2/build_armv5l-linux-gnueabi/gcc-4.5.3/gcc-4.5.3-stage3/armv5l-linux-gnueabi/libstdc++-v3/include/bits/basic_string.tcc:264
#11 0x0026175c in CLCD_Wnd::Refresh (this=0x7d3d60) at ../../lib/src/HAL/LCD/CLCD_Wnd.cpp:49
Line 7 show creation with capacity=4294967293 followed immediately by throw_length_error.
Plus, your object at line 11 is only 24 bytes away from your string, which may indicate some kind of allocation problem if CLCD_Wnd needs more space than that.
Almost certainly m_strValue or its containing object no longer exists (deleted or went out of scope). It's impossible to say without more code but if you're on Linux valgrind can help you out.
Inside the main,is there any command to show how's it invoked?
This might be what you're looking for, if I get the question right:
(gdb) help set backtrace past-main
Set whether backtraces should continue past "main".
Normally the caller of "main" is not of interest, so GDB will terminate
the backtrace at "main". Set this variable if you need to see the rest
of the stack trace.
so if you set it to on (and the debug info for the libc are available, cf. this anwser), you'll see a stack looking like that:
(gdb) where
#0 main () at ./functionPtr.c:8
#1 0x0000003c47e2139d in __libc_start_main (main=0x40052b <main>, argc=1, ubp_av=0x7fffffffde28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde18) at libc-start.c:226
#2 0x0000000000400449 in _start ()
with the surrounding libc-start.c code looking like that:
struct pthread *self = THREAD_SELF;
/* Store old info. */
unwind_buf.priv.data.prev = THREAD_GETMEM (self, cleanup_jmp_buf);
unwind_buf.priv.data.cleanup = THREAD_GETMEM (self, cleanup);
/* Store the new cleanup handler info. */
THREAD_SETMEM (self, cleanup_jmp_buf, &unwind_buf);
/* Run the program. */
result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);