Better debugging "po" info?

Discussion in 'Mac Programming' started by Maury, Jun 14, 2012.

  1. macrumors 6502

    Mar 25, 2008
    I'm trying to debug a problem with one of my NSDictionary's containing junk. I'm stepping though trying to figure out where it happens - so far no clue.

    I think I know the general area, but when I try to see what data I've already got, everything's just references...

    (lldb) po dict
    (NSMutableDictionary *) $37 = 0x00000001001afee0 {
    "table_cat" = <6d797371 6c>;

    Is there any way to know what that thing inside the <>'s is? It's supposed to be an NSData, shouldn't the contents just print out? Shouldn't it at *least* say it's an NSData?
  2. macrumors 604

    Aug 9, 2009
    It is "printing out". It's showing the first 5 bytes in hex:
    <6d797371 6c>
    You should try an NSLog with a %@ format on the NSData before dropping into the debugger. So you know what NSData's -description method is likely to produce.
  3. thread starter macrumors 6502

    Mar 25, 2008
    Oh, well this is very good news then. But shouldn't this be decoded by default? I seem to recall it did that under gdb, that is, you got a string instead of hex.
  4. macrumors 604

    Aug 9, 2009
    I don't see why. The debugger has no way of knowing what the text-encoding is. It could guess, but how? A plausible explanation for 'po' is that it calls the -description method, the same way %@ does in a format string.

    I'm not in a position to check this, but it seems unlikely to me. There's no way of knowing what the bytes in the NSData represent. It's just bytes. They could represent anything.

    If gdb is guessing it's a string, and showing it that way, it's some special feature of gdb, because it would have to look at the bytes, guess an encoding, and then show the text. There may be other ways of printing arbitrary bytes as text in gdb, but 'po' doesn't seem like it (assuming it's implemented as %@ or -description). The NSData object certainly doesn't know if the bytes it holds are a string. It could be anything.
  5. thread starter macrumors 6502

    Mar 25, 2008
    Oh geez, now I get it. Yes, you are right, this is indeed what I should be getting back. For some reason I had convinced myself the data inside was NSString, even though it was clear even as I wrote that message that it wasn't. Duh!

Share This Page