I am not able to get dictionary/array value in console while debugging.
It always show message while po dictionary/array like
error: warning: Stopped in a context claiming to capture an Objective-C object pointer, but 'self' isn't available; pretending we
are in a generic context
Check the screenshot here
You can check the values of properties and variables using po [self variablename] in console window. This way you can easily access the variables.
Also you can check with other projects weather the problem is with xcode or in your project configurations.
You can also expand the collapsed value in debug area. if it's expanding then you can access values by simply using po variablename otherwise you need to use po [self variablename].
I'd the same issue and found out this solution. Changing this clang module debugging DEBUG to NO and RELEASE to YES will solve your issue.
Checkout this link below.
Accessing Self in LLDB
Please refer the following screen shot where i have printed the value of an array
This is a debugger bug (Yeah, imagine that!)
Simply restart XCode, and it shouldn't be a problem for you anymore :)
EDIT:
Psyche! I was thinking of something else.
You're creating a retain cycle, and as of now, the debugger classifies this specific retain cycle this way (As I said, a bug).
To fix this, create a weak copy of self:
__weak __typeof(self)weakSelf = self;
Then for the self that's giving you trouble:
Change self.object to weakSelf.object
Source: "self" not available in debugger on iOS 5.1
Related
I'm looking for a way to cause the XCode debugger to break programmatically from Swift code if my iOS program is running in the debugger. This would be similar to the way System.Diagnostics.Debugger.Break() works in the Visual Studio environment. Is this possible? The point would be for any developer that hits a particular section of code to break, but not to have a fatal error that causes code execution to stop permanently.
Edit: This is a little different than the user asking to "enable" a breakpoint (though the answer provided in that question is really what I was looking for). I'm also still looking for something that can be done in Swift without interop, bridging headers, and such.
For Swift, raise(SIGINT) works for me.
I have this function:
func fail(desc: String) {
#if DEBUG
print("assertFail:\(desc)")
raise(SIGINT)
#endif
}
For DEBUG macro setup see here: In absence of preprocessor macros, is there a way to define practical scheme specific flags at project level in Xcode project
Putting asm("svc 0") in your code will stop your running application if debugging through xcode. See: https://stackoverflow.com/a/34078247/215400
I'm not 100% positive there isn't a built in one - but you can create what you want yourself using Symbolic Breakpoints in the XCode UI.
1) Create a new class to represent your Debugger Break.
#interface MYDebuggerBreak : NSObject
+(void)fireUpDebugger;
#end
#implementation MyDebuggerBreak
+(void)fireUpDebugger {
// Do Nothing
}
#end
2) Add a Symbolic Breakpoint to a method on that Class
[MYDebuggerBreak fireUpDebugger]
This is a bit roundabout, you could also put a breakpoint directly into the line "fireUpDebugger" since you control the code. Symbolic Breakpoints are more useful if you want to stop on a method call for something you don't control.
I am running into a bizarre situation where a unit test's execution is behaving differently than the normal execution of a piece of code.
In particular, I am using a library called JSONModel, and when I am attempting to deserialize an object from a JSON string, one line in particular is causing problems when I step through the executing test case:
if ( [[property.type class] isSubclassOfClass:[JSONModel class]] ) ...
If I put a breakpoint before (or after) this line and execute:
expr [[property.type class] isSubclassOfClass:[JSONModel class]]
...in the debugger, it prints \x01 as the value (i.e. true), however when I actually step the instruction pointer, it behaves as though it is false, going instead into the else block. Again, typing the expression into the debugger again shows it as true even still.
I'm curious if anyone has seen similar behavior before and has any suggestions as to what could possibly be going wrong. I'm quite certain I'm not including different definitions for anything, unless Xcode has different internal cocoa class implementations for testing.
Update: Here's some even weirder evidence: I've added some NSLog statements to get an idea for how the execution is seeing things. If I log property.type.superclass I get JSONModel back (as expected); however if I log property.type.superclass == [JSONModel class] I get false!
To me this is indicating that the JSONModel the unit test execution is seeing is somehow a different JSONModel class that I'm seeing at runtime (and what it should be seeing). However, how that is happening I can't figure out.
Could this be caused by a forward class declaration or something like that?
Well I seem to have discovered a "solution" by experimentation. It turns out if I replace [JSONModel class] with NSClassFromString(#"JSONModel") it works swimmingly!
Now why this is I cannot say, and will give the answer to whoever can explain it!
I had the exact same problem, here's what was happening.
As expected with this kind of behaviour, it was an issue with the class being duplicated. As with you, [instance class] and NSClassFromString would return different values. However, the class were identical in all points : same ivar, same methods (checked with the obj runtime). No warning was displayed at compile, link and/or runtime
In my case, the tests were about a static library used in my main application (Bar.app).
Basically, I had 3 targets:
libFoo
libFooTests
Bar.app
The tests were performing on the device, and not on simulator. As such, they needed to be logic tests, and not unit tests, and had to be loaded into an application. The bundle loader was my main app, Bar.app.
Only additional linker flag was -ObjC
Now, Bar.app was linking libFoo.
It turns out, libFooTests was also linking libFoo.
When injecting libFooTests in the test host (Bar.app), symbols were duplicated, but no warning were presented to me. This is how this particular class got duplicated.
Simply removing libFoo from the list of libraries to link against in libFooTests did the trick.
I ran into a situation that Xcode shows different result of one object from the result of po command in LLDB. firstly, all values in the object is nil and the object is displayed with *const type modifier, which it shouldn't be. and when I use po to get datasource variable it shows correct data. However, it shows datasource is nil in Xcode variable list.( please see following screenshot) Can anyone explain why?
This seems like the sort of thing you should file a bug with Apple about. Probably take more back and forth to figure out what is going on than can be easily done in this context.
What do I need to do to have variables display their values in XCode?
I don't have it in Auto pane, and it also does not show when I hover over it. Why is that?
I can go Add Expression and sometimes it will display it correctly, and I can also do NSLog and log it, but this seems really ridiculous in the year of 2013.
I am using XCode 4.6. Am I doing something wrong, or this basic functionality just does not exist?
You can use the local variables section in the content pane to view variable values while debugging:
You can use shift + command + Y to toggle the above pane.
For more information regarding debugging in xCode, check out the following link.
In the console use the command 'po' (stands for print object)
e.g. po [self myVariable]
This will give you more information than this semi-useless variable tree in the content pane.
hints:
1) Make sure your build configuration is set to Debug, or you can't debug local variables.
2) Sometimes you need to debug structs and primitives, in this case use 'p' instead of 'po'
3) you can use dot notation (po self.myVariable), but for some data types this doesn't seem to work. I believe it depends on your xcode version
I'm encountering this error when I'm running my DirectX10 program in debug mode:
D3D10: WARNING: ID3D10Buffer::SetPrivateData: Existing private data of same name with different size found! [ STATE_SETTING WARNING #55: SETPRIVATEDATA_CHANGINGPARAMS ]
I'm trying to make the project highly OOP as a learning exercise, so there's a chance that this may be occurring, but is there a way to get some more details?
It appears this warning is raised by D3DX10CreateSprite, which is internally called by font->DrawText
You can ignore this warning, seems to be a bug in the Ms code :)
Direct3D11 doesn't have built-in text rendering anymore, so you won't encounter it in the future.
Since this is a D3D11 warning, you could always turn it off using ID3D11InfoQueue:
D3D11_MESSAGE_ID hide [] = {
D3D11_MESSAGE_ID_SETPRIVATEDATA_CHANGINGPARAMS,
// Add more message IDs here as needed
};
D3D11_INFO_QUEUE_FILTER filter;
memset(&filter, 0, sizeof(filter));
filter.DenyList.NumIDs = _countof(hide);
filter.DenyList.pIDList = hide;
d3dInfoQueue->AddStorageFilterEntries(&filter);
See this page for more. I found your question while googling for the answer and had to search a bit more to find the above snippet, hopefully this will help someone :)
What other data are you looking for or interested in?
The warning is pretty clear about what is going on, but if you want to hunt down a bit more data, there may be a few things to try.
Try calling ID3D10Buffer::GetPrivateData with the same name or do some other check to see if there is data with that name already, and if so, what the contents are. Print your results to a file, output window, or console. This may be combined with breakpoints to see where the duplicate is occurring (break when there's already data).
You may (not positive) be able to set the D3D runtimes to debug mode and to break on warnings (not sure if it can do warnings or just errors). Debug your app in VS or your preferred debugger, and when the warning is shown, it will break and you can look at the parameters.
Go through your code and track down all calls to ID3D10Buffer::SetPrivateData and look to see if there are any obvious duplicates. If there are, work up the program flow and see why and what you can do about them (this may work best after you use one of the former methods to know where to start).
How are your data names set up, and what is the buffer used for? Examining one or both may lead you to a conflict somewhere.
You may also try unicorns, they've been known to help with this kind of problem.