I wanted to try to build and modify Chromium in order to try and learn a few things. When I first built it and ran it (without any changes), it worked perfectly fine, however I tried changes some of the branding in order to tinker with it and it gave me an error message. I referred to two places when rebranding to see where I could change the branding:
First link
Second link
When I ran the modified version, it gave me an error message when running:
[0808/205916.858263:FATAL:bundle_locations.mm(62)] Check failed: new_bundle. Failed to load the bundle at /path/to/src/out/buildTwo/RebrandName.app/Contents/Frameworks/Chromium Framework.framework/Versions/94.0.4601.0
0 libbase.dylib 0x000000010a123638 base::debug::CollectStackTrace(void**, unsigned long) + 12
1 libbase.dylib 0x000000010a00e774 base::debug::StackTrace::StackTrace() + 24
2 libbase.dylib 0x000000010a032c1c logging::LogMessage::~LogMessage() + 184
3 libbase.dylib 0x000000010a033914 logging::LogMessage::~LogMessage() + 12
4 libbase.dylib 0x0000000109ffa0f0 logging::CheckError::~CheckError() + 36
5 libbase.dylib 0x000000010a139d5c base::mac::AssignOverridePath(base::FilePath const&, NSBundle**) + 176
6 libchrome_dll.dylib 0x0000000104ceb5d0 SetUpBundleOverrides() + 40
7 libchrome_dll.dylib 0x0000000104ce8f44 ChromeMain + 156
8 RebrandName 0x00000001049b7cc0 main + 284
9 libdyld.dylib 0x000000018efcd450 start + 4
zsh: trace trap out/buildTwo/RebrandName.app/Contents/MacOS/RebrandName
I tried to investigate to see what might have happened and saw that /path/to/src/out/buildTwo/RebrandName.app/Contents/Frameworks/Chromium Framework.framework but in it's place is /path/to/src/out/buildTwo/RebrandName.app/Contents/Frameworks/RebrandName Framework.framework
I ran out/buildTwo/RebrandName.app/Contents/MacOS/RebrandName and this error popped up.
This is currently running on an M1 Macbook Pro on MacOS Big Sur.
I have tried searching for the fix with no luck. Please understand that I have little to no idea of what I'm doing, so if more clarification is required, please let me know and I will try to edit my question as best as I can.
The file:
chrome/common/chrome_constants.cc
Change PRODUCT_STRING constant
Related
When debugging my Swift iOS project that also contains Objective-C parts, I cannot use breakpoints otherwise the debug server crashes, logging:
Message from debugger: The LLDB RPC server has crashed. The crash log is located in
~/Library/Logs/DiagnosticReports and has a prefix 'lldb-rpc-server'. Please file a bug and
attach the most recent crash log.
I am using the latest Xcode (11.5) but this happens since a number of updates. I suspect this started to happen at the time one of the latest Xcode updates has been installed but I am not 100% sure.
I know this question can be a duplicate, so I will add as much details as I can. The log contains, at the top:
Process: lldb-rpc-server [57486]
Path: /Applications/Xcode.app/Contents/SharedFrameworks/LLDBRPC.framework/Versions/A/Resources/lldb-rpc-server
Identifier: lldb-rpc-server
Version: 2
Code Type: X86-64 (Native)
Parent Process: Xcode [44264]
Responsible: Xcode [44264]
User ID: 501
Date/Time: 2020-06-27 20:11:09.502 +0200
OS Version: Mac OS X 10.15.5 (19F101)
Report Version: 12
Bridge OS Version: 4.5 (17P5300)
Anonymous UUID: AAD489A9-72D8-BF2A-EF2C-48E06D701EBA
Sleep/Wake UUID: 4DA8CC95-35BE-4383-A87D-E24E0A2C6A42
Time Awake Since Boot: 130000 seconds
Time Since Wake: 11000 seconds
System Integrity Protection: disabled
Crashed Thread: 9 RPC packet thread for client tid 002da567 (2991463)
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [57486]
Then, I will attach the crashing thread log:
Thread 9 Crashed:: RPC packet thread for client tid 002da567 (2991463)
0 com.apple.LLDB.framework 0x0000000109aff3f2 clang::ASTReader::ReadSLocEntry(int) + 226
1 com.apple.LLDB.framework 0x000000010a68e7ca clang::SourceManager::getFileIDLoaded(unsigned int) const + 618
2 com.apple.LLDB.framework 0x000000010a358a24 clang::SourceManager::getDecomposedLoc(clang::SourceLocation) const + 148
3 com.apple.LLDB.framework 0x0000000109b1f3ab clang::ASTReader::ReadPragmaDiagnosticMappings(clang::DiagnosticsEngine&) + 1131
4 com.apple.LLDB.framework 0x0000000109b1bf89 clang::ASTReader::InitializeContext() + 969
5 com.apple.LLDB.framework 0x0000000109b1b039 clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule>*) + 3833
6 com.apple.LLDB.framework 0x00000001098ca8da clang::CompilerInstance::loadModule(clang::SourceLocation, llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, clang::Module::NameVisibilityKind, bool) + 11034
7 com.apple.LLDB.framework 0x0000000107e00f47 swift::ClangImporter::Implementation::loadModuleClang(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >)::$_6::operator()(llvm::ArrayRef<std::__1::pair<clang::IdentifierInfo*, clang::SourceLocation> >, bool) const + 311
8 com.apple.LLDB.framework 0x0000000107e00cb5 swift::ClangImporter::Implementation::loadModuleClang(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 869
9 com.apple.LLDB.framework 0x0000000107e01320 swift::ClangImporter::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 32
10 com.apple.LLDB.framework 0x0000000107d4c3f1 swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>, bool) + 881
11 com.apple.LLDB.framework 0x0000000107d7c1ab swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc, bool) + 1627
12 com.apple.LLDB.framework 0x0000000107dd64a2 swift::SerializedModuleLoaderBase::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, llvm::StringRef, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool, bool) + 642
13 com.apple.LLDB.framework 0x0000000107dd83d4 swift::SerializedModuleLoaderBase::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 452
14 com.apple.LLDB.framework 0x0000000107f09884 swift::ASTContext::getModule(llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 244
15 com.apple.LLDB.framework 0x0000000107d4c34c swift::ModuleFile::getModule(llvm::ArrayRef<swift::Identifier>, bool) + 716
16 com.apple.LLDB.framework 0x0000000107d7c1ab swift::ModuleFile::associateWithFileContext(swift::FileUnit*, swift::SourceLoc, bool) + 1627
17 com.apple.LLDB.framework 0x0000000107dd64a2 swift::SerializedModuleLoaderBase::loadAST(swift::ModuleDecl&, llvm::Optional<swift::SourceLoc>, llvm::StringRef, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, std::__1::unique_ptr<llvm::MemoryBuffer, std::__1::default_delete<llvm::MemoryBuffer> >, bool, bool) + 642
18 com.apple.LLDB.framework 0x0000000107dd85dd swift::MemoryBufferSerializedModuleLoader::loadModule(swift::SourceLoc, llvm::ArrayRef<std::__1::pair<swift::Identifier, swift::SourceLoc> >) + 285
19 com.apple.LLDB.framework 0x0000000107f09bb5 swift::ASTContext::getModuleByName(llvm::StringRef) + 773
20 com.apple.LLDB.framework 0x0000000106edea5d lldb_private::SwiftASTContext::GetModule(lldb_private::SourceModule const&, lldb_private::Status&) + 749
21 com.apple.LLDB.framework 0x0000000106eed644 LoadOneModule(lldb_private::SourceModule const&, lldb_private::SwiftASTContext&, std::__1::weak_ptr<lldb_private::StackFrame>&, llvm::SmallVectorImpl<swift::SourceFile::ImportedModuleDesc>&, lldb_private::Status&) + 516
22 com.apple.LLDB.framework 0x0000000106eedf79 lldb_private::SwiftASTContext::PerformAutoImport(lldb_private::SwiftASTContext&, lldb_private::SymbolContext&, std::__1::weak_ptr<lldb_private::StackFrame>&, swift::SourceFile*, lldb_private::Status&) + 281
23 com.apple.LLDB.framework 0x0000000106f4f13b lldb_private::Target::GetScratchSwiftASTContext(lldb_private::Status&, lldb_private::ExecutionContextScope&, bool) + 1291
24 com.apple.LLDB.framework 0x0000000106dc233c lldb_private::ValueObject::GetScratchSwiftASTContext() + 108
25 com.apple.LLDB.framework 0x0000000106f88744 lldb_private::SwiftLanguageRuntime::GetDynamicTypeAndAddress(lldb_private::ValueObject&, lldb::DynamicValueType, lldb_private::TypeAndOrName&, lldb_private::Address&, lldb_private::Value::ValueType&) + 148
26 com.apple.LLDB.framework 0x000000010711b8ff lldb_private::SwiftLanguage::GetPossibleFormattersMatches(lldb_private::ValueObject&, lldb::DynamicValueType) + 303
27 com.apple.LLDB.framework 0x0000000106dd5654 lldb_private::FormatManager::GetPossibleMatches(lldb_private::ValueObject&, lldb_private::CompilerType, unsigned int, lldb::DynamicValueType, std::__1::vector<lldb_private::FormattersMatchCandidate, std::__1::allocator<lldb_private::FormattersMatchCandidate> >&, bool, bool, bool, bool) + 1492
28 com.apple.LLDB.framework 0x0000000106dd4a85 lldb_private::FormattersMatchData::GetMatchesVector() + 117
29 com.apple.LLDB.framework 0x0000000106de6a08 void lldb_private::TypeCategoryMap::Get<std::__1::shared_ptr<lldb_private::TypeSummaryImpl> >(lldb_private::FormattersMatchData&, std::__1::shared_ptr<lldb_private::TypeSummaryImpl>&) + 392
30 com.apple.LLDB.framework 0x0000000106dd9420 std::__1::shared_ptr<lldb_private::TypeSummaryImpl> lldb_private::FormatManager::GetCached<std::__1::shared_ptr<lldb_private::TypeSummaryImpl> >(lldb_private::FormattersMatchData&) + 448
31 com.apple.LLDB.framework 0x0000000106dd739c std::__1::shared_ptr<lldb_private::TypeSummaryImpl> lldb_private::FormatManager::Get<std::__1::shared_ptr<lldb_private::TypeSummaryImpl> >(lldb_private::ValueObject&, lldb::DynamicValueType) + 60
32 com.apple.LLDB.framework 0x0000000106dd734e lldb_private::FormatManager::GetSummaryFormat(lldb_private::ValueObject&, lldb::DynamicValueType) + 14
33 com.apple.LLDB.framework 0x0000000106dd18c3 lldb_private::DataVisualization::GetSummaryFormat(lldb_private::ValueObject&, lldb::DynamicValueType) + 51
34 com.apple.LLDB.framework 0x0000000106dbd827 lldb_private::ValueObject::UpdateFormatsIfNeeded() + 439
35 com.apple.LLDB.framework 0x0000000106dc358e lldb_private::ValueObject::CalculateSyntheticValue(bool) + 94
36 com.apple.LLDB.framework 0x0000000106dc3842 lldb_private::ValueObject::GetSyntheticValue(bool) + 34
37 com.apple.LLDB.framework 0x0000000106d2cd5d ValueImpl::GetSP(lldb_private::ProcessRunLock::ProcessRunLocker&, std::__1::unique_lock<std::__1::recursive_mutex>&, lldb_private::Status&) + 557
38 com.apple.LLDB.framework 0x0000000106d1b33b lldb::SBValue::GetSP(ValueLocker&) const + 139
39 com.apple.LLDB.framework 0x0000000106d1bf4b lldb::SBValue::GetValueType() + 187
40 lldb-rpc-server 0x00000001068a39e4 rpc_server::_ZN4lldb7SBValue12GetValueTypeEv::HandleRPCCall(rpc_common::Connection&, rpc_common::RPCStream&, rpc_common::RPCStream&) + 36
41 lldb-rpc-server 0x00000001068a6ce1 rpc_common::Connection::PrivateHandleRPCPacket(rpc_common::RPCPacket&, rpc_common::RPCPacket&, bool&) + 1553
42 lldb-rpc-server 0x00000001068aa36d Packets::ProcessPackets() + 1005
43 lldb-rpc-server 0x00000001068a9e96 Packets::ReadThread() + 214
44 lldb-rpc-server 0x00000001068a9db9 Packets::RunReadThread(void*) + 9
45 libsystem_pthread.dylib 0x00007fff72ea4109 _pthread_start + 148
46 libsystem_pthread.dylib 0x00007fff72e9fb8b thread_start + 15
Only in a few cases, I can temporally solve the problem by deleting the app from the simulator / device and cleaning the project in Xcode.
I have tried the following:
I completely removed all Cocoapods related stuff from the project, and replaced Cocoapods dependencies with mostly Carthage, and a few libraries added by and with their entire source. The problem persists.
After Cocoapods deintegrate, I tried to remove all remaining entries referencing Cocoapods from the build settings.
The problem persists and it must be something project specific since I don't experience it on any other project. I even tried to attach hopper disassembler to the debug server to better follow the crash, but for the moment I have not found the root cause of the problem. Any help will be greatly appreciated.
EDIT:
After countless hours, I could at least determine a further important detail: The crash occurs only when I set the configuration to Debug, it never happens in Release. I am now changing the different build settings one by one. This is a very lengthy process because the issue is consistent only 80% of the times, meaning that a bad configuration might temporarily work. The only certainty is that it has never occurred in Release mode. Thanks for your interest and help.
This isn’t a problem with breakpoints directly, they are just the first thing that causes lldb to read the debug information for your project. The crash is coming when lldb tries to reconstruct a clang module needed to bind some ObjC classes into the swift module info. There’s not much more to be gathered from the crash report. But the lldb “types” log will show what lldb was working on at the time of the crash. To generate that log, put the command:
log enable -f /tmp/lldb-log.txt lldb types
In your ~/.lldbinit, and redo your debug session. When it crashes, file a bug with the log and the crash with http://bugs.swift.org.
It may help to unset all project breakpoints, as well as unsetting all filters and actions to thrown errors and clean up, re-compile at least once before you set new breakpoints in an updated Xcode version.
Also check if you dont have exidently set breakpoint follow-ship in the debug icons row below your source while running. Uncheck at least once and try again.
Exact same error was driving me crazy unless i did the explained steps.
now i know where changes in Xcode's breakpoint management can lead to after an proper update.
I've coded a standalone Objective C command application. If I run it through a LaunchDaemon, it runs just fine when connected by an ObjC client application over DistriutedObjects communication. If I run it at command line, it runs just fine. If I run it when called by a Bash script, it runs just fine. However, in various ways that I've attempted to run this through the root user's crontab, it does a crash report about pointer allocation:
Apr 14 05:27:00 volomike cron[72531]: cron(72531,0x7fff7d2fa000) malloc: *** error for object 0x7fb9c8400213: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Apr 14 05:27:00 volomike diagnosticd[70689]: error evaluating process info - pid: 72531, puniqueid: 72531
Apr 14 05:27:00 volomike com.apple.xpc.launchd[1] (com.vix.cron[72531]): Service exited due to signal: Abort trap: 6
Apr 14 05:27:00 volomike com.apple.xpc.launchd[1] (com.apple.ReportCrash.Root[72550]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.ReportCrash.DirectoryService
Apr 14 05:27:00 volomike ReportCrash[72550]: Saved crash report for cron[72531] version 39 to /Library/Logs/DiagnosticReports/cron_2016-04-14-052700_volomike.crash
The significant part of that crash report reads:
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
*** error for object 0x7fb9c8400213: pointer being freed was not allocated
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff9490ff06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff9c45e4ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff9345b6e7 abort + 129
3 libsystem_malloc.dylib 0x00007fff9c02f041 free + 425
4 cron 0x000000010367aa41 0x103677000 + 14913
5 cron 0x000000010367a7e4 0x103677000 + 14308
6 cron 0x0000000103679572 0x103677000 + 9586
7 cron 0x000000010367925a 0x103677000 + 8794
8 cron 0x000000010367885e 0x103677000 + 6238
9 libdyld.dylib 0x00007fff949835ad start + 1
In the various ways, I've done it with these various cron lines, but they crash immediately when trying to call the command, and even when I have NSLog() writing stuff to /var/log/system.log all the way from the start of main to the end of the application, nothing writes -- it's like when cron tries to call my command, it dies immediately with a crash report about pointer allocation.
41 5 * * * /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched
41 5 * * * /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched &
41 5 * * * '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched
41 5 * * * '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched &
Note again that if I do '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched, it runs just fine, as does /bin/bash '/Applications/My App.app/Contents/Resources/mytoolcommand.sh' /q /sched, as does '/Applications/My App.app/Contents/Resources/mytoolcommand' /q /sched
I even did a variation where cron called my mytoolcommand.sh script and simply wrote Hello World to /tmp/out.txt, and it ran just fine. So, I know my crontab is working.
Can you help me figure out what I'm doing wrong? Some suspected possible issues:
Perhaps OSX El Capitan is shutting my application down for some reason, such as not being signed properly. (I'm debugging right now. I never had signature issues come up before unless it dealt with .app folders. Besides, I can run it just fine from command line without having a signature warning.)
I have debug messages loading from main() right off the bat. They should be writing to /var/log/system.log, but they're not. This tells me the application is crashing immediately when called by cron. So, is there something special I need to load into my application's libraries in order for it to run properly when called under cron?
DEVELOPMENTS
I suspected that El Capitan Gatekeeper may have been the cause. So, I created a simplistic Objective C console application like so in a main.mm file and compiled.
#import <Foundation/Foundation.h>
int main(int argc, const char * argv[]) {
#autoreleasepool {
NSString *sTest = #"Hello World";
[sTest writeToFile:#"/tmp/test.txt" atomically:YES encoding:NSUTF8StringEncoding error:nil];
}
return 0;
}
Cron seems to run this just fine, so it's not looking like a Gatekeeper problem.
I got the problem to go away, but only briefly. I recompiled the project in a brand new project, copying over source code and settings. I then ran the command through the cron about 4 times without an issue. However, when I ran it the fifth time, it failed again and continued failing.
So, I guess I'm going to have to figure out how to convert this into a LaunchAgent.
The answer is YOU DON'T. You don't use cron anymore on OSX for your applications you are coding. Instead, switch to a LaunchAgent. Sure, Apple keeps it around for POSIX support, and therefore may keep it around for a very long time, but even their website encourages people to no longer use cron for application coding.
"Note: Although it is still supported, cron is not a recommended
solution. It has been deprecated in favor of launchd."
SOURCE: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html
Unfortunately, though, LaunchAgents don't yet (in 10.11.4 at least) support cron-style syntax. (Yeah, I've already filed that suggestion to Apple for you.) So, there's no use of dash, comma, or backslash. Instead, it only supports an integer and multiple blocks to create each timeframe. And if that's not suitable enough, then set at least the most minimal timeframes and then do the rest of the code in whatever you are launching so that, for instance, if you want something only to run on the first Monday of the month, the LaunchDaemon launches in the first seven days but your application does a shutdown if it's not the first Monday of the month.
My script just does some hotkey replacements within the Mozilla Firefox window. It works for the most part, but after a few hotkey uses it goes haywire and forces the windows key pressed regardless of input. This makes it impossible to type.
1 sc163::!
2
3 SetTitleMatchMode, 2
4 #IfWinActive ahk_class MozillaWindowClass
5 #s::^w
6 Return
7 #d::^Tab
8 Return
9 sc163::^l
10 Return
11 AppsKey::^w
12 Return
13 RControl::^t
14 Return
15 RAlt::^+t
16 Return
17 RShift::^!b
18 Return
19 PgDn::^+Tab
20 Return
21 #IfWinActive
When I remove lines 5-8 that use the windows key, it no longer goes haywire, but I need those hotkey replacements. Is there anything wrong with my syntax that may be causing this issue?
After launching a few hotkeys, it will permanently press the windows key even if there is no physical input from me. As if it is ghost pressing the windows key. After launching task view(windows key + tab) and refocusing the Mozilla window, the issue goes away. But comes back shortly after doing the same thing. Removing the lines 5-8 that involve the windows key in the hotkey seems to fix the problem but I need those replacements so I'm not sure to approach this.
Thanks.
So I managed to fix by prepending send to the hotkey commands and making some of the combos less complex as it wasn't working well with ahk/FF in tandem.
My app is written both in objective c and c++. I'm using xcode 4.5 and of course I have developer account, my device is not jailbroken and I've set up everything in my developer account ok.
I do not use "Device Logs" from xcode, instead I've implemented signals/exceptions handlers to write stack traces to file and - when next time app launches - send it to my webserver.
To get stack trace on crash I use [NSException callStackSymbols]. It works. So when I do sample crash like:
NSArray *arr=[NSArray array];
[arr objectAtIndex:100];
while debugging in xcode and launching installed from xcode app on device I get:
0 CoreFoundation 0x36c738a7 __exceptionPreprocess + 186
1 libobjc.A.dylib 0x3308a259 objc_exception_throw + 32
2 CoreFoundation 0x36bcb23d -[__NSArrayI objectAtIndex:] + 164
3 MyApp 0x001be505 _ZN8Menu6handleEN12GestureE + 912
4 MyApp 0x000e6ce1 _ZN13BaseLevel10handleBaseEN12GestureE + 440
5 MyApp 0x0011b747 _ZN12Manager6handleEN12GestureE + 742
6 MyApp 0x00102731 _ZN13Processor9doProcessEd + 552
7 GLKit 0x3723a0c5 -[GLKViewController _updateAndDraw] + 272
8 CoreFoundation 0x36bd27d3 -[NSObject performSelector:] + 38
9 QuartzCore 0x3233486f _ZN2CA7Display11DisplayLink8dispatchEyy + 166
10 QuartzCore 0x323347c5 _ZN2CA7Display16IOMFBDisplayLink8callbackEP21__IOMobileFramebufferyyyPv + 60
MyApp c++ and objc classes and methods are symbolicated ok.
But when I make AdHoc ipa, and do the same crach in it I get:
0 CoreFoundation 0x36c738a7 __exceptionPreprocess + 186
1 libobjc.A.dylib 0x3308a259 objc_exception_throw + 32
2 CoreFoundation 0x36bcb23d -[__NSArrayI objectAtIndex:] + 164
3 MyApp 0x001be505 _mh_execute_header + 894213
4 MyApp 0x000e6ce1 _mh_execute_header + 11489
5 MyApp 0x0011b747 _mh_execute_header + 227143
6 MyApp 0x00102731 _mh_execute_header + 124721
7 GLKit 0x3723a0c5 -[GLKViewController _updateAndDraw] + 272
8 CoreFoundation 0x36bd27d3 -[NSObject performSelector:] + 38
9 QuartzCore 0x3233486f _ZN2CA7Display11DisplayLink8dispatchEyy + 166
10 QuartzCore 0x323347c5 _ZN2CA7Display16IOMFBDisplayLink8callbackEP21__IOMobileFramebufferyyyPv + 60]
i.e. names of my classes and methods are gone, replaced by symbol _mh_execute_header+<offset>.
I thought I've missed dSYM setting, but it is on for both release and debug, also "strip debug symbols" is off.
Have searched on SO, but no luck. Please tell me what's wrong?
My bad, I was not familar with symbolicate techs.
In short - to symbolicate stack trace you need dSYM of package and xcode to symbolicate the crash log with its private api. Maybe next time I'll write more: still learning how to do it in the most convenient (for me) way.
Edit: a week has passed, and I've developed a solution. It's specific to my multiplatform ecosystem, but here how it works in short. App crashes and sends crash log with all needed data to my server. When I want to see crash logs, I launch utility on my desktop which downloads all the stacks (from release/arm binaries) from the server, which are not proccessed yet. Next it finds corresponding bundles in Xcode Archives folder (gets uuids/vmaddr for arch needed), then calculates real addresses of stack lines (using binary vmaddr and _mh_execute_header address from received log) and calls atos for every address. Then it parses output of atos, generate diff and sends it back to server. This way I can see symbolicated stacks in my php-based bugtracker.
It was not so easy, as getting deobfuscated stacks in java, but still it's possible.
You can use this Symbolication tool I wrote to quickly Symbolicate your app's addresses.
symbolication your.app.dSYM your.app.trace
The symbolicated version will be printed to STDOUT. For best results, keep your .app in the same folder as your .dSYM.
https://github.com/Imperiopolis/Symbolication
I'm trying to get omnicomplete to work for C++, and while everything seems to be in order, when I reset my omnifunc to be omnifunc=omni#cpp#complete#Main, the plugin does not recognize the omnifunc, and I get a pattern not found error. I've installed Ctags and put it in .vim/<name_of_dir>, along with adding cpp_src to .vim/tags and running the necessary commands. (see here for more info)
The issue is that, no matter what I try, I still get this error. What can I do to get this working? I've tried this before, and the first time has just been a headache which resulted in me not being able to get it to work. This time, however, I'm determined.
VimRc
1 syntax on
2 set number
3 set autoindent
4 set ft=nasm
5 set ts=4
6 set nowrap
7 set nocp
8 filetype plugin on
9 map <C-F12> :!ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .<CR>
10
11 autocmd FileType cpp set omnifunc=omni#cpp#complete#Main
12
13 " configure tags - add additional tags here or comment out not-used ones
14 set tags+=~/.vim/tags/cpp
15 set tags+=~/.vim/tags/gl
16 set tags+=~/.vim/tags/sdl
17 " set tags+=~/.vim/tags/qt4
18 " " build tags of your own project with Ctrl-F12
19 map <C-F12> :!ctags -R --sort=yes --c++-kinds=+p --fields=+iaS --extra=+q .<CR>
20 "
21 " " OmniCppComplete
22 let OmniCpp_NamespaceSearch = 1
23 let OmniCpp_GlobalScopeSearch = 1
24 let OmniCpp_ShowAccess = 1
25 let OmniCpp_ShowPrototypeInAbbr = 1 " show function parameters
26 let OmniCpp_MayCompleteDot = 1 " autocomplete after .
27 let OmniCpp_MayCompleteArrow = 1 " autocomplete after ->
28 let OmniCpp_MayCompleteScope = 1 " autocomplete after ::
29 let OmniCpp_DefaultNamespaces = ["std", "_GLIBCXX_STD"]
30 " " automatically open and close the popup menu / preview window
31 au CursorMovedI,InsertLeave * if pumvisible() == 0|silent! pclose|endif
32 set completeopt=menuone,menu,longest,preview
As always, any help is much appreciated.
Update
Posting my Ctags file for others to inspect in case there is an issue with that:
ctags -R --c++-kinds=+p --fields-+iaS --extra=+q .
map <C-F12> :!ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .<CR>
Obviously, Vim can't find your tags file. Your command ctags -R --c++-kinds=+p --fields-+iaS --extra=+q . will create tags file in current directory. Make sure that this is what you want.
Please execute the following command:
:set tags?
and make sure your tags file is present in resulting list. You can also place cursor at any symbol (say, some class name) and press Ctrl-]. Vim will jump to this symbol definition if your tags is OK. If it is not, then, of course, omnicppcomplete will not work. (I use omnicppcomplete for more than year, and it works. Not perfectly with complicated classes/structs, but works.)
And, finally, check my answer here, because i would recommend absolutelly the same: to get perfect C/C++/Objective-C code completion you should use Clang Complete (no ctags is needed for this kind of completion).
And if you want tags to be present (say, to easily jump to symbol definition), please use Indexer plugin.