Interpreting the output of perf.data file using perf report - c++11

My C++ application was consuming a lot of CPU cycles. So I have profiled my application using the Linux profiler.The output of the profiler (perf.data) file was generated, and I have run perf report
The report is given below.
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 43K of event 'cpu-clock:uhH'
# Event count (approx.): 10966500000
#
# Overhead Command Shared Object Symbol
# ........ ............... ......................... ....................................................................................................................................................................................
#
59.19% ZManager libc-2.23.so [.] __mcount_internal
14.15% ZManager libc-2.23.so [.] _mcount
1.41% ZManager ZManager [.] std::vector<unsigned int, std::allocator<unsigned int> >::~vector
1.17% ZManager ZManager [.] std::vector<unsigned int, std::allocator<unsigned int> >::size
1.16% ZManager ZManager [.] std::vector<unsigned int, std::allocator<unsigned int> >::vector
0.46% ZManager ZManager [.] std::_Vector_base<unsigned int, std::allocator<unsigned int> >::_Vector_impl::_Vector_impl
0.45% ZManager ZManager [.] std::__copy_move_a2<false, __gnu_cxx::__normal_iterator<unsigned int const*, std::vector<unsigned int, std::allocator<unsigned int> > >, unsigned int*>
0.40% ZManager libpthread-2.23.so [.] pthread_mutex_lock
0.39% ZManager ZManager [.] std::__miter_base<__gnu_cxx::__normal_iterator<unsigned int const*, std::vector<unsigned int, std::allocator<unsigned int> > > >
0.38% ZManager libc-2.23.so [.] _int_malloc
0.36% ZManager ZManager [.] std::__niter_base<__gnu_cxx::__normal_iterator<unsigned int const*, std::vector<unsigned int, std::allocator<unsigned int> > > >
0.34% ZManager ZManager [.] std::allocator<unsigned int>::allocator
0.34% ZManager ZManager [.] std::allocator<unsigned int>::~allocator
From the above it is clear that majority of the CPU is consumed by some instruction in libc (which my program is calling)
It is shown as
59.19% ZManager libc-2.23.so [.] __mcount_internal
14.15% ZManager libc-2.23.so [.] _mcount
Does anyone know what __mcount_internal and _mcount means?

Related

Mac M1 assembly bus error with Sample Hello World display program [duplicate]

I'm writing in assembly using clang 13.1.6 with MacOS Monterey 12.5 on an ARM64 M1 Pro laptop.
If I try to use .dword/.xword in the .text section with the address of a label as its value, my program crashes on startup with a bus error.
Minimal reproducible example:
.text
.balign 4
.global _main
_main:
// accepted method to load from static address
adrp x1, vector#GOTPAGE
ldr x1, [x1, #vector#GOTPAGEOFF]
// now x1 contains the address of vector
ldr x2, [x1]
// now x2 should contain the address of dest
br x2
dest:
mov x0, #0
ret
vector:
.xword dest
This assembles and links without errors or warnings using cc reloc.s -o reloc, but bus errors immediately when run, apparently before even reaching my actual code. The backtrace from lldb is as follows:
* thread #1, stop reason = EXC_BAD_ACCESS (code=2, address=0x100003fb0)
frame #0: 0x000000010001da54 dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 60
dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const:
-> 0x10001da54 <+60>: str x19, [x20]
0x10001da58 <+64>: ldp x29, x30, [sp, #0x20]
0x10001da5c <+68>: ldp x20, x19, [sp, #0x10]
0x10001da60 <+72>: add sp, sp, #0x30
Target 0: (a.out) stopped.
(lldb) bt
* thread #1, stop reason = EXC_BAD_ACCESS (code=2, address=0x100003fb0)
* frame #0: 0x000000010001da54 dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 60
frame #1: 0x0000000100040fd4 dyld`invocation function for block in dyld3::MachOLoaded::fixupAllChainedFixups(Diagnostics&, dyld_chained_starts_in_image const*, unsigned long, dyld3::Array<void const*>, void (void*, void*) block_pointer) const + 424
frame #2: 0x0000000100041080 dyld`dyld3::MachOLoaded::walkChain(Diagnostics&, dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, unsigned short, bool, unsigned int, void (dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, bool&) block_pointer) const + 104
frame #3: 0x00000001000412b0 dyld`dyld3::MachOLoaded::forEachFixupInSegmentChains(Diagnostics&, dyld_chained_starts_in_segment const*, bool, void (dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, dyld_chained_starts_in_segment const*, bool&) block_pointer) const + 208
frame #4: 0x0000000100040e04 dyld`dyld3::MachOLoaded::forEachFixupInAllChains(Diagnostics&, dyld_chained_starts_in_image const*, bool, void (dyld3::MachOLoaded::ChainedFixupPointerOnDisk*, dyld_chained_starts_in_segment const*, bool&) block_pointer) const + 96
frame #5: 0x0000000100040d98 dyld`dyld3::MachOLoaded::fixupAllChainedFixups(Diagnostics&, dyld_chained_starts_in_image const*, unsigned long, dyld3::Array<void const*>, void (void*, void*) block_pointer) const + 120
frame #6: 0x000000010001da0c dyld`invocation function for block in dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 136
frame #7: 0x000000010001d788 dyld`dyld4::Loader::applyFixupsGeneric(Diagnostics&, dyld4::RuntimeState&, dyld3::Array<void const*> const&, dyld3::Array<void const*> const&, bool, dyld3::Array<dyld4::Loader::MissingFlatLazySymbol> const&) const + 204
frame #8: 0x0000000100021574 dyld`dyld4::JustInTimeLoader::applyFixups(Diagnostics&, dyld4::RuntimeState&, dyld4::DyldCacheDataConstLazyScopedWriter&, bool) const + 604
frame #9: 0x000000010000d904 dyld`dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 1928
frame #10: 0x000000010000d06c dyld`start + 488
The crash appears to be inside the dynamic linker, not in my code at all.
An even simpler example with the same behavior is:
.text
.balign 4
.global _main
_main:
ldr x1, =dest
br x1
dest:
mov x0, #0
ret
Here ldr x1, =dest is supposed to similarly assemble the address of dest into the literal pool (a nearby location within the .text section) and load from there into x1. This also bus errors.
Equivalent code works fine on ARM64 Linux.
Why is this, and how do I fix it?
Absolute addresses in the text section seem to be unsupported by ARM64 MacOS. As best I can tell, the dynamic linker tries to apply a relocation/fixup to store the actual runtime address of dest into vector, but crashes because .text is already mapped read-only.
So if you have an object that needs to be initialized with the address of a label or other object, then you need to put it in a data section, even if it is read-only. This is what clang does when compiling C/C++ code. For instance, if you write in C
const int i = 42;
const int * const ptr1 = &i;
const int * const ptr2 = NULL;
const int * const ptr3 = (const int *)0xdeadbeefcafed00dUL;
then i, ptr2, ptr3 all get preceded by .section __TEXT,__const, but ptr1 is preceded by .section __DATA,__const. The latter section is also read-only at runtime, but apparently is mapped read-write while relocation is done.
And you simply cannot use ldr x1, =label at all. Use instead adr or adrp / add as appropriate to generate the address in x1 if label is in the text section, or otherwise load it from the global offset table as appropriate.
It would be nice if the linker would detect this and warn you, instead of going ahead and building an executable that mysteriously crashes.

Crash in protobuf after upgrading to Mojave

After upgrading to Mojave the application started to crash in XCode debugger. It does run normally as a standalone application.
The backtrace looks like the following:
frames 0-5 call for the custom new, which is not initialized, the app initializes custom memory allocator in main
frame #6: 0x00007fff53ee006f libprotobuf.dylib`wireless_diagnostics::google::protobuf::(anonymous namespace)::InitGeneratedPool() + 20
frame #7: 0x00007fff53ecdd47 libprotobuf-lite.dylib`wireless_diagnostics::google::protobuf::internal::FunctionClosure0::Run() + 17
frame #8: 0x00007fff53ecdd1b libprotobuf-lite.dylib`wireless_diagnostics::google::protobuf::GoogleOnceInitImpl(long*, wireless_diagnostics::google::protobuf::Closure*) + 73
frame #9: 0x00007fff53edffbe libprotobuf.dylib`wireless_diagnostics::google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int) + 78
frame #10: 0x00007fff53edfbf9 libprotobuf.dylib`wireless_diagnostics::google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto() + 68
frame #11: 0x0000000117de8cc8 dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 518
frame #12: 0x0000000117de8ec6 dyld`ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
frame #13: 0x0000000117de40da dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 358
frame #14: 0x0000000117de406d dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
frame #15: 0x0000000117de406d dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
frame #16: 0x0000000117de406d dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
frame #17: 0x0000000117de406d dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
frame #18: 0x0000000117de406d dyld`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 249
frame #19: 0x0000000117de3254 dyld`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 134
frame #20: 0x0000000117de32e8 dyld`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 74
frame #21: 0x0000000117dd2756 dyld`dyld::initializeMainExecutable() + 169
frame #22: 0x0000000117dd778f dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 6237
frame #23: 0x0000000117dd14f6 dyld`dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 1154
frame #24: 0x0000000117dd1036 dyld`_dyld_start + 54
Xcode injects the dynamic library libViewDebuggerSupport.dylib, which causes the crash. And problematic *.dylib is
/System/Library/PrivateFrameworks/WirelessDiagnostics.framework/Versions/A/Libraries/libprotobuf.dylib
Fixing the custom allocator is the one of the options, but I want to avoid doing it.
Do you know any way to prevent XCode from injecting libViewDebuggerSupport.dylib?
It is appeared to be a bug in Mojave. Apple is working on fixing it, but they did not give me any ETA.
For now I fixed the crash by fixing my custom allocator.

app signed on sierra crashed on el capitan

I have an application built with Xcode , all third party frameworks and dylib-s are code signed separtly , Application works fine on os x sierra ( tested in different devices) but crashed on os x El Capitan with
Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)
( and again tested on several devices).
here is the stack trace on crash on El Capitan
Process: BeSafe [671] Path:
/Applications/BeSafe.app/Contents/MacOS/BeSafe Identifier:
com.onecryptor.besafe Version: 0.2.6.0 (0.2.6.0) Code
Type: X86-64 (Native) Parent Process: ??? [1]
Responsible: BeSafe [671] User ID: 501
Date/Time: 2017-05-22 14:12:38.209 +0400 OS Version:
Mac OS X 10.11 (15A284) Report Version: 11 Anonymous UUID:
48F622B8-8E74-B38C-B200-580A63C6EFA7
Time Awake Since Boot: 1400 seconds
System Integrity Protection: enabled
Crashed Thread: 0
Exception Type: EXC_BAD_ACCESS (Code Signature Invalid)
Exception Codes: 0x0000000000000032, 0x0000000107462000
Exception Note: EXC_CORPSE_NOTIFY
kernel messages:
-0 sec CODE SIGNING: cs_invalid_page(0x107462000): p=671[BeSafe] final status 0x3004200, denying page sending SIGKILL
-0 sec CODE SIGNING: process 671[BeSafe]: rejecting invalid page at address 0x107462000 from offset 0x0 in file
"/Applications/BeSafe.app/Contents/Frameworks/libboost_date_time-mt.dylib"
(cs_mtime:1495447699.0 == mtime:1495447699.0) (signed:1 validated:1
tainted:1 wpmapped:0 slid:0)
VM Regions Near 0x107462000:
__LINKEDIT 00000001073b3000-0000000107462000 [ 700K] r--/rwx SM=COW /Applications/BeSafe.app/Contents/MacOS/BeSafe
--> mapped file 0000000107462000-0000000107463000 [ 4K] r-x/r-x SM=PRV 1
VM_ALLOCATE 0000000107463000-0000000107464000 [ 4K] rw-/rwx SM=ALI
Application Specific Information: dyld: launch, loading dependent
libraries #executable_path/../Frameworks/libboost_date_time-mt.dylib
Thread 0 Crashed: 0 dyld
0x00007fff66b70a10 memcmp + 208 1 dyld
0x00007fff66b5d905
ImageLoaderMachO::validateFirstPages(linkedit_data_command const*,
int, unsigned char const*, unsigned long, long long,
ImageLoader::LinkContext const&) + 145 2 dyld
0x00007fff66b62b7b
ImageLoaderMachOCompressed::instantiateFromFile(char const*, int,
unsigned char const*, unsigned long, unsigned long long, unsigned long
long, stat const&, unsigned int, unsigned int, linkedit_data_command
const*, encryption_info_command const*, ImageLoader::LinkContext
const&) + 283 3 dyld 0x00007fff66b5ca6f
ImageLoaderMachO::instantiateFromFile(char const*, int, unsigned char
const*, unsigned long long, unsigned long long, stat const&,
ImageLoader::LinkContext const&) + 299 4 dyld
0x00007fff66b4f8c3 dyld::loadPhase6(int, stat const&, char const*,
dyld::LoadContext const&) + 402 5 dyld
0x00007fff66b54469 dyld::loadPhase5(char const*, char const*,
dyld::LoadContext const&, std::__1::vector >) + 710 6 dyld
0x00007fff66b54189 dyld::loadPhase4(char const, char const*,
dyld::LoadContext const&, std::__1::vector >) + 180 7 dyld
0x00007fff66b53c9f dyld::loadPhase3(char const, char const*,
dyld::LoadContext const&, std::__1::vector >) + 1019 8 dyld
0x00007fff66b53643 dyld::loadPhase1(char const, char const*,
dyld::LoadContext const&, std::__1::vector >) + 135 9 dyld
0x00007fff66b4f47b dyld::loadPhase0(char const, char const*,
dyld::LoadContext const&, std::__1::vector >) + 213 10 dyld
0x00007fff66b4f15f dyld::load(char const, dyld::LoadContext const&)
+ 180 11 dyld 0x00007fff66b54706 dyld::libraryLocator(char const*, bool, char const*,
ImageLoader::RPathChain const*) + 52 12 dyld
0x00007fff66b5a85e
ImageLoader::recursiveLoadLibraries(ImageLoader::LinkContext const&,
bool, ImageLoader::RPathChain const&) + 384 13 dyld
0x00007fff66b5a564 ImageLoader::link(ImageLoader::LinkContext const&,
bool, bool, bool, ImageLoader::RPathChain const&) + 80 14 dyld
0x00007fff66b50a12 dyld::link(ImageLoader*, bool, bool,
ImageLoader::RPathChain const&) + 149 15 dyld
0x00007fff66b51b97 dyld::_main(macho_header const*, unsigned long,
int, char const**, char const**, char const**, unsigned long*) + 3083
16 dyld 0x00007fff66b4d276
dyldbootstrap::start(macho_header const*, int, char const**, long,
macho_header const*, unsigned long*) + 512 17 dyld
0x00007fff66b4d036 _dyld_start + 54
Thread 0 crashed with X86 Thread State (64-bit): rax:
0x0000000000000000 rbx: 0x0000000107462000 rcx: 0x0000000000000000
rdx: 0x0000000000000768 rdi: 0x0000000107462000 rsi:
0x00007fff58bb6ad0 rbp: 0x00007fff58bb5d90 rsp: 0x00007fff58bb5d90
r8: 0x0000000000000003 r9: 0x0000000000000000 r10:
0x0000000000000001 r11: 0x0000000000000202 r12: 0x0000000000000000
r13: 0x0000000000000003 r14: 0x0000000000000768 r15:
0x00007fff66b8cce8 rip: 0x00007fff66b70a10 rfl: 0x0000000000010246
cr2: 0x0000000107462000 Logical CPU: 3 Error Code:
0x00000004 Trap Number: 14
Binary Images:
0x107046000 - 0x107375ffb +com.onecryptor.besafe (0.2.6.0 - 0.2.6.0) <880A6212-7110-317E-B4FA-1CF533E79AE5>
/Applications/BeSafe.app/Contents/MacOS/BeSafe
0x107465000 - 0x1074a1ff7 +org.sparkle-project.Sparkle (1.14.0 - 1.14.0) <85A19559-55A6-3BA3-AC85-543D647D8F30>
/Applications/BeSafe.app/Contents/Frameworks/Sparkle.framework/Versions/A/Sparkle
0x7fff66b4c000 - 0x7fff66b82f5f dyld (360.14) /usr/lib/dyld
External Modification Summary: Calls made by other processes
targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0 Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0 Calls made by all processes on this machine:
task_for_pid: 683
thread_create: 0
thread_set_state: 0
VM Region Summary: ReadOnly portion of Libraries: Total=4696K
resident=0K(0%) swapped_out_or_unallocated=4696K(100%) Writable
regions: Total=10.2M written=0K(0%) resident=0K(0%) swapped_out=0K(0%)
unallocated=10.2M(100%)
VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= ======= Process Corpse Info 2048K 2 STACK GUARD 56.0M 2
Stack 8192K 2 VM_ALLOCATE
4K 2
__DATA 536K 6
__LINKEDIT 968K 4
__TEXT 3728K 4 mapped file 4K 2 shared memory 8K 3
=========== ======= ======= TOTAL 71.1M 18
Model: iMac11,3, BootROM VirtualBox, 4 processors, 2.2 GHz, 2 GB, SMC
2.3f35 Graphics: Display, PCI, 3 MB Memory Module: Bank 0/DIMM 0, 2 GB, DRAM, 1600 MHz, innotek GmbH, - Network Service: Ethernet,
Ethernet, en0 Serial ATA Device: VBOX HARDDISK, 84.83 GB Serial ATA
Device: VBOX CD-ROM, 59.4 MB USB Device: USB Bus USB Device: USB
Tablet USB Device: USB Keyboard Thunderbolt Bus:

Patching a Mach-O binary with LC_LOAD_DYLIB requires reboot to work

I'm patching a Mach-O binary with a dylib (by appending a LC_LOAD_DYLIB command at the end of the load commands + adjusting the mach header's sizeofcmds + incrementing its ncmds) and I would expect to be able to compile over and over the dylib itself and just rerun the binary.
However, for some reason, when doing so, after the first run, the binary crashes for various reasons (e.g EXC_CRASH or EXC_BAD_ACCESS at different addresses)
If I restart the machine, everything works perfectly fine(the lib is patched and the exec runs). I bet this has to do with some obscure (for me at least) memory mapping or caching the dynamic linker does, but my expertise in that area is slim. Any chance you guys know something about it?
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fffd43d3829 map_images_nolock + 588
1 libobjc.A.dylib 0x00007fffd43d3521 map_2_images + 43
2 dyld 0x00000001164e5d4c dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*), bool, bool) + 1124
3 dyld 0x00000001164e5f25 dyld::registerObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 50
4 libdyld.dylib 0x00007fffd4cbd584 _dyld_objc_notify_register + 77
5 libobjc.A.dylib 0x00007fffd43d3074 _objc_init + 115
6 libdispatch.dylib 0x00007fffd4c84c64 _os_object_init + 13
7 libdispatch.dylib 0x00007fffd4c84c13 libdispatch_init + 295
8 libSystem.B.dylib 0x00007fffd36f1a02 libSystem_initializer + 121
9 dyld 0x00000001164f6063 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 385
10 dyld 0x00000001164f6266 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
11 dyld 0x00000001164f1bf0 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 338
12 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
13 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
14 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
15 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
16 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
17 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
18 dyld 0x00000001164f1b87 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 233
19 dyld 0x00000001164f0c60 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 138
20 dyld 0x00000001164f0cf5 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 75
21 dyld 0x00000001164e32f6 dyld::initializeMainExecutable() + 195
22 dyld 0x00000001164e7459 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 3789
23 dyld 0x00000001164e2249 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 470
24 dyld 0x00000001164e2036 _dyld_start + 54

Archive build is crashing on launch

Can anybody help me out, I'm getting error on app launch with archive build. Debug build is working fine.
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xffffffffffffffe8
VM Regions Near 0xffffffffffffffe8:
--> shared memory 00007fffffe36000-00007fffffe37000 [ 4K] r-x/r-x SM=SHM
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libc++.1.dylib 0x00007fff8fb6c4f1 std::__1::basic_istream<char, std::__1::char_traits<char> >::sentry::sentry(std::__1::basic_istream<char, std::__1::char_traits<char> >&, bool) + 29
1 libc++.1.dylib 0x00007fff8fb6e437 std::__1::basic_istream<char, std::__1::char_traits<char> >::tellg() + 191
2 ??? 0x000000010d0b44ee 0 + 4513809646
3 ??? 0x000000010d0b35d8 0 + 4513805784
4 ??? 0x000000010d1213cd 0 + 4514255821
5 ??? 0x000000010d18e5c7 0 + 4514702791
6 ??? 0x000000010d159251 0 + 4514484817
7 ??? 0x000000010d18df0a 0 + 4514701066
8 ??? 0x000000010d144b1a 0 + 4514401050
9 ??? 0x000000010d0b121a 0 + 4513796634
10 ??? 0x000000010d0b66b1 0 + 4513818289
11 dyld 0x00007fff659f1d0b ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 265
12 dyld 0x00007fff659f1e98 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
13 dyld 0x00007fff659ee891 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 305
14 dyld 0x00007fff659ee718 ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 138
15 dyld 0x00007fff659ee989 ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 75
16 dyld 0x00007fff659e1245 dyld::initializeMainExecutable() + 187
17 dyld 0x00007fff659e4c19 dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 2669
18 dyld 0x00007fff659e0276 dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) + 512
19 dyld 0x00007fff659e0036 _dyld_start + 54
This was due to library image not loaded in release build. I didn't added library in 'Linked Binary With Libraries'.

Resources