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):
Related
There is a problem to identify the full command from the core dump file using gdb
The crashed command itself can be long
i.e.
myCommand -f log/SlaRunTimeReport.rep -I input/myFile.txt -t output/myFile.txt
But When using gdb to identify the command in the location “Core was generated by”
i.e. by executing
gdb -c core.56536
The Output:
GNU gdb (GDB) Red Hat Enterprise Linux 7.10-20.el7
….
Core was generated by `myCommand -f log/SlaRunTimeReport.rep -I
input/myFile.t'.
It is possible to see that the full command(executable + parameters) was cut in the middle
‘myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t'
In additional using strings command , also did not help to identify the full command
strings core.56536 | grep PMRunTimeReport
The Output:
myCommand
myCommand -f log/SlaRunTimeReport.rep -I input/myFile.t
Is there any way to get from coredump file the full command that caused the failure
Thanks in Advance
Is there any way to get from coredump file the full command that caused the failure
There are multiple ways, but running strings is the wrong way.
IF you built your program with debug info, you should be able to simply execute up command until you reach main, then examine argv[0] through argv[argc-1].
If your main was not built with debug info, or if it doesn't use argc and argv, you should be able to recover that info from __libc_argc and __libc_argv variables. Example:
$ ./a.out foo bar baz $(python -c 'print "a" * 500')
Aborted (core dumped)
$ gdb -q ./a.out core
Core was generated by `./a.out foo bar baz aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.
Note that the "generated by" is truncated -- it comes from a fixed length array inside of struct prpsinfo, saved in NT_PRPSINFO ELF note in the core.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007fab38cfcf2b in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.27-15.fc28.x86_64
(gdb) p (int)__libc_argc
$1 = 5
(gdb) p ((char**)__libc_argv)[0]#5
$2 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 200 times>...}
This last line is actually a lie -- we know that 'a' repeats 500 times.
We can fix it like so:
(gdb) set print elem 0
(gdb) p ((char**)__libc_argv)[0]#5
$3 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}
Voila: we now have the complete command.
Lastly, if you install debug info for GLIBC, you can simply look in the __libc_start_main (which called your main):
(gdb) set backtrace past-main
(gdb) bt
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007fab38ce7561 in __GI_abort () at abort.c:79
#2 0x00000000004004ef in main () at foo.c:3
#3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108)
at ../csu/libc-start.c:308
#4 0x000000000040042a in _start ()
Here you can clearly see argc and argv in frame 3, and can examine that argv like so:
(gdb) fr 3
#3 0x00007fab38ce918b in __libc_start_main (main=0x4004e6 <main>, argc=5, argv=0x7ffede431118,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffede431108)
at ../csu/libc-start.c:308
308 result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
(gdb) p argv[0]#5
$1 = {0x7ffede43289f "./a.out", 0x7ffede4328a7 "foo", 0x7ffede4328ab "bar",
0x7ffede4328af "baz",
0x7ffede4328b3 'a' <repeats 500 times>}
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);