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.
Related
I have my application using boost logger. When I terminate my program using killall myApplication. There is core file generated. I then use gdb and see the trace. I also tried some related fix but not useful. link
#0 __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ff95f9aa801 in __GI_abort () at abort.c:79
#2 0x00007ff96240f84a in __gnu_cxx::__verbose_terminate_handler ()
at /home/nwani/m3/conda-bld/compilers_linux-64_1560109574129/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#3 0x00007ff96240df47 in __cxxabiv1::__terminate (handler=<optimized out>)
at /home/nwani/m3/conda-bld/compilers_linux-64_1560109574129/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4 0x00007ff96240d3a5 in __cxa_call_terminate (ue_header=ue_header#entry=0x55c83e48bfd0)
at /home/nwani/m3/conda-bld/compilers_linux-64_1560109574129/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libstdc++-v3/libsupc++/eh_call.cc:54
#5 0x00007ff96240dbd8 in __cxxabiv1::__gxx_personality_v0 (version=<optimized out>, actions=6, exception_class=5138137972254386944, ue_header=0x55c83e48bfd0, context=0x7ffc786aaa90)
at /home/nwani/m3/conda-bld/compilers_linux-64_1560109574129/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libstdc++-v3/libsupc++/eh_personality.cc:677
#6 0x00007ff96235aaab in _Unwind_RaiseException_Phase2 (exc=exc#entry=0x55c83e48bfd0, context=context#entry=0x7ffc786aaa90, frames_p=frames_p#entry=0x7ffc786aa998)
at /home/nwani/m3/conda-bld/compilers_linux-64_1560109574129/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libgcc/unwind.inc:64
#7 0x00007ff96235af49 in _Unwind_Resume (exc=0x55c83e48bfd0) at /home/nwani/m3/conda-bld/compilers_linux-64_1560109574129/work/.build/x86_64-conda_cos6-linux-gnu/src/gcc/libgcc/unwind.inc:241
#8 0x000055c83c2e5be1 in boost::log::v2_mt_posix::aux::light_rw_mutex::unlock_shared (this=<optimized out>) at /usr/include/boost/log/detail/light_rw_mutex.hpp:115
#9 boost::log::v2_mt_posix::sources::multi_thread_model<boost::log::v2_mt_posix::aux::light_rw_mutex>::unlock_shared (this=<optimized out>) at /usr/include/boost/log/sources/threading_models.hpp:78
#10 boost::log::v2_mt_posix::aux::shared_lock_guard<boost::log::v2_mt_posix::sources::multi_thread_model<boost::log::v2_mt_posix::aux::light_rw_mutex> >::~shared_lock_guard (this=<optimized out>,
__in_chrg=<optimized out>) at /usr/include/boost/log/detail/locks.hpp:146
#11 boost::log::v2_mt_posix::sources::basic_composite_logger<char, boost::log::v2_mt_posix::sources::severity_logger_mt<severity_level>, boost::log::v2_mt_posix::sources::multi_thread_model<boost::log::v2_mt_posix::aux::light_rw_mutex>, boost::log::v2_mt_posix::sources::features<boost::log::v2_mt_posix::sources::severity<severity_level> > >::open_record<boost::parameter::aux::tagged_argument<boost::log::v2_mt_posix::keywords::tag::severity, severity_level const> > (this=this#entry=0x55c83e46b798, args=...) at /usr/include/boost/log/sources/basic_logger.hpp:458
My application is running on linux. In class destructor, I have log printing. The core file shows that that is the crashing point. I would like to ask if that is some config problem or a wrong usage of the boost library?
The problem is that at the point when your class destructor is called the thread-local storage used for the severity level is already destroyed. Because of this, initiating a log record fails with an exception, and since you don't catch it, the program aborts.
It is recommended to avoid logging during program termination. However, if you really do need that instance of logging, you may try changing the logger type to logger_mt. This will remove the severity level from the log records emitted through that logger, but you could emulate it with scoped logger attributes.
I want to use elasticsearch yii2 component with AWS elasticsearch service. But it is surly not allowing. Because AWS elasticsearch is not providing [http][publish_address] in response while electing node for connection. And yii2-elasticsearch(2.1) is simply discarding any such node.
Is there any other way, if i'm missing something?
Following is my component configuration and error i'm getting.
'elasticsearch' => [
'class' => 'yii\elasticsearch\Connection',
'nodes' => [
[
'http_address' => 'end-point.es.amazonaws.com',
'protocol' => 'https'
],
],
]
Stack trace:
#0 /var/www/html/staging/vendor/yiisoft/yii2-elasticsearch/Connection.php(190): yii\base\ErrorHandler->handleError(8, 'Undefined index...', '/var/www/html/s...', 190, Array)
#1 /var/www/html/staging/vendor/yiisoft/yii2-elasticsearch/Connection.php(155): yii\elasticsearch\Connection->populateNodes()
#2 /var/www/html/staging/vendor/yiisoft/yii2-elasticsearch/Connection.php(259): yii\elasticsearch\Connection->open()
#3 /var/www/html/staging/common/models/es/BaseModel.php(129): yii\elasticsearch\Connection->createCommand()
#4 /var/www/html/staging/common/models/es/BaseModel.php(134): common\models\es\BaseModel::deleteIndex()
#5 /var/www/html/staging/console/controllers/EsController.php(114): common\models\es\BaseModel::resetIndex()
#6 /var/www/html/staging/console/controllers/EsController.php(206): console\controllers\EsController->reindexInBulk(Array, '100')
#7 [internal function]: console\controllers\EsController->actionReindex()
#8 /var/www/html/staging/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#9 /var/www/html/staging/vendor/yiisoft/yii2/base/Controller.php(157): yii\base\InlineAction->runWithParams(Array)
#10 /var/www/html/staging/vendor/yiisoft/yii2/console/Controller.php(148): yii\base\Controller->runAction('reindex', Array)
#11 /var/www/html/staging/vendor/yiisoft/yii2/base/Module.php(528): yii\console\Controller->runAction('reindex', Array)
#12 /var/www/html/staging/vendor/yiisoft/yii2/console/Application.php(180): yii\base\Module->runAction('es/reindex', Array)
#13 /var/www/html/staging/vendor/yiisoft/yii2/console/Application.php(147): yii\console\Application->runAction('es/reindex', Array)
#14 /var/www/html/staging/vendor/yiisoft/yii2/base/Application.php(386): yii\console\Application->handleRequest(Object(yii\console\Request))
#15 /var/www/html/staging/yii(31): yii\base\Application->run()
#16 {main}
Look like it tries to delete an index that doesnt exist.
/var/www/html/staging/common/models/es/BaseModel.php(134): common\models\es\BaseModel::deleteIndex()
Hence the error.
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
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);