Is possible to get line number of crash exactly when error is in a swift closure ?
I can't get line number exactly when I re-symbolicate device log or using crash report on firebase, I can just know it happens on which closure,
what I miss ?
I'm sorry it is not possible
Your code doesn't exist in the compiled binary because the compiler changes your code code to optimise it in Release.
The solution is to use crash tools (See Crashlytics) or throw out NSLog()
Related
I made a breakpoint in Xcode with the jump commend to force passing some condition, but when it execute to line 168 it crash with message
"Thread 1: EXC_BAD_ACCESS (code=1, address=0x1)"
why did that happen?
the console logged:
warning: MoreMultitypeCollectionViewCell.swift:178 appears multiple times in this function, selecting the first location:
MoreMultitypeCollectionViewCell.(updateButtonStateCkeck in _9A12557DCAB30EEB52DC7C2EA09487CD)() -> () + 1580 at MoreMultitypeCollectionViewCell.swift:178
MoreMultitypeCollectionViewCell.(updateButtonStateCkeck in _9A12557DCAB30EEB52DC7C2EA09487CD)() -> () + 1600 at MoreMultitypeCollectionViewCell.swift:178
my questions are:
How should I type in lldb to select location?
Is there a better way to force passing into If Statement without change code and rebuild project?
sometimes when I type 'po' in lldb or click print description in variable view, it will show fail message, how is that?
1) In lldb, the equivalent command is thread jump and you can specify an address as well as a line number there.
2) thread jump or the Xcode equivalent is an inherently dangerous operation. If you jump over the initialization of some variable, you will be dealing with bad data now and will likely crash. That sort of thing you can sometimes spot by eye - though Swift is lazy about initialization so the actual initialization of a variable may not happen where you think it does in the source. There are more subtle problems as well. For instance, if you jump over some code that as a byproduct of its operation retains or releases an object, the object will end up under or over retained. The former will cause crashes, the latter memory leaks. These retains & releases are generated by the compiler, so you can't see them in your source code, though you could if you look at the disassembly of the code you are jumping over.
Without looking at the code in question, I can't tell why this particular jump caused a crash.
But you can't 100% safely skip some of the code the compiler choose to emit. Looking at the disassembly you might be able to spot either (a) a better place to stop before the jump - i.e. stop past some retain or release that is causing a problem or jump to an address in the middle of a line so you still call a retain that's needed. You'll have to figure this out by hand.
3) There's not enough info to answer this question.
BTW, your image links don't seem to resolve.
While decrypting I get the error : The operation couldnot be performed RNCryptorError 1
I dont understand what I am doing wrong. Here is my block of code
For anyone who might search here: this is a duplicate of RNCryptor#174, and you may want to read there as well.
Please just post code into the question rather than a screenshot. I can't compile a screenshot, and they're very hard to read.
Error 1 is an HMAC error. Either your data is corrupted or your password is incorrect.
Note that NSException never makes sense in Swift. Switch can't catch them. They only make sense in ObjC if you're going to crash the program shortly after. They're not memory-safe in ObjC. You meant to use Swift's throw and ErrorType, which are unrelated to raise or NSException.
My Swift application running in iOS simulator is being stopped in debugger with runtime error EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, sub code=0x0).
According to the WWDC 2014 Session 409 this is typically due to assertion failure.
In the current development Beta version of Xcode 6, the debugger’s stack trace and the above error does not provide enough information to see what the issue is. How do I find out where the problem is?
It appears that the most common source of this error (at the time of this writing: Xcode 6 Beta 1) is that some implicitly unwrapped optional property or variable is nil.
For convenience, most Objective-C API are bridged to Swift with implicitly unwrapped optionals. They are denoted by exclamation mark behind the type declaration: AnyObject[]!
If the debugger stops in your code, double-check that line and look for implicitly unwrapped optionals that could be nil there.
Sometimes the debugger stops with that runtime error deep in Swift system library. This happens for example when you pass a closure to collection methods like filter, map, reduce et al. The runtime error then occurs at the call site of those library functions, but the definition might be in different parts of your code, where you defined the function/closure. Look there for implicitly unwrapped optionals that might be nil at runtime.
To guard agains these kinds of error be aware that even though Swift compiler will not force you to handle the potential nil values returned from Cocoa, you should use optional binding, optional chaining
or optional downcasting wherever the return value from Objective-C land might be nil.
Let’s hope that future versions of Swift compiler will start emitting more helpful diagnostic messages and errors for this common type of problem!
I have found (after many hours) that this error can appear on the wrong line.
For example
As you can see the app is crashing where I am checking for nil, but then 'continuing' through because it prints the statements. It then goes 'backwards' and crashes.
I've come to the conclusion that there is a source-mapping bug in XCode (7) where a nil variable is un-wrapped. In this case, I had a variable (much farther down in my code) that was nil and being unwrapped.
The problem of course is that the compiler didn't flag the actual variable that was nil, it flagged something else entirely.
So if you run into this nasty bug, go through all possible variables that can be nil and check them for unwrapping. You are likely unwrapping a nil, its just not the one the compiler says.
As mentioned in the comment there is compiler optimization. Here is a link to fix the issue (and find the route cause of the crash)
xcode 6.1 how to disable optimization (Swift)
I had the same issue as Palimondo. Fortunately, it was simply a matter of making sure that I had initialized the item ahead of time. In my code, I was calling a function to place images in UIImageViews and passing in an element from an array. I had not yet loaded my array with the UIImageViews, and therefore when the code would run it would say that I was passing in a nonexistent element of the array. Once I made sure to load up my array at the start of the program the error went away.
When am using build and analyse method the following error occurs:- /Users/ghost/demo/libs/cocos2d/CCSprite.m:476:2 Assigned value is garbage or undefined
in:- -(void)updateTransform method am getting above error
here is my screenshot for this error:-
Is it my fault that the program is leaking memory or in cocos2d libraries leaking memory.
recently i asked question regarding this same issue refer the link :-
memory leakage in system libraries
how to rectify this issue:-
Assigned value is garbage or undefined
None of that indicates anything about leaking memory. The analyzer checks for much more than just memory abuse.
The analyzer has identified a code path that, if followed, will lead to an undefined/uninitialized value being used. May happen, may not, but it is worthy of a bug against cocos2d!
This looks like a problem in the Cocos code. The matrix is initialized in two conditionals, therefore it might not be initialized before it’s used. The conditionals might be written so that the matrix is always initialized, the analyzer does not know. I’d simply initialize the matrix with identity transform, that certainly does not hurt. And yes, bbum is right, this is worthy of a bug report – no library should throw analyzer results unless there’s no other way.
I only have 1 line of code, and this is:
pcrecpp::RE re("abc");
inside a function OnBnClickedButtonGo(). And this function fails in Release mode, but it works OK in debug mode.
(I am using Visual Studio 8 on Windows XP.)
The error message is:
A buffer overrun has occurred in testregex.exe which has corrupted the program's
internal state. Press Break to debug the program or Continue to terminate
the program.
For more details please see Help topic 'How to debug Buffer Overrun Issues'.
I suspect it is its destructor, which is invisible and implied... but I don't know really.
PS: I am statically linking to the PCRE lib version 7.8.
PS2: Not very relevant, but may help some people who have trouble linking to the PCRE library (it took me hours to sort it out): include the line #define PCRE_STATIC.
I had the same error message in my case. In debug is everything fine, but in release I get the error message. I have a native C/C++ library like native.dll. I have created a mixed unmanaged/managed C++ library, which is a wrapper for that library to .net. Somewhere in this mixed.dll I have an unmanaged function signature declaration, like:
typedef void ( *FunctionOnStartSend)();
for this the I get the message, but if I add a "magic word" there then there is no error message:
typedef void (__stdcall *FunctionOnStartSend)();
If it's happening only in release mode, it's possible that something is getting "optimized" out. Try doing something more than just the one liner, like a Match() and maybe even printing out the matches.
Here is my fresh history:
About a month ago I've got a strange link failure of the VS2008 and that day I dug that setting _SECURE_SCL=0 may help (see link text). And it helped. That day it helped me and I just propagated this setting to all the libs we build at team -- that's because MS says that two libs built with different _SECURE_SCL are incompartible.
Time passed and three days ago I've got a bug when VS2008 says that error message that we see in the first post. And there are no help from the debugger because it overruns only in Release build. I've spend almost 2 days pump'n'jump'n the code of the libs and the overrun was flawed from line to line. Finally I started checking build settings line by line and figured the diff in this setting!
Why, oh why Microsoft guys can't embed some small check in dynamic loader code to test that the library currently running and the one going to be dynamically loaded are incompartible?! Some pice of code that save people's time. Blah!