In my app i got crash report
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000
Crashed Thread: 7
In Thread 7 :
Thread 7 Crashed:
0 CoreFoundation 0x3728ba96 0x37278000 + 80534
1 CFNetwork 0x36617b84 0x36616000 + 7044
2 CFNetwork 0x36617af6 0x36616000 + 6902
3 MusicBandApp 0x0000bbfc 0x1000 + 44028
4 MusicBandApp 0x0000b740 0x1000 + 42816
5 Foundation 0x33b88382 0x33b6b000 + 119682
6 Foundation 0x33bfa5c6 0x33b6b000 + 587206
7 libsystem_c.dylib 0x3579530a 0x35762000 + 209674
8 libsystem_c.dylib 0x35796bb4 0x35762000 + 215988
but can"t show particular crash file name & line number.
How can sybolicate this crash report.
We need a file called symbolitecrash to process this file. This file can be located in /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources
Open the Terminal.
Copy symbolitecrash file to the default location shown when the terminal is opened.
eg. Terminal window :-
Last login: Wed Jun 22 15:28:21 on ttys000
UserMM:~ user$
Here, the default location is the directory "user".
Running this script with the -h option provides the minimal help:
UserMM:~ user$ symbolitecrash -h
usage:
/usr/local/bin/symbolicatecrash [-Ah] [-o ] LOGFILE [SYMBOL_PATH ...]
Symbolicates a crashdump LOGFILE which may be "-" to refer to stdin. By default,
all heuristics will be employed in an attempt to symbolicate all addresses.
Additional symbol files can be found under specified directories.
Options:
-A Only symbolicate the application, not libraries
-o If specified, the symbolicated log will be written to OUTPUT_FILE (defaults to stdout)
-h Display this message
-v Verbose
Place the .crash file in the same location where symbolitecrash file is copied.
To add symbols to the crash log you need the dSYM file generated by the linker when you compiled your application for AppStore. In other words, when you build for AppStore you should keep the dSYM package in a safe place backed up by Time Machine. This is very important. You should keep a copy of the dSYM for each version of your application ever shipped. If you have the package, translating code offsets to function names with line numbers has never been easier:
$ symbolicatecrash MiMo_2011-06-22-143801_Anands-Ipod.crash myApp.app.dSYM > myApp_2011-06-22-143801_Anands-Ipod1.crash
myApp_2011-06-22-143801_Anands-Ipod1.crash is the new crash file generated in the same location.
Here is the result:
Thread 0 Crashed:
0 libobjc.A.dylib 0x300c87ec objc_msgSend + 20
1 myApp 0x00006434 -[BoardView setSelectedPiece:] (BoardView.m :321)
I also described how to do this step by step in this post
It worked fine for me:
Crash Symbolized http://k.minus.com/jk4X2obwZMI7j.png
Related
With JabRef, we experience a weird situation where some users get the following error when starting JabRef
We do not ship a JRE with our application and rely on that Java is installed on the machine of the users.
We have a long issue on GitHub about this particular error and despite all our efforts, it seems we cannot find the source of the issue. Especially, since none of the devs can reproduce it. Fortunately, one of the users who experiences this error was kind enough to provide all information about his machine:
$ java -version
java version "1.8.0_161"
Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)
$ which java
/usr/bin/java
$ ls -l /usr/bin/java
lrwxr-xr-x 1 root wheel 74 Aug 14 12:09 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (2):
1.8.0_161, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
1.8.0_121, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
$ echo $JDK_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home
I asked this particular user to provide the INSTALL4J_LOG and so that we can compare the log-files of Install4J on my machine where it works and on the users machine where it fails.
My machine runs OS X 10.13.2 and the system of the user is OS X 10.12.6.
There are two main differences between them. The first difference is that when I invoke the JabRef launcher, it instantly tells me the order of places to search for Java:
2018-01-24 02:10:14.437 JavaApplicationStub[4846:345347] -[Launcher findJavaBundle:] [Line 479] search sequence (
EPATH,
Y,
"EJAVA_HOME",
"EJDK_HOME"
)
This is exactly the order we have configured in Install4J
On the users log-file this part is missing completely. However, it doesn't really matter, because the JRE/JDK is very rarely included in the $PATH variable. The next things to check are the default locations and this will find the JRE in Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin first.
Therefore, on my machine and on the users machine, JabRef will use this JRE and not any of additionally installed JDK's.
Now, there is the probably more important difference. On the machine of the user, it seems the JRE needs to be unpacked which does not happen for me:
2018-01-23 12:27:08.320 JavaApplicationStub[40695:1133965] -[Launcher findJavaBundle:] [Line 474] Running unpacker
2018-01-23 12:27:08.323 JavaApplicationStub[40695:1133965] +[Unpacker unpack:withProgress:] [Line 24] found ()
2018-01-23 12:27:08.323 JavaApplicationStub[40695:1133965] +[Unpacker unpack:withProgress:] [Line 24] found ()
After that, the logs look similar but when finally the JRE is invoked, it cannot be found on the user's machine and we get the error message
2018-01-23 12:27:08.328 JavaApplicationStub[40695:1133965] int launcher_main(int, char **) [Line 925] Could not load JRE from The bundle “Java SE 8” couldn’t be loaded because its executable couldn’t be located..: (
0 CoreFoundation 0x00007fff8ff882cb __exceptionPreprocess + 171
1 libobjc.A.dylib 0x00007fffa4d9e48d objc_exception_throw + 48
2 CoreFoundation 0x00007fff90006c3d +[NSException raise:format:] + 205
3 JavaApplicationStub 0x0000000100008644 -[Launcher launch] + 468
4 JavaApplicationStub 0x0000000100008ef5 launcher_main + 645
5 JavaApplicationStub 0x0000000100009062 main + 34
6 JavaApplicationStub 0x0000000100001504 start + 52
)
Now, I'm not sure why unpacking is necessary and if it can be explained by the particular JRE or the different Mac OS versions.
In any way, I have asked the user to install the Oracle JRE 1.8.0_161 so that we both have the exact same Java and I'll report back if this solved the problem.
However, has someone a bright idea why the Install4J launcher crashes?
I'm looking at a crash report provided by Apple
Hardware Model: iPhone4,1
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-11-18 16:03:44.951 -0600
OS Version: iOS 6.0.1 (10A523)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x352925b0 objc_msgSend + 16
1 MYAPP 0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42
2 MYAPP 0x0004fb26 -[MyImageTask didReceiveImage:] + 98
3 Foundation 0x361ac8e8 __NSThreadPerformPerform
4 CoreFoundation 0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
5 CoreFoundation 0x3b37cee4 __CFRunLoopDoSources0
6 CoreFoundation 0x3b37bcb2 __CFRunLoopRun
7 CoreFoundation 0x3b2eeeb8 CFRunLoopRunSpecific
8 CoreFoundation 0x3b2eed44 CFRunLoopRunInMode
9 GraphicsServices 0x396bc2e6 GSEventRunModal
10 UIKit 0x3452e2f4 UIApplicationMain
11 MYAPP 0x0004934a main + 70
12 MYAPP 0x000492fc start + 36
The funny thing is when I use atos to lookup the line of code that corresponds to address locations 0x0006573a and 0x0004fb26 I get completely different match. The atos output is not even from the same class that's mentioned in the crash log (MyViewController, MyImageTask). Instead atos points me to totally benign lines of code in a completely unrelated class. I verified again that I'm working with the exact dSYM and IPA that I submitted to Apple.
My atos command
/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26
Same result with /usr/bin/atos and for armv7s.
Has anyone else experienced this issue? Can you please advise? Thanks.
A simpler alternative: you can use the atos -l flag to make it do the maths for you.
Say you've got the following line in your crash log that you want to symbolicate:
5 MyApp 0x0044e89a 0x29000 + 4348058
The first hex number is the stack address, and the second hex number is the load address. You can ignore the last number. You don't need to worry about slide addresses either.
To symbolicate, do the following:
atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a
If you can't find your MyApp.app/MyApp file, rename your '.ipa' file to a '.zip', unzip it, and it'll be in the Payload folder.
And if you're not sure which architecture to use (for example, armv7 or armv7s), scroll to the 'Binary Images' part of the crash file and you can find it in there.
Cheers
You have to calculate the address to use with atos, you can't just use the one in the stacktrace.
symbol address = slide + stack address - load address
The slide value is the value of vmaddr in LC_SEGMENT cmd (Mostly this is 0x1000). Run the following to get it:
otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"
Replace ARCHITECTURE with the actual architecture the crash report shows, e.g. armv7.
Replace APP_BUNDLE/APP_EXECUTABLE with the path to the actual executable.
The stack address is the hex value from the crash report.
The load address can be is the first address showing in the Binary Images section at the very front of the line which contains your executable. (Usually the first entry).
Since in the past value of the slide was equal to value of the load address this always worked. But since Apple introduced Address space layout randomization beginning with iOS 4.3 (in different variations), the apps loading address is randomized for security reasons.
Simply use dwarfdump:
dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'
No need to do any calculations at all.
(From Get symbol by address (symbolicating binary, iOS build)).
For whom that certain times doesn't have the value for Load Address like this:
Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
0 CoreFoundation 0x2c3084b7 <redacted> + 150
1 libobjc.A.dylib 0x39abec8b objc_exception_throw + 38
2 CoreFoundation 0x2c21cc35 CFRunLoopRemoveTimer + 0
3 AppName 0x0005a7db AppName + 272347
I've created a simple bash to help me debug:
#! /bin/bash
read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7
It just reads the path for the app, the app name, the stack address, and the value after "+" signal (the decimal value) and then find the value for load address to run atos command.
I try to archive the ZxingWedget Demo,scanTest. compile is ok. it can run on the simulator.
but it can not archive completely on ios6.0.
this is the error:
Stripping /Users/ganguo/Library/Developer/Xcode/DerivedData/ScanTest-gadjcaxemklyqpcxsvmiorzakfhu/Build/Intermediates/ArchiveIntermediates/ScanTest/IntermediateBuildFilesPath/ZXingWidget.build/Release-iphoneos/ZXingWidget.build/Objects-normal/armv7/libZXingWidget.a
cd /Users/ganguo/objc/lib/zxing/iphone/ZXingWidget
setenv PATH "/Applications/app/Xcode45-DP4.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/app/Xcode45-DP4.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/app/Xcode45-DP4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -S /Users/ganguo/Library/Developer/Xcode/DerivedData/ScanTest-gadjcaxemklyqpcxsvmiorzakfhu/Build/Intermediates/ArchiveIntermediates/ScanTest/IntermediateBuildFilesPath/ZXingWidget.build/Release-iphoneos/ZXingWidget.build/Objects-normal/armv7/libZXingWidget.a
0 0x10eaf75f0 __assert_rtn + 144
1 0x10eb5ed12 ld::tool::FunctionStartsAtom<arm>::encode() const + 594
2 0x10eb4d05b ld::tool::OutputFile::updateLINKEDITAddresses(ld::Internal&) + 251
3 0x10eb483b8 ld::tool::OutputFile::write(ld::Internal&) + 136
4 0x10eaf7c5f main + 1263
A linker snapshot was created at:
/tmp/strip.7jH8OR-2012-07-16-113649.ld-snapshot
ld: Assertion failed: (addr != badAddress), function encode, file /SourceCache/ld64/ld64-134.5/src/ld/LinkEdit.hpp, line 1289.
/Applications/app/Xcode45-DP4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: internal link edit command failed
Command /Applications/app/Xcode45-DP4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip failed with exit code 1
I filed the bug (12176840) with Apple for this problem today.
Do a clean and try again. If it still fails, file a bug with Apple. This is an xcode/toolchain bug (in prerelease software).
I believe that the zxing library doesn't support the armv7 architecture yet. I would love to be wrong, though...
I'm having XCode (latest version) crash whenever I start up - can't get anything done until I resolve this - any ideas?
Error - See below
What I did prior to getting the issue
had put in a new HDD (and moved the old to the optical bay) - reinstalled XCode 4 on the new SSD - all working fine
I did rename my home directory user name on the "old" HDD to put "_OLD" at the end - just so I didn't get confused if jumping to the old HDD for files
I tried to open a test project from this old HDD area - got some issue opening it (can't remember details) - closed/restarted fromhere
Then after this every time I try to open XCode a fresh it's like it tries to open the last projects that was open including this one I had an issue with - get the below error - can't continue on using xcode have to crash out
Error:
ASSERTION FAILURE in /SourceCache/DVTFoundation/DVTFoundation-903/Framework/Classes/FilePaths/DVTFilePath.m:322
Details: fsrep is absolute (starts with tilde) ('~--814203924d469071-0000000000') parentPath must be nil but it is not ('<DVTFilePath:0x401bdf9e0:'/Volumes/Macintosh HD/Users/greg/.dvdcss'>')
Object: <DVTFilePath>
Method: +_filePathForParent:fileSystemRepresentation:length:allowCreation:
Thread: <NSThread: 0x40010a260>{name = (null), num = 1}
Hints: None
Backtrace:
0 0x0000000103f44466 -[IDEAssertionHandler handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in IDEKit)
1 0x00000001035b3794 _DVTAssertionFailureHandler (in DVTFoundation)
2 0x0000000103550a9e +[DVTFilePath _filePathForParent:fileSystemRepresentation:length:allowCreation:] (in DVTFoundation)
3 0x0000000103550963 +[DVTFilePath _filePathForParent:pathString:] (in DVTFoundation)
4 0x0000000103b95642 -[DVTFilePath(IDESourceControlStatus) IDESourceControl_importantSubpaths] (in IDEFoundation)
5 0x0000000103b414ac -[IDEFileReference _updateSourceControlStatusIfNeeded] (in IDEFoundation)
6 0x0000000103b37951 -[IDEWorkspace _updateSourceControlStatusIfNeeded] (in IDEFoundation)
7 0x00007fff8c2eb25a __NSFireDelayedPerform (in Foundation)
8 0x00007fff8b82df84 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ (in CoreFoundation)
9 0x00007fff8b82dad6 __CFRunLoopDoTimer (in CoreFoundation)
10 0x00007fff8b80e471 __CFRunLoopRun (in CoreFoundation)
11 0x00007fff8b80dae6 CFRunLoopRunSpecific (in CoreFoundation)
12 0x00007fff8b3633d3 RunCurrentEventLoopInMode (in HIToolbox)
13 0x00007fff8b36a63d ReceiveNextEventCommon (in HIToolbox)
14 0x00007fff8b36a4ca BlockUntilNextEventMatchingListInMode (in HIToolbox)
15 0x00007fff86bde3f1 _DPSNextEvent (in AppKit)
16 0x00007fff86bddcf5 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (in AppKit)
17 0x00007fff86bda62d -[NSApplication run] (in AppKit)
18 0x00007fff86e5980c NSApplicationMain (in AppKit)
19 0x0000000103549eec (in Xcode)
20 0x0000000000000002
I had the same problem.
It was due to a file fo which the name started by ~ in the directory path given by Xcode when it crashed.
Check if you don't have such a file and delete it.
In my case, it solved the issue.
Hope this help,
Rds,
Michael
The solution that worked for me is to delete the Xcode autosave files in ~/Library/Autosave Information. Xcode then started up clean for me.
may not be best answer (?) however I had to (a) reinstall + (b) delete all the various XCode files scattered through my home directory...then it started up ok
Step 1: Copy all the code you want to keep into text files or
something like that
Step 2: Un-install
Step 3: make some coffee
Step 4: Re-install
Details: fsrep is absolute (starts with tilde) ('~--814203924d469071-0000000000') parentPath must be nil but it is not ('<DVTFilePath:0x401bdf9e0:'/Volumes/Macintosh HD/Users/greg/.dvdcss'>')
Object: <DVTFilePath>
in my case the file referenced was dropbox's cache, so the error looked like this
must be nil but it is not ('<DVTFilePath:0x401bdf9e0:'/Volumes/Macintosh HD/Users/greg/.dropbox.cache.2.25.12'>')
after some research on dropbox forums i found these cache directories can be deleted. after removal xcode worked fine.
so i would tell future people who come here to try and remove the offending file prior to reinstalling xcode. (or rename it if you cant delete it)
I deleted ~/Library/Preferences/com.apple.dt.Xcode.plist and Xcode started normally again.
In my case I was xcodebuild'ing Xcode UI Tests from command line using custom .xcconfig file:
HERE_BUILD=./Build-command-line
HERE_INTERMEDIATES=$(HERE_BUILD)/Intermediates
// Paths
// the following paths are enough to redirect everything to $HERE_BUILD
MODULE_CACHE_DIR = $(HERE_BUILD)/DerivedData/ModuleCache
OBJROOT = $(HERE_INTERMEDIATES)
SHARED_PRECOMPS_DIR = $(HERE_INTERMEDIATES)/PrecompiledHeaders
SYMROOT = $(HERE_BUILD)/Products
When I changed HERE_BUILD to have absolute path:
HERE_BUILD=$(SRCROOT)/Build-command-line
the error went away.
I am new one to develop iphone App. so help me to found out error in crash log. In crash log contains only library or framework. Help me to found out crash line .
Check the crash log and find the memory address where it is crashed .
(see MyApp 0x35626f5a 0x1000 + 22516)
Crash log:
0 WebCore 0x35626e8a 0x3023d000 + 23455
1 Foundation 0x3565ebf8 0x3023d000 + 56767
... ... ...
17 MyApp 0x35626f5a 0x1000 + 22516
Steps to analyze crash report:
Copy the .app file and the .dSYM file that was created at the time of release to a folder (say CrashTest).
Open the Crash report.
Open 'Terminal' application and go to the folder (CrashTest) created above (using CD command).
Use this command :atos -arch armv7 -o 'app_name.app'/'app_name' 'crashed_memory_location'.
(crashed_memory_location ->The memory location should be the one at which the app crashed as per the report).
Eg : atos -arch armv7 -o MyApp.app/MyApp 0x35626f5a
This would show you the exact line, method name which resulted in crash.
o/p format : [classname functionName:]; and line number
Eg : +[MyController formatMyAddress:] (in MyApp) (MyController.m:401)
Did u view a debug build or release build?
Release builds do not contain all the information about the crash.