Error: Unable to capture view hierarchy. Details: Log Title: Data
source expression execution failure. Log Details: error evaluating
expression “(id)[[(Class)objc_getClass("DBGTargetHub") sharedHub]
performRequestWithRequestInBase64:#"YnBsaXN0MDDUAQIDBAUGRkdYJHZlcnNpb25YJG9iamVjdHNZJGFyY2hpdmVyVCR0b3ASAAGGoK8QFwcIGxwdHh8gISIuLzAxMjM0Nz1BQkNEVSRudWxs0wkKCwwTGldOUy5rZXlzWk5TLm9iamVjdHNWJGNsYXNzpg0ODxAREoACgAOABIAFgAaAB6YUFRYXGBmACIAJgBOAD4AUgBWAFl8QG0RCR0hpZXJhcmNoeVJlcXVlc3RQcmlvcml0eV8QHERCR0hpZXJhcmNoeVJlcXVlc3RQcmVkaWNhdGVfEBdEQkdIaWVyYXJjaHlSZXF1ZXN0TmFtZV8QHkRCR0hpZXJhcmNoeVJlcXVlc3RTcGluUnVubG9vcF8QHURCR0hpZXJhcmNoeVJlcXVlc3RJZGVudGlmaWVyXxAXREJHSGllcmFyY2h5UmVxdWVzdFR5cGUQANMJCgsjKC2kJCUmJ4AKgAuADIANpCkXKyuADoAPgBCAEIASXxATc3RyaWN0ZXN0VmlzaWJpbGl0eV8QEWluY2x1ZGVMYXp5VmFsdWVzXxATZW51bVByb3ZpZGVyQ2xhc3Nlc18QFm9wdGlvbnNQcm92aWRlckNsYXNzZXMQAwjSCgs1NqCAEdI4OTo7WiRjbGFzc25hbWVYJGNsYXNzZXNXTlNBcnJheaI6PFhOU09iamVjdNI4OT4/XxATTlNNdXRhYmxlRGljdGlvbmFyeaM+QDxcTlNEaWN0aW9uYXJ5XxAPSW5pdGlhbCByZXF1ZXN0XxAkQ0U4OUY0RkItRkRGRS00RUNGLUIwNzctMUQyNDk1REMzMjRCEAHSODlARaJAPF8QD05TS2V5ZWRBcmNoaXZlctFISVRyb290gAEACAARABoAIwAtADIANwBRAFcAXgBmAHEAeAB/AIEAgwCFAIcAiQCLAJIAlACWAJgAmgCcAJ4AoAC+AN0A9wEYATgBUgFUAVsBYAFiAWQBZgFoAW0BbwFxAXMBdQF3AY0BoQG3AdAB0gHTAdgB2QHbAeAB6wH0AfwB/wIIAg0CIwInAjQCRgJtAm8CdAJ3AokCjAKRAAAAAAAAAgEAAAAAAAAASgAAAAAAAAAAAAAAAAAAApM="]”:
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1,
address=0x0).
The process has been returned to the state before expression evaluation.
You likely have a bug somewhere in the implementation of a framework override. At least it was the case for me: a forced unwrapping of an optional nil value. Since the debugger executes the above statement, I could not get a stack trace of where the problem had happened.
My idea was to emulate the debugger's statement in my code directly. Since you won't have access to DBGTargetHub's interface, I went with using the Objective-C runtime functions.
NSString *data = #"YnBsaXN0MDDUAQIDBA[...]";
Class DbgTargetHub = objc_getClass("DBGTargetHub");
SEL sel = sel_getUid("sharedHub");
id sharedHub = ((id(*)(id, SEL))objc_msgSend)(DbgTargetHub, sel);
sel = sel_getUid("performRequestWithRequestInBase64:");
id result = ((id(*)(id, SEL, NSString*))objc_msgSend)(sharedHub, sel, data);
I was able to generate a stack trace from this which I could use to locate my problem.
Would be interested to know if this helped anybody.
For me this was a really weird SwiftUI bug caused by having a Section(header: that was a Divider view. Changed it to a Rectangle view and it all started working again...
I was only able to track this down by commenting out views until things worked again. Hope this helps some poor soul
Related
Debugging with PyCharm (happens on multiple versions) I'm unable to correctly view some lists and dictionaries (other are presented correctly).
In the view window the object's name is presented with the message:
{list} Unable to get repr for <type 'list>
or
{dict} Unable to get repr for <type 'dict'>
An update:
In one of my attempts, I received the following message from the debugger (presented instead of the value of one of the list variable):
Unable to display children:Error resolving variables Traceback (most
recent call last): File "/Applications/PyCharm
CE.app/Contents/helpers/pydev/_pydevd_bundle/pydevd_comm.py", line
1004, in do_it
_typeName, valDict = pydevd_vars.resolve_compound_variable(self.thread_id, self.frame_id,
self.scope, self.attributes) TypeError: 'NoneType' object is not
iterable
I'll appreciate any idea as for what may cause this behavior?
Thanks!
It turned out the problem is due to usage of rpyc.py: The process I was debugging was called through rpyc and while I was debugging it, the calling process received a timeout on the rpyc connection.
I think that this caused variables, passed through rpc to lose integrity so the debugger couldn't present them correctly.
The solution was to downgrade rpyc.py to version 3.3.0 (I was on 3.4.2).
My colleague, Nurit Izraelov, correctly suggested the rpyc.py version may be the blame.
Thanks all!
It happened to me sometimes and what caused the behaviour was that some MyClass triggered an exception on its str method.
In such a case, PyCharm debugger only showed
some_object = {MyClass} Unable to get repr for <class 'my_app.models.MyClass'>
So what I did to confirm the origin was to watch repr(some_object) in the Watches section of the debugger. And there it gave me an explicit error message:
{TypeError}%d format: a number is required, not NoneType
Which helped me trace back to the origin.
I appreciate this is not a generic answer, but just a complement to Fabio's.
Probably some custom class of yours has a bad __repr__ or __str__ in it and the debugger is unable to print it.
You can probably use a shell at that point to know which elements are actually inside such a dict or list (and see which object has the faulty __repr__ or __str__).
Extending the scope of the problem rather than adding an answer - all the other suggestions are what I do normally to get this working.
Could it be a race condition?
For me it appears to be something weird. In the Variables pane I can see correct representation for theObject, repr(theObject) and even [theObject] but if I set a variable in my code thus a = theObject or b = [theObject] then I get the "Unable to get repr for <class 'list'>" message.
theObject in this case is an instance of a subclassed D lang struct wrapped with autowrap.
I have found a few questions regarding this issue, yet none of them were helping with my problem. I am trying to save an object to core data using this code (which worked perfectly fine in Xcode 6 and Simulator...):
let fetchRequest = NSFetchRequest(entityName: "Patient")
let fetchedResults : [NSManagedObject]!
do {
fetchedResults = try managedContext.executeFetchRequest(fetchRequest) as! [NSManagedObject]
patienten = fetchedResults
} catch {
print("error")
}
I added the do-try-catch once I started working on this project in the Xcode 7 beta and a physical device.
Now, when I hit the Save button, this piece of code is called, the app freezes and I get the following:
warning: could not load any Objective-C class information from the dyld shared cache. This will significantly reduce the quality of type information available.
Does anybody know where I went wrong?
For anyone coming across this in the future, I just ran into this problem myself and it turned out that I was actually getting a stack overflow from a recursive function.
Apparently calling setValue:forKey: on an NSObject calls the respective set[Key] function, where [Key] is the (capitalized) name you gave to the forKey section.
So, if like me, you have code that looks like the following, it will cause an infinite loop and crash.
func setName(name: String) {
self.setValue(name, forKey: "name")
}
Choose Product > Clean
I had similar issue. I deleted the app from the device. Then "Product->Clean" in the XCode menu. When I ran the app again, the issue got resolved.
Swift 3:
Actually this problem happened often when you have any property in input declared as type NSError and the compiler expect an Error output, so change the input type to Error usually solve this issue.
What helped me in similar problem (xCode 7, Swift 2):
reading this question
Or more quickly without explaining the reason of solution: just comment #objc(className) in your NSManagedObjectSubclass , that was generated from your CoreData Entity (#objc(Patient) - in your case ).
This solution (if issue still appears) does not applicable to xCode 7.1/Swift 2.1, as the way of generating NSManagedObjectSubclasses was changed.
Don't forget about cleaning your project (Product > Clean) and deleting the app from your device/simulator to replace CoreData storage on it.
let fetchRequest = NSFetchRequest(entityName: "Patient")
do {
let fetchedResults = try managedObjectContext!.executeFetchRequest(fetchRequest)
print("\(fetchedResults)")
} catch {
print("error")
}
The above code worked for me.
Maybe the issue maybe with how your core data is managed.
Check if your managedObjectContext is actually getting created.
Check the modelling of your core data
Does anyone have the faintest idea what this error means please and how to resolve it? All my research is drawing a blank, I can see how to set it on MSDN but it doesn't explain it in a way that explains to me what the issue is. If I remove some of my LINQ queries to set viewbag items then it seems to resolve it but the moment I set new ones and pass them into my view to generate a mail for MVCMailer it comes back. Not sure if its a viewbag issue or simply that I am calling too many linq queries to generate them to pass to the view.
I am very stuck (again)..........
Cheers,
Steve.
DbLimitExpression requires a collection argument.
Parameter name: argument
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.ArgumentException: DbLimitExpression requires a collection argument.
Parameter name: argument
An example of the code is:
var VBSalutation = from A in context.Salutations
where A.SalutationId == policytransaction.SalutationId
select A.SalutationName;
ViewBag.Salutation = VBSalutation.FirstOrDefault();
This is repeated for various parameters and then passed to the view.
Well, I faced a similar problem and solved it. Problem was in WHERE clause: data type of left side equal operator (=) sign was not matching with data type of right side. So in your scenario:
where A.SalutationId == policytransaction.SalutationId
SalutationID of A might be an INT and SalutationId of policytransaction might be a string (This is how it was in my case).
I solved it by assigning policytransaction.SalutationId to an Int variable and using it:
int myIntVariable = Convert.ToInt16(policytransaction.SalutationId);
...//some code here
where A.SalutationId == myIntVariable;
Please also note that you cannot directly cast your variables directly in Linq else you'll get an error "LINQ to Entities does not recognize the method". You'll have to use a temp variable and then apply the where clause.
Try ViewBag.Salutation = VBSalutation.SingleOrDefault();
In the following code, I am able to check with the debugger the values of self and childView.
[self.navigationController pushViewController:childView animated:YES];
However, I am not able to see the value of self.navigationController. How can I check if it is nil?
Just add the line:
UINavigationController* navController = self.navigationController;
And then set a breakpoint, or whatever else you want to do.
The reason is because navigationController is a property, so you can't just examine it; you would have to send the property's owner a getter message. In the debugger, that's pretty expensive, especially if it crashes or otherwise fails, plus it could always have side effects (e.g., faulting in a Core Data object, lazy-loading something, or changing some state in another ivar), so the debugger will not do this casually.
You must explicitly request the message using the Debugger Console:
po [self navigationController]
(I don't know whether it will let you use property-access syntax there. There's no difference between them, which is the root of the problem: A property access is an Objective-C message, which, as I described above, is why the debugger won't do one unless you specifically tell it to.)
You could always just do something like (self.navigationController == nil).
If I get an error code result from a Cocoa function, is there any easy way to figure out what it means (other than by grepping through all the .h files in the framework bundles)?
You should look at the <Framework/FrameworkErrors.h> header for whatever framework the method you're using that's returning an error comes from.
For example, an NSError in the Cocoa domain that you get from a method in the Foundation framework will have its code property described in the <Foundation/FoundationErrors.h> header. Similarly with AppKit and <AppKit/AppKitErrors.h> and Core Data and <CoreData/CoreDataErrors.h>.
Also, if you print the description of the NSError in the debugger, it should include not only the error domain and code, but also the name of the actual error code constant so you can look it up in the API reference.
The sections on 'Error Domains' and 'Error Codes' in Apple's Error Handling Programming Guide address this reasonably well. You need to do the following:
Log the error, taking note of both the error domain (a human-readable / Googleable string that tells you where to look for the error code definitions) and the error code itself (an integer)
Sniff around on Google (or read from the list below) and figure out the name of the header file(s) where the error codes for that error domain are defined
Search those header file(s) for the error code you got. You should find both a constant name for the error code (like ENOMEM), and hopefully also an explanatory comment (like /* Cannot allocate memory */) explaining what the error means. If there's no comment, and the constant name isn't self-explanatory, just Google the constant name and you'll probably find a proper description.
Some header files of major error domains:
NSCocoaErrorDomain
Error code declarations are spread across three header files:
<Foundation/FoundationErrors.h> (Generic Foundation error codes)
<AppKit/AppKitErrors.h> (Generic AppKit error codes)
<CoreData/CoreDataErrors.h> (Core Data error codes)
NSURLErrorDomain
Check NSURLError.h
NSXMLParserErrorDomain
CheckNSXMLParser.h
NSMachErrorDomain
Check /usr/include/mach/kern_return.h
NSPOSIXErrorDomain
Check /usr/include/sys/errno.h
NSOSStatusErrorDomain
Check
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/MacErrors.h
Also, Cocoa's NSError is meant to be displayable to the end user. If you just log it, it should be readable.
If you're talking about Carbon's OSStatus and such, MacErrors.h.
For NSError errors add a line of code:
NSError *error;
// ... Some code that returns an error
// Get the error as a string
NSString *s = [error localizedDescription];
// Observe the code for yourself or display to the user.