How to display full file name in lldb - c++

I'm pretty familiar with the basic commands of gdb. Unfortunately Apple switched to lldb which has completely different set of commands and now I need to learn a new tool.
Trying to debug a program I step into the function, but it does not display a full file name where the function is. So no path to the file.
Is there a command to retrieve it?
Thank you.

You can do image lookup -n <func-name> to get the file name
(lldb) image lookup -n main
1 match found in /Users/ml9951/manticore/trunk/src/regression-tests/goals/seq-logging/a.out:
Address: a.out[0x0000000100027670] (a.out.__TEXT.__text + 156144)
Summary: a.out`main at main.c:90 <<--------
(lldb)
It doesn't have the entire path, but hopefully this helps some.

(lldb) image lookup -v -a $pc
Address: libjvm.so[0x0000000001a3c2c4] (libjvm.so.PT_LOAD[1]..text + 24588836)
Summary: libjvm.so`SystemDictionaryShared::add_lambda_proxy_class(InstanceKlass*, InstanceKlass*, Symbol*, Symbol*, Symbol*, Method*, Symbol*, JavaThread*) + 356 at systemDictionaryShared.cpp:1642:3
Module: file = "/home/foo/bar/jdk17u-git/build/linux-x86_64-server-fastdebug/images/jdk/lib/server/libjvm.so", arch = "x86_64"
CompileUnit: id = {0x0000038b}, file = "/home/foo/bar/jdk17u-git/src/hotspot/share/classfile/systemDictionaryShared.cpp", language = "c++14"
Function: id = {0x0d35d4df}, name = "SystemDictionaryShared::add_lambda_proxy_class(InstanceKlass*, InstanceKlass*, Symbol*, Symbol*, Symbol*, Method*, Symbol*, JavaThread*)", mangled = "_ZN22SystemDictionaryShared22add_lambda_proxy_classEP13InstanceKlassS1_P6SymbolS3_S3_P6MethodS3_P10JavaThread", range = [0x00007ffff74ff160-0x00007ffff74ff79d)
FuncType: id = {0x0d35d4df}, byte-size = 0, decl = systemDictionaryShared.cpp:1631:6, compiler_type = "void (class InstanceKlass *, class InstanceKlass *, class Symbol *, class Symbol *, class Symbol *, class Method *, class Symbol *, class JavaThread *)"
Blocks: id = {0x0d35d4df}, range = [0x7ffff74ff160-0x7ffff74ff79d)
LineEntry: [0x00007ffff74ff2c4-0x00007ffff74ff2c9): /home/foo/bar/jdk17u-git/src/hotspot/share/classfile/systemDictionaryShared.cpp:1642:3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Symbol: id = {0x000055ba}, range = [0x00007ffff74ff160-0x00007ffff74ff79d), name="SystemDictionaryShared::add_lambda_proxy_class(InstanceKlass*, InstanceKlass*, Symbol*, Symbol*, Symbol*, Method*, Symbol*, JavaThread*)", mangled="_ZN22SystemDictionaryShared22add_lambda_proxy_classEP13InstanceKlassS1_P6SymbolS3_S3_P6MethodS3_P10JavaThread"
Variable: id = {0x0d35d4fd}, name = "caller_ik", type = "InstanceKlass *", location = DW_OP_reg12 R12, decl = systemDictionaryShared.cpp:1631:68
Variable: id = {0x0d35d512}, name = "lambda_ik", type = "InstanceKlass *", location = DW_OP_reg3 RBX, decl = systemDictionaryShared.cpp:1632:68
...

Related

MySQL C++ Connector crashes at ResultSet->getBlob()

I'm trying to find out how to store binary data from a C++ program in a MariaDB database and restore from there.
For a first try I created a db table DOCUMENT:
idDOCUMENT INT(10) PK
TYPE VARCHAR(45)
DESCRIPTION VARCHAR(45)
CREATIONDATE DATETIME
DATA LONGBLOB
The binary data shall go to the DATA field.
Now I try to upload a PDF document to that table using this C++ code:
ifstream inFile("/home/thomas/Projekte/test-and-trials/test-and-trials/Contract.pdf", ios::binary);
const string INSERTtoDocument = "INSERT INTO DOCUMENT(TYPE,DESCRIPTION,DATA) VALUES(?, ?, ?)";
shared_ptr<sql::PreparedStatement> insertDocument(con->prepareStatement(INSERTtoDocument));
insertDocument->setString(1, "PDF");
insertDocument->setString(2, "Contract");
insertDocument->setBlob(3, &inFile);
int code = insertDocument->executeUpdate();
After executing that I can see in MySQL workbench that a new record has been created.
I can even download the blob from there, view the file in a PDF viewer. diff says that this download is binary same to what I uploaded.
Next I try to download the file using this C++ code:
const string QUERYblob = "SELECT * FROM DOCUMENT WHERE idDOCUMENT=?";
shared_ptr<sql::PreparedStatement> selectDocument(con->prepareStatement(QUERYblob));
selectDocument->setUInt(1, 12);
shared_ptr<sql::ResultSet> res(selectDocument->executeQuery());
res->first();
string docType = res->getString("TYPE");
string docDescr = res->getString("DESCRIPTION");
istream *blobStream = res->getBlob("DATA");
string docType = res->getString("TYPE");
returns "PDF". Correct so far.
string docDescr = res->getString("DESCRIPTION");
gives me "Contract". Also fine.
But
istream *blobStream = res->getBlob("DATA");
crashes with a segment violation. Reliably, each and every time.
Whats going on here?
bt full shows:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6f7ba50 in __memcpy_ssse3 () from /lib64/libc.so.6
(gdb) bt full
#0 0x00007ffff6f7ba50 in __memcpy_ssse3 () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007ffff7b939f7 in ?? () from /usr/lib64/libmysqlcppconn.so.7
No symbol table info available.
#2 0x00007ffff7b97658 in sql::mysql::MySQL_Prepared_ResultSet::getString(unsigned int) const () from /usr/lib64/libmysqlcppconn.so.7
No symbol table info available.
#3 0x00007ffff7b9391c in sql::mysql::MySQL_Prepared_ResultSet::getString(sql::SQLString const&) const () from /usr/lib64/libmysqlcppconn.so.7
No symbol table info available.
#4 0x00007ffff7b97f98 in sql::mysql::MySQL_Prepared_ResultSet::getBlob(sql::SQLString const&) const () from /usr/lib64/libmysqlcppconn.so.7
No symbol table info available.
#5 0x0000000000401987 in main () at ../test-and-trials/main.cpp:49
driver = 0x618290
con = std::shared_ptr<sql::Connection> (use count 1, weak count 0) = {
get() = 0x63a500}
res = std::shared_ptr<sql::ResultSet> (use count 1, weak count 0) = {
get() = 0x636b20}
docDescr = "Contract"
buf = std::shared_ptr<char> (empty) = {
get() = 0x6 <error: Cannot access memory at address 0x6>}
docType = "PDF"
outFile = <incomplete type>
QUERYblob = "SELECT * FROM DOCUMENT WHERE idDOCUMENT=?"
selectDocument = std::shared_ptr<sql::PreparedStatement> (use count 1, weak count 0) = {get() = 0x63bde0}
blobStream = 0x402d90 <__libc_csu_init>
--Type <RET> for more, q to quit, c to continue without paging--
blobSize = 0
__FUNCTION__ = "main"
(gdb)

lldb source paths for an external framework

I've made a small WebRTC player on macOS that is linked against Googles libwebrtc to torubleshoot my WebRTC streaming backend. But I am having issues putting any breakpoints in libwebrtc. For example, if I set a breakpoint in a known file like this breakpoint set --file packet_buffer.cc --line 365, lldb seems to resolve the symbol since the output from lldb is:
Breakpoint 1: where = WebRTC`webrtc::video_coding::PacketBuffer::FindFrames(unsigned short) + 1827 at packet_buffer.cc:365:11, address = 0x0000000101331183
But when the breakpoint is hit, Xcode shows disassembly:
The thing that troubles me is the relative path of the source - I am unsure to where Xcode/lldb resolves that - to the root of the loaded application or the module?
If I do a image lookup with a function from that file, e.g. image lookup -vn webrtc::video_coding::PacketBuffer::Packet::Packet, the output shows that lldb seems to find the symbol:
4 matches found in /Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC:
Address: WebRTC[0x0000000000f1b8d0] (WebRTC.__TEXT.__text + 15835536)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long) at packet_buffer.cc:58
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d30002c9f3}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC2ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx", range = [0x000000010132e8d0-0x000000010132ea72)
FuncType: id = {0x4d30002c9f3}, byte-size = 0, decl = packet_buffer.h:38, compiler_type = "void (const class webrtc::RtpPacketReceived &, const struct webrtc::RTPVideoHeader &, int64_t, int64_t)"
Blocks: id = {0x4d30002c9f3}, range = [0x10132e8d0-0x10132ea72)
LineEntry: [0x000000010132e8d0-0x000000010132e901): ../../modules/video_coding/packet_buffer.cc:58
Symbol: id = {0x00057dfa}, range = [0x000000010132e8d0-0x000000010132ea80), name="webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC2ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx"
Variable: id = {0x4d30002ca11}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-80), decl =
Variable: id = {0x4d30002ca1f}, name = "rtp_packet", type = "const webrtc::RtpPacketReceived &", location = DW_OP_fbreg(-88), decl = packet_buffer.cc:42
Variable: id = {0x4d30002ca2e}, name = "video_header", type = "const webrtc::RTPVideoHeader &", location = DW_OP_fbreg(-96), decl = packet_buffer.cc:43
Variable: id = {0x4d30002ca3d}, name = "ntp_time_ms", type = "int64_t", location = DW_OP_fbreg(-104), decl = packet_buffer.cc:44
Variable: id = {0x4d30002ca4c}, name = "receive_time_ms", type = "int64_t", location = DW_OP_fbreg(-112), decl = packet_buffer.cc:45
Address: WebRTC[0x0000000000f1ba80] (WebRTC.__TEXT.__text + 15835968)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long) at packet_buffer.cc:58
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d30002cbf0}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC1ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx", range = [0x000000010132ea80-0x000000010132eabb)
FuncType: id = {0x4d30002cbf0}, byte-size = 0, decl = packet_buffer.h:38, compiler_type = "void (const class webrtc::RtpPacketReceived &, const struct webrtc::RTPVideoHeader &, int64_t, int64_t)"
Blocks: id = {0x4d30002cbf0}, range = [0x10132ea80-0x10132eabb)
LineEntry: [0x000000010132ea80-0x000000010132eaa0): ../../modules/video_coding/packet_buffer.cc:58
Symbol: id = {0x00057dfe}, range = [0x000000010132ea80-0x000000010132eac0), name="webrtc::video_coding::PacketBuffer::Packet::Packet(webrtc::RtpPacketReceived const&, webrtc::RTPVideoHeader const&, long long, long long)", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC1ERKNS_17RtpPacketReceivedERKNS_14RTPVideoHeaderExx"
Variable: id = {0x4d30002cc0e}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-8), decl =
Variable: id = {0x4d30002cc1b}, name = "rtp_packet", type = "const webrtc::RtpPacketReceived &", location = DW_OP_fbreg(-16), decl = packet_buffer.cc:42
Variable: id = {0x4d30002cc29}, name = "video_header", type = "const webrtc::RTPVideoHeader &", location = DW_OP_fbreg(-24), decl = packet_buffer.cc:43
Variable: id = {0x4d30002cc37}, name = "ntp_time_ms", type = "int64_t", location = DW_OP_fbreg(-32), decl = packet_buffer.cc:44
Variable: id = {0x4d30002cc45}, name = "receive_time_ms", type = "int64_t", location = DW_OP_fbreg(-40), decl = packet_buffer.cc:45
Address: WebRTC[0x0000000000f23740] (WebRTC.__TEXT.__text + 15867904)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet() at packet_buffer.h:37
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d300038648}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC1Ev", range = [0x0000000101336740-0x000000010133675b)
FuncType: id = {0x4d300038648}, byte-size = 0, decl = packet_buffer.h:37, compiler_type = "void (void)"
Blocks: id = {0x4d300038648}, range = [0x101336740-0x10133675b)
LineEntry: [0x0000000101336740-0x0000000101336750): ../../modules/video_coding/packet_buffer.h:37
Symbol: id = {0x0005803a}, range = [0x0000000101336740-0x0000000101336760), name="webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC1Ev"
Variable: id = {0x4d300038664}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-8), decl =
Address: WebRTC[0x0000000000f23760] (WebRTC.__TEXT.__text + 15867936)
Summary: WebRTC`webrtc::video_coding::PacketBuffer::Packet::Packet() at packet_buffer.h:37
Module: file = "/Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/WebRTC", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "../../modules/video_coding/packet_buffer.cc", language = "c++14"
Function: id = {0x4d300038672}, name = "webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled = "_ZN6webrtc12video_coding12PacketBuffer6PacketC2Ev", range = [0x0000000101336760-0x00000001013367e3)
FuncType: id = {0x4d300038672}, byte-size = 0, decl = packet_buffer.h:37, compiler_type = "void (void)"
Blocks: id = {0x4d300038672}, range = [0x101336760-0x1013367e3)
LineEntry: [0x0000000101336760-0x0000000101336770): ../../modules/video_coding/packet_buffer.h:37
Symbol: id = {0x0005803e}, range = [0x0000000101336760-0x00000001013367f0), name="webrtc::video_coding::PacketBuffer::Packet::Packet()", mangled="_ZN6webrtc12video_coding12PacketBuffer6PacketC2Ev"
Variable: id = {0x4d30003868e}, name = "this", type = "webrtc::video_coding::PacketBuffer::Packet *", location = DW_OP_fbreg(-8), decl =
It seems weird that there are duplicate entries (and I have no idea why), but at least lldb seems to know the name. The other thing that worries me is the relative path in CompileUnit but I am not sure how to fix that (compile flags while building libwebrtc?). The relative path is not correct if you take the /Users/rudolfs/Git/webrtc-checkout/src/out/Debug/WebRTC.framework/ as a base name, since then it should be ../../../modules, but maybe lldb treats frameworks differently and uses /Users/rudolfs/Git/webrtc-checkout/src/out/Debug as a base path?
I've seen multiple questions here regarding target.source-map, but I don't understand if this would help here and what should I override?
I also tried setting a custom working directory in the Xcode scheme (to /Users/rudolfs/Git/webrtc-checkout/src/out/Debug) in hope that the relative paths would not get resolved but that did not help.
The output of image lookup -v is showing 4 matches for this source line -- this method was inlined in four different places (the last two looking like a ctor).
Looking at the LineEntrys, lldb is trying to show the source at ../../modules/video_coding/packet_buffer.cc:58 or ../../modules/video_coding/packet_buffer.h:37.
This is going to be tricky for lldb to resolve. The compiler has created debug information with relative paths. I thought most compilers would try to come up with an absolute path to the location of the source files for the debug information, but it's been a while since I've looked into a problem like this. It may be that invoking your compiler with an absolute source pathname may work, if you're invoking it with a relative one right now.
A common problem is when the source was compiled on one computer in /build-dir but on your debug system the source is in /src-dir -- there's an lldb setting specifically for this case, target.source-map which remaps the file paths in the debug information when looking for the source at debug-time. But that's not going to help you here.
I encountered a similar problem. source-map config works for me. You can try map ../.. to /Users/rudolfs/Git/webrtc-checkout/src.

How to set rules for generic type parameters in VisualStudio?

The picture below shows the warning I keep getting in Visual Studio 2017:
I got this off some website and I have tried all sorts of things. Does anyone know how I can get rid of this?
Here is my the part of my .editorconfig related to naming:
###############################
# Naming Conventions #
###############################
# Style Definitions
dotnet_naming_style.pascal_case_style.capitalization = pascal_case
dotnet_naming_style.camel_case_style.capitalization = camel_case
dotnet_naming_style.I_prefix_style.required_prefix = I
dotnet_naming_style.I_prefix_style.capitalization = pascal_case
# Use PascalCase for constant fields
dotnet_naming_rule.constant_fields_should_be_pascal_case.severity = warning
dotnet_naming_rule.constant_fields_should_be_pascal_case.symbols = constant_fields
dotnet_naming_rule.constant_fields_should_be_pascal_case.style = pascal_case_style
dotnet_naming_symbols.constant_fields.applicable_kinds = field
dotnet_naming_symbols.constant_fields.applicable_accessibilities = *
dotnet_naming_symbols.constant_fields.required_modifiers = const
# Use PascalCase for public fields
dotnet_naming_rule.pascal_case_for_public_fields.severity = warning
dotnet_naming_rule.pascal_case_for_public_fields.symbols = public_fields
dotnet_naming_rule.pascal_case_for_public_fields.style = pascal_case_style
dotnet_naming_symbols.public_fields.applicable_kinds = field
dotnet_naming_symbols.public_fields.applicable_accessibilities = public
# Interfaces must be PascalCase and have an I prefix
dotnet_naming_rule.interfaces_start_with_I.severity = warning
dotnet_naming_rule.interfaces_start_with_I.symbols = any_interface
dotnet_naming_rule.interfaces_start_with_I.style = I_prefix_style
dotnet_naming_symbols.any_interface.applicable_accessibilities = *
dotnet_naming_symbols.any_interface.applicable_kinds = interface
# Classes, structs, methods, enums, events, properties, namespaces, delegates must be PascalCase
dotnet_naming_rule.general_naming.severity = warning
dotnet_naming_rule.general_naming.symbols = general
dotnet_naming_rule.general_naming.style = pascal_case_style
dotnet_naming_symbols.general.applicable_kinds = class,struct,enum,property,method,event,namespace,delegate
dotnet_naming_symbols.general.applicable_accessibilities = *
# Everything else is camelCase
dotnet_naming_rule.everything_else_naming.severity = warning
dotnet_naming_rule.everything_else_naming.symbols = everything_else
dotnet_naming_rule.everything_else_naming.style = camel_case_style
dotnet_naming_symbols.everything_else.applicable_kinds = *
dotnet_naming_symbols.everything_else.applicable_accessibilities = *
# prefix_type_parameters_with_t_style - Generic Type Parameters must be PascalCase and the first character must be a 'T'
dotnet_naming_style.prefix_type_parameters_with_t_style.capitalization = pascal_case
dotnet_naming_style.prefix_type_parameters_with_t_style.required_prefix = T
You can get nice set of rules from here.

How to check if LLDB loaded debug symbols from shared libraries?

On Linux I use
(gdb) i shared
in gdb and gdb prints a list of libraries either with a star * if no debug symbols are loaded or without it if loaded, e.g:
0x0000000100c18660 0x0000000100c489a0 Yes (*) /Users/anon/work/software/webrtc-audio-processing-0.1/build_darwin/../bin/darwin/lib/libwebrtc_audio_processing.0.dylib
0x0000000100c57ca0 0x0000000100c76978 Yes /Users/anon/work/software/speex/speex/speex-1.2rc2/build_darwin/../bin/darwin/lib/libspeex.1.dylib
I found that in LLDB I should use
(lldb) image list
to do the same. But I get a list of libraries which says nothing to me on whether debug symbols are loaded for the lib or not, e.g:
[181] 19269C1D-EB29-384A-83F3-7DDDEB7D9DAD 0x00007fff8d2d3000 /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
[182] 8D7BA9BA-EB36-307A-9119-0B3D9732C953 0x00007fff879ee000 /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
[183] 6F03761D-7C3A-3C80-8031-AA1C1AD7C706 0x00007fff92e52000 /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
So how do I check if debug symbols are loaded by LLDB?
UPDATE: I just decided to post output of (lldb) image lookup -vn <function> (thanks Jim) for others to know what it looks like:
image lookup -vn Herqq::Upnp::HSsdp::init
2 matches found in libHUpnp.2.dylib:
Address: libHUpnp.2.dylib[0x00000000000283f0] (libHUpnp.2.dylib.__TEXT.__text + 150384)
Summary: libHUpnp.2.dylib`Herqq::Upnp::HSsdp::init() at hssdp.cpp:804
Module: file = "libHUpnp.2.dylib", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "/Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp", language = "c89"
Function: id = {0xa0002401f}, name = "init", range = [0x00000000000283f0-0x0000000000028511)
FuncType: id = {0xa0002401f}, decl = hssdp.h:304, clang_type = "_Bool (void)"
Blocks: id = {0xa0002401f}, range = [0x000283f0-0x00028511)
LineEntry: [0x00000000000283f0-0x00000000000283ff): /Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp:804
Symbol: id = {0x00000c9b}, range = [0x00000000000283f0-0x0000000000028520), name="Herqq::Upnp::HSsdp::init()", mangled="_ZN5Herqq4Upnp5HSsdp4initEv"
Variable: id = {0xa0002403a}, name = "this", type= "Herqq::Upnp::HSsdp *", location = DW_OP_fbreg(-16), decl =
Variable: id = {0xa00024047}, name = "herqqLog__", type= "HLogger", location = DW_OP_fbreg(-32), decl = hssdp.cpp:805
Variable: id = {0xa00024056}, name = "ha", type= "QHostAddress", location = DW_OP_fbreg(-56), decl = hssdp.cpp:812
Address: libHUpnp.2.dylib[0x0000000000028550] (libHUpnp.2.dylib.__TEXT.__text + 150736)
Summary: libHUpnp.2.dylib`Herqq::Upnp::HSsdp::init(QHostAddress const&) at hssdp.cpp:817
Module: file = "libHUpnp.2.dylib", arch = "x86_64"
CompileUnit: id = {0x00000000}, file = "/Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp", language = "ISO C++:1998"
Function: id = {0xa0002408f}, name = "init", range = [0x0000000000028550-0x000000000002862d)
FuncType: id = {0xa0002408f}, decl = hssdp.h:321, clang_type = "_Bool (const class QHostAddress &)"
Blocks: id = {0xa0002408f}, range = [0x00028550-0x0002862d)
LineEntry: [0x0000000000028550-0x0000000000028564): /Users/blade/work/software/HUPnP/build-herqq-Desktop_Qt_5_5_0_clang_64bit-Debug/hupnp/../../herqq/hupnp/src/ssdp/hssdp.cpp:817
Symbol: id = {0x00000ca3}, range = [0x0000000000028550-0x0000000000028630), name="Herqq::Upnp::HSsdp::init(QHostAddress const&)", mangled="_ZN5Herqq4Upnp5HSsdp4initERK12QHostAddress"
Variable: id = {0xa000240aa}, name = "this", type= "Herqq::Upnp::HSsdp *", location = DW_OP_fbreg(-16), decl =
Variable: id = {0xa000240b7}, name = "unicastAddress", type= "const QHostAddress &", location = DW_OP_fbreg(-24), decl = hssdp.cpp:816
Variable: id = {0xa000240c6}, name = "herqqLog__", type= "HLogger", location = DW_OP_fbreg(-40), decl = hssdp.cpp:818
If your binary was built with a dSYM, then the dSYM will show up on the line after the binary's listing in image list.
There isn't an easy way to do this if the binary is using the "leave the debug information in the .o file" style which is the default for the Debug configuration in Xcode. I filed a bug to make that easier to see.
One fairly simple way to do it is:
(lldb) image lookup -vn <SomeFunctionNameThatShouldHaveDebugInfo>
If the output of that command includes a CompileUnit, then the .o file containing that function has debug information, otherwise, not.

getting different values when inspecting an object with gdb

I'm using gdb to debug a c++ program which terminated with a segmentation fault. Looking at the stack, the first few frames are:
#0 0x0041c496 in cDefaultList::doInsert (this=0x9c69708, obj=0x9c69348) at cdefaultlist.cc:119
#1 0x0041c86c in cDefaultList::take (this=0x9c69708, obj=0x9c69348) at cdefaultlist.cc:189
#2 0x0043bd9c in cPacket::encapsulate (this=0x9c69708, msg=0x9c69348) at cmessage.cc:589
#3 0x08448861 in MobIPv6mn::handleMessage (this=0x96d3350, msg=0x9c69348) at src/networklayer/numbatIPv6/mip6.cc:170
#4 0x0046069c in cSimulation::doOneEvent (this=0x87f3318, mod=0x96d3350) at csimulation.cc:627
#5 0x0015ecdf in Tkenv::doRunSimulation (this=0x87f3110) at tkenv.cc:529
#6 0x0015e899 in Tkenv::runSimulation (this=0x87f3110, mode=2, until_time=..., until_eventnum=0, until_msg=0x0, until_module=0x0) at tkenv.cc:402
#7 0x00168f10 in run_cmd (interp=0x8842e48, argc=2, argv=0xbfffcb00) at tkcmd.cc:430
So I do:
frame 3
and later want to inspect "msg" with print * (IPv6 *) msg, because that's what the type of msg should be. Well, when I look at the Ipv6-specific fields of msg, I always get completely different values, like:
srcIP_var = {addr = "\000\000\000\000\000\000i\000\000\000\001\000\000\000\001"}, dstIP_var = {
addr = "\000\000H\223\306\t\000\000\000\000\000\000\000\000\000"}, BindingUpdate_var = false, BindingAck_var = false, Dhcpv6Relay_var = false}
or
srcIP_var = {addr = "\000\000\000\000\000\000)\000\000\000\020\264K\000\020\264"}, dstIP_var = {addr = "\346\t:SCALEEXP_UNIN"}, BindingUpdate_var = 73,
BindingAck_var = 84, Dhcpv6Relay_var = 73}
or even:
srcIP_var = {addr = "\000\000\000\000\000\000\061\000\000\000\030\264K\000\030\264"}, dstIP_var = {
addr = "K\000\a\350N\v\304\350N\v\001\000\000\000\001"}, BindingUpdate_var = false, BindingAck_var = false, Dhcpv6Relay_var = false}
Why is that? Does that mean the packet is not really of the type I tried to cast it to?
Thanks a lot!
Are you sure you're not just looking at uninitialized (or freed and then re-used) memory? That could explain why your code is crashing as well.