I've been tracking down an occasional crash in my app, which comes from an EXC_BAD_ACCESS KERN_PROTECTION_FAILURE, and I finally found something that it could be by using the Address Sanitizer. Unfortunately, I have no idea what the ASan output is telling me.
I've set up my Core Data stack based on this tutorial's stack. The ASan warning warning shows up here:
func mergeChanges(from transactions: [NSPersistentHistoryTransaction]) {
let context = viewContext
context.perform {
for transaction in transactions {
let note = transaction.objectIDNotification()
context.mergeChanges(fromContextDidSave: note) // heap buffer overflow!
try? self.storeHistoryToken(transaction.token)
}
}
}
I don't know what I could do to fix this code, since it seems pretty simple. It does happen when there's a lot of data being imported to Core Data through Batch Insertion Requests.
The output of the sanitizer into the debug terminal looks like this:
==59326==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6280004dbcff at pc 0x00010c71c8bd bp 0x7ff7b724b9d0 sp 0x7ff7b724b190
READ of size 15360 at 0x6280004dbcff thread T0
#0 0x10c71c8bc in wrap_memcpy+0x16c (libclang_rt.asan_iossim_dynamic.dylib:x86_64+0x1b8bc)
#1 0x7ff804aafd81 in fetchResultSetReallocCurrentRow+0x206 (CoreData:x86_64+0x1f2d81)
#2 0x7ff804a80dce in -[NSSQLiteConnection fetchResultSet:usingFetchPlan:]+0x317 (CoreData:x86_64+0x1c3dce)
#3 0x7ff804ab0ed1 in newFetchedRowsForFetchPlan_MT+0x471 (CoreData:x86_64+0x1f3ed1)
#4 0x7ff804bb0807 in _executeObjectFaultRequest+0x307 (CoreData:x86_64+0x2f3807)
#5 0x7ff804bb26e7 in _executeNewRowValuesForObjectFaultRequest+0xb6 (CoreData:x86_64+0x2f56e7)
#6 0x7ff804abe237 in -[NSSQLObjectFaultRequestContext executeRequestCore:]+0x14 (CoreData:x86_64+0x201237)
#7 0x7ff80491f370 in -[NSSQLStoreRequestContext executeRequestUsingConnection:]+0x1b0 (CoreData:x86_64+0x62370)
#8 0x7ff8049debfa in __52-[NSSQLDefaultConnectionManager handleStoreRequest:]_block_invoke+0x37 (CoreData:x86_64+0x121bfa)
#9 0x7ff804a729ca in __37-[NSSQLiteConnection performAndWait:]_block_invoke+0x1b (CoreData:x86_64+0x1b59ca)
#10 0x1123d2f5a in _dispatch_client_callout+0x7 (libdispatch.dylib:x86_64+0x4f5a)
#11 0x1123e4d71 in _dispatch_lane_barrier_sync_invoke_and_complete+0x83 (libdispatch.dylib:x86_64+0x16d71)
#12 0x7ff804a723d2 in -[NSSQLiteConnection performAndWait:]+0x8e (CoreData:x86_64+0x1b53d2)
#13 0x7ff8049deb13 in -[NSSQLDefaultConnectionManager handleStoreRequest:]+0xe3 (CoreData:x86_64+0x121b13)
#14 0x7ff804b68065 in -[NSSQLCoreDispatchManager routeStoreRequest:]+0x10e (CoreData:x86_64+0x2ab065)
#15 0x7ff804a32fd4 in -[NSSQLCore dispatchRequest:withRetries:]+0x84 (CoreData:x86_64+0x175fd4)
#16 0x7ff804a33ec3 in -[NSSQLCore newValuesForObjectWithID:withContext:error:]+0x137 (CoreData:x86_64+0x176ec3)
#17 0x7ff8049f8858 in __95-[NSPersistentStoreCoordinator(_NSInternalMethods) newValuesForObjectWithID:withContext:error:]_block_invoke+0x5b (CoreData:x86_64+0x13b858)
#18 0x7ff8049e64e6 in -[NSPersistentStoreCoordinator _routeLightweightBlock:toStore:]+0xeb (CoreData:x86_64+0x1294e6)
#19 0x7ff8049f85bd in -[NSPersistentStoreCoordinator(_NSInternalMethods) newValuesForObjectWithID:withContext:error:]+0x15c (CoreData:x86_64+0x13b5bd)
#20 0x7ff80496466f in _PFFaultHandlerLookupRow+0x204 (CoreData:x86_64+0xa766f)
#21 0x7ff804966c69 in _PF_FulfillDeferredFault+0xd6 (CoreData:x86_64+0xa9c69)
#22 0x7ff8049864a6 in _sharedIMPL_pvfk_core+0x8a (CoreData:x86_64+0xc94a6)
#23 0x7ff804976326 in _PF_Handler_Public_GetProperty+0xed (CoreData:x86_64+0xb9326)
#24 0x7ff800b9e985 in -[NSFunctionExpression expressionValueWithObject:context:]+0x6c2 (Foundation:x86_64+0x4a0985)
#25 0x7ff800b58fda in -[NSComparisonPredicate evaluateWithObject:substitutionVariables:]+0x146 (Foundation:x86_64+0x45afda)
#26 0x7ff800b5c0c0 in -[NSCompoundPredicateOperator evaluatePredicates:withObject:substitutionVariables:]+0x116 (Foundation:x86_64+0x45e0c0)
#27 0x7ff800b5ba14 in -[NSCompoundPredicate evaluateWithObject:substitutionVariables:]+0x109 (Foundation:x86_64+0x45da14)
#28 0x7ff804a18812 in -[NSFetchedResultsController _preprocessUpdatedObjects:insertsInfo:deletesInfo:updatesInfo:sectionsWithDeletes:newSectionNames:treatAsRefreshes:]+0x1f0 (CoreData:x86_64+0x15b812)
#29 0x7ff804a19c48 in __82-[NSFetchedResultsController(PrivateMethods) _core_managedObjectContextDidChange:]_block_invoke+0x7d7 (CoreData:x86_64+0x15cc48)
#30 0x7ff8049a0112 in developerSubmittedBlockToNSManagedObjectContextPerform+0x96 (CoreData:x86_64+0xe3112)
#31 0x7ff80499fffc in -[NSManagedObjectContext performBlockAndWait:]+0xc4 (CoreData:x86_64+0xe2ffc)
#32 0x7ff804a1945e in -[NSFetchedResultsController _core_managedObjectContextDidChange:]+0x6d (CoreData:x86_64+0x15c45e)
#33 0x7ff80035964a in __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__+0x88 (CoreFoundation:x86_64+0x5664a)
#34 0x7ff800359580 in ___CFXRegistrationPost_block_invoke+0x55 (CoreFoundation:x86_64+0x56580)
#35 0x7ff80AddressSanitizer report breakpoint hit. Use 'thread info -s' to get extended information about the report.
(lldb) thread info -s
thread #1: tid = 0x1361ef, 0x000000010c751210 libclang_rt.asan_iossim_dynamic.dylib`__asan::AsanDie(), queue = 'SQLQueue 0x613000128340 for MyAppModel.sqlite', stop reason = Heap buffer overflow
{
"access_size": 15360,
"access_type": 0,
"address": 108301900430591,
"description": "heap-buffer-overflow",
"instrumentation_class": "AddressSanitizer",
"pc": 4503750845,
"stop_type": "fatal_error"
}
Can anyone help me make sense of this?
I am currently using Artery to simulate Traffic in a custom scenario. Being lazy, I just changed the required sumo-files and launchd.xml and references in the omnetpp.ini files so that I can run Artery using the run_example target.
So far so good.
Qtenv starts without problems an I get a dialogue, prompting me to choose the ini configuration (General, veins, inet or inet_rsu). Whenever the SimTime reaches around 140 seconds running the inet_rsu configutration, the program crashes producing the following error Message:
opp_run: /home/wiconlab/Car2x/artery-master/src/artery/application
/LocalDynamicMap.cc:24: void artery::LocalDynamicMap::updateAwareness(const CaObject&): Assertion `entry.expiry > omnetpp::simTime() && entry.expiry < omnetpp::simTime() + 2.0' failed
The complete terminal output is as follows:
$ cmake --build build --target run_example
[ 13%] Built target traci
[ 14%] Building INET (external dependency)
*** COMPILING with:
g++ -c -std=c++11 -O2 -DNDEBUG=1 -MMD -MP -MF .d -fPIC -fno-stack-protector -DHAVE_SWAPCONTEXT -DWITH_MPI -DXMLPARSER=libxml -DPREFER_QTENV -DWITH_QTENV -DWITH_TKENV -DWITH_PARSIM -DWITH_NETBUILDER -DWITH_OSG -DWITH_OSGEARTH -Wno-overloaded-virtual -include inet/common/precompiled.h -I. -I/home/wiconlab/Car2x/omnetpp-5.1.1/include
*** LINKING with:
g++ -shared -fPIC -o ../out/gcc-release/src/libINET.so -Wl,--no-as-needed -Wl,--whole-archive -Wl,--no-whole-archive -loppenvir -loppsim -ldl -lstdc++ -lOpenThreads -losg -losgText -losgDB -losgEarth -losgEarthUtil -Wl,-rpath,/home/wiconlab/Car2x/omnetpp-5.1.1/lib -Wl,-rpath,/lib -Wl,-rpath,. -L/home/wiconlab/Car2x/omnetpp-5.1.1/lib
Building...
[ 14%] Built target build_inet
[ 15%] Building Veins (external dependency)
[ 15%] Built target build_veins
[ 16%] Building Vanetza (external dependency)
-- Boost version: 1.58.0
-- Found the following Boost libraries:
-- date_time
-- serialization
-- system
-- Using bundled ASN.1 code instead of asn1c
-- Could NOT find Cohda (missing: COHDA_MK2_ROOT)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/wiconlab/Car2x/artery-master/extern/vanetza/build
[ 0%] Built target asn1_gen
[ 65%] Built target asn1
[ 67%] Built target common
[ 71%] Built target net
[ 81%] Built target security
[ 85%] Built target dcc
[ 95%] Built target geonet
[ 97%] Built target btp
[ 98%] Built target facilities
[ 99%] Built target gnss
[100%] Built target proxy_fake_feed
[ 16%] Built target build_vanetza
[ 22%] Built target denm
[ 27%] Built target messages
[ 49%] Built target storyboard
[ 65%] Built target envmod
[100%] Built target artery
OMNeT++ Discrete Event Simulation (C) 1992-2017 Andras Varga, OpenSim Ltd.
Version: 5.1.1, build: 170508-adbabd0, edition: Academic Public License -- NOT FOR COMMERCIAL USE
See the license for distribution terms and warranty disclaimer
Setting up Qtenv...
Loading NED files from /home/wiconlab/Car2x/artery-master/src/artery: 38
Loading NED files from /home/wiconlab/Car2x/artery-master/src/traci: 10
Loading NED files from /home/wiconlab/Car2x/artery-master/extern/veins/examples/veins: 1
Loading NED files from /home/wiconlab/Car2x/artery-master/extern/veins/src/veins: 33
Loading NED files from /home/wiconlab/Car2x/artery-master/extern/inet/examples: 163
Loading NED files from /home/wiconlab/Car2x/artery-master/extern/inet/src: 562
Loading NED files from /home/wiconlab/Car2x/artery-master/extern/inet/tutorials: 5
Loading images from './bitmaps': *: 0
Loading images from './images': *: 0
Loading images from '/home/wiconlab/Car2x/omnetpp-5.1.1/images': *: 0 abstract/*: 90 background/*: 4 block/*: 320 device/*: 195 logo/*: 1 maps/*: 9 misc/*: 70 msg/*: 55 old/*: 111 status/*: 28
Loading configuration... done.
Warning: Cannot find local schema '/home/hardt/Car2x/sumo-0.30.0/data/xsd/additional_file.xsd', will try website lookup.
Warning: Cannot find local schema '/home/hardt/Car2x/sumo-0.30.0/data/xsd/additional_file.xsd', will try website lookup.
opp_run: /home/wiconlab/Car2x/artery-master/src/artery/application/LocalDynamicMap.cc:24: void artery::LocalDynamicMap::updateAwareness(const CaObject&): Assertion `entry.expiry > omnetpp::simTime() && entry.expiry < omnetpp::simTime() + 2.0' failed.
Error: tcpip::Socket::recvAndCheck # recv: peer shutdown
Quitting (on error).
Aborted (core dumped)
scenarios/artery/CMakeFiles/run_example.dir/build.make:57: recipe for target 'scenarios/artery/CMakeFiles/run_example' failed
make[3]: *** [scenarios/artery/CMakeFiles/run_example] Error 134
CMakeFiles/Makefile2:566: recipe for target 'scenarios/artery/CMakeFiles/run_example.dir/all' failed
make[2]: *** [scenarios/artery/CMakeFiles/run_example.dir/all] Error 2
CMakeFiles/Makefile2:573: recipe for target 'scenarios/artery/CMakeFiles/run_example.dir/rule' failed
make[1]: *** [scenarios/artery/CMakeFiles/run_example.dir/rule] Error 2
Makefile:248: recipe for target 'run_example' failed
make: *** [run_example] Error 2
Backtrace after running in Debug configuration:
(gdb) backtrace
#0 0x00007ffff4c49428 in __GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff4c4b02a in __GI_abort () at abort.c:89
#2 0x00007ffff4c41bd7 in __assert_fail_base (fmt=<optimized out>,
assertion=assertion#entry=0x7fffd779f940 "entry.expiry > omnetpp::simTime() && entry.expiry < omnetpp::simTime() + 2.0",
file=file#entry=0x7fffd779f8f0 "/home/wiconlab/Car2x/artery-master/src/artery/application/LocalDynamicMap.cc", line=line#entry=24,
function=function#entry=0x7fffd779f9a0 <artery::LocalDynamicMap::updateAwareness(CaObject const&)::__PRETTY_FUNCTION__> "void artery::LocalDynamicMap::updateAwareness(const CaObject&)")
at assert.c:92
#3 0x00007ffff4c41c82 in __GI___assert_fail (
assertion=0x7fffd779f940 "entry.expiry > omnetpp::simTime() && entry.expiry < omnetpp::simTime() + 2.0",
file=0x7fffd779f8f0 "/home/wiconlab/Car2x/artery-master/src/artery/application/LocalDynamicMap.cc", line=24,
function=0x7fffd779f9a0 <artery::LocalDynamicMap::updateAwareness(CaObject const&)::__PRETTY_FUNCTION__> "void artery::LocalDynamicMap::updateAwareness(const CaObject&)") at assert.c:101
#4 0x00007fffd7703ab8 in artery::LocalDynamicMap::updateAwareness (this=0x1d62c7a8, obj=...)
at /home/wiconlab/Car2x/artery-master/src/artery/application/LocalDynamicMap.cc:24
Python Exception <class 'TypeError'> expected string or bytes-like object:
#5 0x00007fffd76f31f8 in CaService::indicate (this=0x6625550, ind=..., packet=)
at /home/wiconlab/Car2x/artery-master/src/artery/application/CaService.cc:89
#6 0x00007fffd4202d91 in vanetza::btp::PortDispatcher::indicate(vanetza::geonet::DataIndication const&, std::unique_ptr<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket>, std::default_delete<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket> > >) ()
from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_btp.so
#7 0x00007fffd3d3609f in vanetza::geonet::Router::pass_up(vanetza::geonet::DataIndication&, std::unique_ptr<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket>, std::default_delete<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket> > >) ()
from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_geonet.so
#8 0x00007fffd3d362f9 in vanetza::geonet::Router::process_extended(vanetza::geonet::ExtendedPduConstRefs<vanetza::geonet::ShbHeader> const&, std::unique_ptr<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket>, std::default_delete<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket> > >) () from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_geonet.so
#9 0x00007fffd3d378f7 in vanetza::geonet::Router::indicate_extended(vanetza::geonet::IndicationContext&, vanetza::geonet::CommonHeader const&) ()
from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_geonet.so
#10 0x00007fffd3d37b37 in vanetza::geonet::Router::indicate_common(vanetza::geonet::IndicationContext&, vanetza::geonet::BasicHeader const&) ()
from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_geonet.so
#11 0x00007fffd3d39623 in vanetza::geonet::Router::indicate_secured(vanetza::geonet::IndicationContext&, vanetza::geonet::BasicHeader const&) ()
from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_geonet.so
#12 0x00007fffd3d39998 in vanetza::geonet::Router::indicate(std::unique_ptr<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket>, std::default_delete<boost::variant<vanetza::ChunkPacket, vanetza::CohesivePacket> > >, vanetza::MacAddress const&, vanetza::MacAddress const&) ()
from /home/wiconlab/Car2x/artery-master/extern/vanetza/build/lib/libvanetza_geonet.so
#13 0x00007fffd7707bc5 in artery::Middleware::handleLowerMsg (this=0x1d62c650, msg=0x2ea0df0)
at /home/wiconlab/Car2x/artery-master/src/artery/application/Middleware.cc:303
#14 0x00007fffd7707a45 in artery::Middleware::handleMessage (this=0x1d62c650, msg=0x2ea0df0)
at /home/wiconlab/Car2x/artery-master/src/artery/application/Middleware.cc:283
#15 0x00007ffff682e477 in omnetpp::cSimulation::doMessageEvent (this=0x7b6b10, msg=0x2ea0df0,
module=0x1d62c650) at csimulation.cc:669
#16 0x00007ffff682e152 in omnetpp::cSimulation::executeEvent (this=0x7b6b10, event=0x2ea0df0)
at csimulation.cc:611
#17 0x00007ffff74e9075 in omnetpp::qtenv::Qtenv::doRunSimulationExpress (this=0x7b8a50)
at qtenv.cc:968
#18 0x00007ffff74e8526 in omnetpp::qtenv::Qtenv::runSimulation (this=0x7b8a50,
mode=omnetpp::qtenv::RUNMODE_EXPRESS, until_time=..., until_eventnum=0, until_msg=0x0,
until_module=0x0, stopOnMsgCancel=true) at qtenv.cc:731
#19 0x00007ffff746ed8d in omnetpp::qtenv::MainWindow::runSimulation (this=0x252f060,
runMode=omnetpp::qtenv::RUNMODE_EXPRESS) at mainwindow.cc:507
#20 0x00007ffff74a80df in omnetpp::qtenv::MainWindow::on_actionExpressRun_triggered (this=0x252f060)
at mainwindow.h:98
#21 0x00007ffff74a7a3f in omnetpp::qtenv::MainWindow::qt_static_metacall (_o=0x252f060,
_c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x7fffffffc740) at moc_mainwindow.cpp:273
#22 0x00007ffff74a7f7c in omnetpp::qtenv::MainWindow::qt_metacall (this=0x252f060,
_c=QMetaObject::InvokeMetaMethod, _id=5, _a=0x7fffffffc740) at moc_mainwindow.cpp:363
#23 0x00007ffff44aaee0 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007ffff3cba412 in QAction::triggered(bool) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#25 0x00007ffff3cbc898 in QAction::activate(QAction::ActionEvent) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#26 0x00007ffff3dc25a0 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#27 0x00007ffff3dc26d4 in QAbstractButton::mouseReleaseEvent(QMouseEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#28 0x00007ffff3e8726a in QToolButton::mouseReleaseEvent(QMouseEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#29 0x00007ffff3d06fc8 in QWidget::event(QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#30 0x00007ffff3e87349 in QToolButton::event(QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#31 0x00007ffff3cc405c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#32 0x00007ffff3cc9c19 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#33 0x00007ffff447c38b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007ffff3cc8b32 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#35 0x00007ffff3d215bb in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#36 0x00007ffff3d23b7b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#37 0x00007ffff3cc405c in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#38 0x00007ffff3cc9516 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#39 0x00007ffff447c38b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#40 0x00007ffff47be4e1 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#41 0x00007ffff47c01a5 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#42 0x00007ffff47a3f08 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#43 0x00007fffd1b74200 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#44 0x00007fffefd69197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#45 0x00007fffefd693f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#46 0x00007fffefd6949c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#47 0x00007ffff44d27cf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#48 0x00007ffff4479b4a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#49 0x00007ffff4481bec in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#50 0x00007ffff74e7ce6 in omnetpp::qtenv::Qtenv::doRun (this=0x7b8a50) at qtenv.cc:628
#51 0x00007ffff78f8ba0 in omnetpp::envir::EnvirBase::run (this=0x7b8a60) at envirbase.cc:748
#52 0x00007ffff78f5ed8 in omnetpp::envir::EnvirBase::run (this=0x7b8a60, argc=6,
argv=0x7fffffffda98, configobject=0x7bc750) at envirbase.cc:337
#53 0x00007ffff78ee1f9 in omnetpp::envir::setupUserInterface (argc=6, argv=0x7fffffffda98)
at startup.cc:259
#54 0x00007ffff78ef930 in omnetpp::envir::evMain (argc=6, argv=0x7fffffffda98) at evmain.cc:33
#55 0x0000000000402340 in main (argc=6, argv=0x7fffffffda98) at opp_run.cc:321
The assertion in line 24 of LocalDynamicMap tries to ensure that only recent CAMs are added. In the lines before, the full CAM generation time stamp is reconstructed from the truncated generationDeltaTime time stamp. Maybe something went wrong there but I can hardly tell without further information. Can you provide details about your modifications? This may help to reproduce this error.
Also, I suggest to run the simulation with the debugger by invoking the debug_example target. Please make sure to set CMAKE_BUILD_TYPE to "Debug" to enable this target. When the assertion fails you have then the chance to look at the variables in detail: What is the exact OMNeT++ simulation time, i.e. "print simTime().dbl()" with gdb? What is the CAM's generationDeltaTime? What is the reconstruced tai value? What is the time base (mTimebase) of LocalDynamicMap's timer (mTimer)?
Addendum 1: CMake variables can be easily modified from the command line using ccmake or with cmake-gui if you prefer a graphical user interface. Example: Go to your Artery build directory (usually simply called "build") and call "ccmake ." from there. In the then opened command line interface move the cursor to the CMAKE_BUILD_TYPE entry, press [Enter] and modify this entry to "Debug". Finish by pressing [c] to run CMake configuration stage and [g] to generate an updated Makefile in your build directory.
Why are none of the addresses from the gdb backtrace output present in the otx (otool) assembly output of this program? I was under the impression that they corresponded to the offsets in my otool asm output... I apologize if this is a silly question.
(gdb) bt
#0 0x9a4e1aa2 in __semwait_signal ()
#1 0x9a4e175e in _pthread_cond_wait ()
#2 0x9a4e12b1 in pthread_cond_timedwait$UNIX2003 ()
#3 0x0d8f3f87 in unregister_ShockwaveFlash ()
#4 0x0d45cf19 in dyld_stub_write$UNIX2003 ()
#5 0x0d6f9d7e in dyld_stub_write$UNIX2003 ()
#6 0x0d72db5a in dyld_stub_write$UNIX2003 ()
#7 0x0d72e24c in dyld_stub_write$UNIX2003 ()
#8 0x0d8eb5a2 in unregister_ShockwaveFlash ()
#9 0x0d95b9c9 in unregister_ShockwaveFlash ()
#10 0x9277df60 in CAOpenGLLayerDraw ()
#11 0x9277e897 in -[CAOpenGLLayer _display] ()
#12 0x92503ef1 in CALayerDisplayIfNeeded ()
#13 0x925032bc in CA::Context::commit_transaction ()
#14 0x92502f04 in CA::Transaction::commit ()
#15 0x958a1dd2 in __CFRunLoopDoObservers ()
#16 0x9585d3ea in CFRunLoopRunSpecific ()
#17 0x9585d1f1 in CFRunLoopRunInMode ()
#18 0x95530e04 in RunCurrentEventLoopInMode ()
#19 0x95530bb9 in ReceiveNextEventCommon ()
#20 0x956b9084 in _AcquireNextEvent ()
#21 0x956aed40 in RunApplicationEventLoop ()
#22 0x100083e2 in fkDecode ()
#23 0x10026167 in fkCall ()
#24 0x100081f6 in fkDecode ()
#25 0x10026167 in fkCall ()
#26 0x100081f6 in fkDecode ()
#27 0x10003be5 in fkRunMain ()
#28 0x00001e84 in main ()</code>
The followings may help you :
Variables defined in Global and Local Scope may have different address due to Address Space Layout Randomization (ASLR)
Heap allocated variables may have different address due to ASLR, if your program is multi-threaded
On Linux GDB is by default disables ASLR. Try it on Mac disabling ASLR.
I have a recurring intermittent EXC_BAD_ACCESS crash documented here.
This question: What steps can I take to make sure that this isn't a framework/lib error, and is actually a fault with my code? (Aside from the obvious, yes, duh, it's my code.)
I'm struggling with Instruments and getting a stack trace; are there resources I should be using to learn about this aspect of programming?
EDIT: I think this is a stack trace:
#0 0x0000cad8 in std::string ofToString<float>(float const&) at /Developer/of_007_iphone/libs/openFrameworks/utils/ofUtils.h:79
#1 0x000064ac in testApp::draw() ()
#2 0x0036d78c in ofAppiPhoneWindow::timerLoop() ()
#3 0x0037e698 in -[ofxiPhoneAppDelegate timerLoop] ()
#4 0x3095cbde in __NSFireTimer ()
#5 0x3579eca0 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ ()
#6 0x3579e6ac in __CFRunLoopDoTimer ()
#7 0x3576e300 in __CFRunLoopRun ()
#8 0x3576dd7a in CFRunLoopRunSpecific ()
#9 0x3576dc88 in CFRunLoopRunInMode ()
#10 0x336ace8c in GSEventRunModal ()
#11 0x318f0f94 in -[UIApplication _run] ()
#12 0x318ee4d4 in UIApplicationMain ()
#13 0x0036e9c4 in ofAppiPhoneWindow::runAppViaInfiniteLoop(ofBaseApp*) ()
#14 0x003a6804 in ofRunApp(ofBaseApp*) ()
#15 0x00002b34 in main ()
Ok, and another one. Wasn't even sure this was a separate error before:
#0 0x00019244 in std::vector<std::complex<float>, std::allocator<std::complex<float> > >::capacity() const at /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/include/c++/4.2.1/bits/stl_vector.h:434
#1 0x00026608 in std::vector<std::complex<float>, std::allocator<std::complex<float> > >::operator=(std::vector<std::complex<float>, std::allocator<std::complex<float> > > const&) at /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/include/c++/4.2.1/bits/vector.tcc:137
#2 0x00018708 in Analyzer::calcFFT() at /Developer/of_007_iphone/apps/cwi007/iTicTacToe/src/gameplay/pitch.cc:86
#3 0x0001881c in Analyzer::process() at /Developer/of_007_iphone/apps/cwi007/iTicTacToe/src/gameplay/pitch.cc:197
#4 0x00004378 in testApp::audioIn(float*, int, int) at /Developer/of_007_iphone/apps/cwi007/iTicTacToe/src/testApp.mm:362
#5 0x004a3fa0 in recordingCallback(void*, unsigned long*, AudioTimeStamp const*, unsigned long, unsigned long, AudioBufferList*) at /Developer/of_007_iphone/libs/openFrameworks/sound/ofxiPhoneSoundStream.mm:143
#6 0x361ccae0 in AUIOHelper::NotifyInputAvailable(AudioTimeStamp const&, unsigned long, AudioBufferList const&) ()
#7 0x361b9b90 in AURemoteIO::PerformIO(unsigned int, unsigned int, XAudioTimeStamp const&, XAudioTimeStamp const&, int&) ()
#8 0x361b9cfc in AURIOCallbackReceiver_PerformIO ()
#9 0x361b0fcc in _XPerformIO ()
#10 0x360dccbc in mshMIGPerform ()
#11 0x36173850 in MSHMIGDispatchMessage ()
#12 0x361c0b5c in AURemoteIO::IOThread::Entry(void*) ()
#13 0x3609ebb4 in CAPThread::Entry(CAPThread*) ()
#14 0x33c14684 in _pthread_start ()
The first step is to look at the stack trace in the Debugger Navigator or the crash log. Find the crashed thread and look at its stack. If any of your own code is in there, chances are it was your fault.
It won't stand up in court. For one thing, you might have done everything right and tripped a bug in framework or library code, and the moment where you tripped their bug is the moment caught in the stack trace (since that's where the crash happened). It's rare, but it does happen.
The other thing is that if you don't see your own code in the stack trace of the crashed thread, that doesn't prove you innocent. Your code might be guilty on another thread (usually indicating a thread-safety violation: you did something thread-unsafe, either knowingly on another thread without knowing it was unsafe or unknowingly on the wrong thread). Or you might be guilty in the past, having set up a crash to occur (e.g., by over-releasing an object) that occurred later (by messaging the dead object).
No matter what, the only way to determine whose bug it is is to investigate. Find where the crash happened, find what happened, and find why it happened. Once you know those three things, you'll know who did it, and whether you have to fix it (your bug) or report it and work around it (someone else's).
I have a release version server process running under linux 64-bit systems. It got crashed and left a coredump file. I use gdb to debug it like this:
gdb svr coredump file
And got the following backtraces:
(gdb) where
#0 0x0000000000432691 in ?? ()
#1 0x00002b07655a50cc in ?? ()
#2 0x00002b07655a50c4 in ?? ()
#3 0x00007fff9fade920 in ?? ()
#4 0x0000000000439db3 in ?? ()
#5 0x00007fff9fade910 in ?? ()
#6 0x00007fff9fade910 in ?? ()
#7 0x00007fff9fade8e0 in ?? ()
#8 0x00000000004663e2 in ?? ()
#9 0x00007fff9fade910 in ?? ()
#10 0x00007fff9fade910 in ?? ()
#11 0x00007fff9fade930 in ?? ()
#12 0x0000000000605108 in ?? ()
#13 0x00002b07655a274c in ?? ()
#14 0x0000000000ebc678 in ?? ()
#15 0x169f49f100000001 in ?? ()
#16 0x00000000021dc6c0 in ?? ()
#17 0x00002b07655a284c in ?? ()
#18 0x00002b07655a27dc in ?? ()
#19 0x00007fff9fade960 in ?? ()
#20 0x000000000043a03b in ?? ()
#21 0x00007fff9fade960 in ?? ()
#22 0x0000000000994d02 in ?? ()
#23 0x00000000000ecd57 in ?? ()
#24 0x00002b07655a274c in ?? ()
#25 0x00002b07655a274c in ?? ()
#26 0x00002b07655a27dc in ?? ()
#27 0x00007fff9fade980 in ?? ()
#28 0x000000000060a5eb in ?? ()
#29 0x000000009fadeb50 in ?? ()
#30 0x00002b07655a274c in ?? ()
#31 0x00007fff9fade9d0 in ?? ()
#32 0x000000000060a8f0 in ?? ()
#33 0x00007fff9fadeb50 in ?? ()
#34 0x00007fff9fadea10 in ?? ()
#35 0x00002b07655a274c in ?? ()
#36 0x00007fff9fadea10 in ?? ()
#37 0x000000009fade9d0 in ?? ()
#38 0x00007fff9fadeb58 in ?? ()
#39 0x0000000000000000 in ?? ()
The address info can not be analyzed by addr2line, what is the problem and how can I find what is the root cause of coredump?
Thanks!
Are you running GDB on the machine on which the core dump was produced?
For GDB to correctly reconstruct the crash stack trace, it must have access to exact binaries which were used at the time of the crash (or you get garbage).
The easiest way to achieve this is to analyze the core on the machine on which it was produced. If that's not feasible, you must copy all shared libraries to e.g. /tmp/solib-on-server/ (preserve the path, so e.g. /lib/libc.so.6 goes into /tmp/solib-on-server/lib/libc.so.6), then use GDB set solib-absolute-prefix /tmp/solib-on-server command before loading the core. E.g.
gdb -ex 'set solib-absolute-prefix /tmp/solib-on-server' \
-ex 'core /path/to/core' /path/to/executable
Its very hard to debug programs without debug symbols. As you are using release version of the application the core dump will not contain any debug information.
I am not sure, but if you can correlate the stack trace with the ".map" file of your application you could be getting somewhere. If I was in your position I would have recompiled the app with debug symbols(-g compiler flag) and then proceed on debugging.
You can use below commands in gdb to set shared library path.
set solib-search-path [Directories]
[Directories] : paths separated by colon(Ex /usr/lib:/usr/lib64)
show solib-search-path
These two commands helped me to get some info.