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)
Related
I am passing a compound structure pointer to a function after doing all the memory initializations in a test fixture. But as soon as the function gets called the sizeof that struct changes.
Have tried setting watchpoints and everything. don't the what's the issue.
Need help.
This is the code for the test.
sizeof(*ueCb) changes just after calling the function cwRrcSendMibCfgReq.
The function is copying some parameters from ueCb. ueCb has multiple structures inside of it. Accessing ueCb->currContestCellForSel in the function throws a segmentation fault even though I have explicitly allocated memory here. I have checked that the allocation occurs. I check sizeof(*ueCb) in gdb keeping the mentioned fucntion as a breakpoint. The header files are the same. Also ueId remains intact while calling the function. CW_ALLOC is an internal macro which allocates memory. it's working fine I have checked that.
Can't share the whole code because it's part of IP. This code is related to 5G protocol stack.My job is to do unit testing and the entire team isn't able to figure out where the problem is.
TEST(testMib1, test)
{
CwRrcUeCb* ueCb;
CW_ALLOC(CW_REG,CW_POOL,&ueCb, sizeof(CwRrcUeCb));
memset(ueCb, 0, sizeof(CwRrcUeCb));
ueCb->currContestCellForSel = (CwRrcCellCb *)
malloc(sizeof(CwRrcCellCb));
ueCb->currContestCellForSel->phyCellId = 5;
ueCb->ueId = 5;
S16 ret = ROK;
ret = cwRrcSendMibCfgReq(ueCb); // sizeof *ueCb changes after this statement
free(ueCb->currContestCellForSel);
CW_FREE(CW_REG, CW_POOL, ueCb, sizeof (CwRrcUeCb));
// have changed the order just to get to the main point
EXPECT_EQ(ROK, ret);
printf(" Event 9 Done\n\n\n");
}
The backtrace is as follows:
(gdb) backtrace
#0 0x000000000053a673 in cwRrcSendMibCfgReq (rrcUeCb=0x7ffff5d45320) at ../src/5gnrueapp/cw_rrc_fsm.c:2745
#1 0x000000000061dd59 in testMib1_test_Test::TestBody (this=0xa73500) at ../unittest/test_Event9Mib1.cc:79
#2 0x00007ffff71847a3 in void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing:
:Test::*)(), char const*) () from /lib64/libgtest.so.0
#3 0x00007ffff717ab27 in testing::Test::Run() () from /lib64/libgtest.so.0
#4 0x00007ffff717abce in testing::TestInfo::Run() () from /lib64/libgtest.so.0
#5 0x00007ffff717acd5 in testing::TestCase::Run() () from /lib64/libgtest.so.0
#6 0x00007ffff717e018 in testing::internal::UnitTestImpl::RunAllTests() () from /lib64/libgtest.so.0
#7 0x00007ffff717e2a7 in testing::UnitTest::Run() () from /lib64/libgtest.so.0
#8 0x000000000061e156 in main (argc=1, argv=0x7fffffffe1d8) at ../unittest/test_main.cc:38
the function which I'm testing
S16 cwRrcSendMibCfgReq(CwRrcUeCb * rrcUeCb)
{
CtzMibConfigRequest *mibConfig = NULLP;
CW_ALLOC(CW_REG, CW_POOL, &mibConfig, sizeof (CtzMibConfigRequest));
if(NULL == mibConfig)
{
RLOG1(L_FATAL,"Memory Allocation Failed while sending Mib config req ueId:%d",rrcUeCb->ueId);
RETVALUE(RFAILED);
}
mibConfig->pres.pres = 1;
mibConfig->systemFrameNumber = rrcUeCb->cwMibInfo.systemFrameNumber;
mibConfig->subCarrierSpacingCommon = rrcUeCb->cwMibInfo.subCarrierSpacingCommon;
mibConfig->ssb_SubcarrierOffset = rrcUeCb->cwMibInfo.ssb_SubcarrierOffset;
mibConfig->dmrs_TypeAPosition = rrcUeCb->cwMibInfo.dmrs_TypeAPosition;
mibConfig->pdcch_ConfigSIB1.controlResourceSetZero =
rrcUeCb->cwMibInfo.pdcch_ConfigSIB1.controlResourceSetZero;
mibConfig->pdcch_ConfigSIB1.searchSpaceZero = rrcUeCb->cwMibInfo.pdcch_ConfigSIB1.searchSpaceZero;
mibConfig->ueId = rrcUeCb->ueId;
mibConfig->cellId = rrcUeCb->currContestCellForSel->phyCellId;
RLOG0(L_DEBUG,"[CFGREQ] [SRC:RRC ==>> DST:CL(PHY)] : CTZ_CPHY_MIB_CFG_REQ");
printf("\n[SRC:RRC ==>> DST:CL(PHY)] : CTZ_CPHY_MIB_CFG_REQ\n");
CwLiCtzCfgReq(&cwCb.ctzSapCbLst[0]->pst,CTZ_CPHY_MIB_CFG_REQ, mibConfig);
RETVALUE(ROK);
}
Try to swap the order of these lines:
CW_FREE(CW_REG, CW_POOL, ueCb, sizeof (CwRrcUeCb));
free(ueCb->currContestCellForSel);
It seems like you first free ueCb with CW_FREE, and then you access a member pointer of ueCb with ueCb->currContestCellForSel, which might cause the segfault.
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.
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.
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.
I'm having segfault problem in my application written using C++ and compiled using GCC 4.3.2. It is running under Debian 5 x64.
The process crashed on the following line of code:
#0 0x00000000007c720f in Action::LoadInfoFromDB (this=0x7fae10d38d90)
at ../../../src/server/Action.cpp:1233
1233 m_tmap[tId]->slist[sId] = pItem;
The stack trace that i got from the core dump is as follows:
#0 0x00000000007c720f in Action::LoadInfoFromDB (this=0x7fae10d38d90)
at ../../../src/server/Action.cpp:1233
ItemGuid = <value optimized out>
ItemEntry = <value optimized out>
pItem = (class Item *) 0x2b52bae0
fields = <value optimized out>
tId = 1 '\001'
sId = 0 '\0'
result = (QueryResult *) 0x7fadcae3d8e0
#1 0x00000000007c7584 in Action::DisplayInfo (this=0x0, session=0x7fadbdd44a20)
at ../../../src/server/Action.cpp:1090
data = {<ByteBuffer> = {static DEFAULT_SIZE = 4096, _rpos = 220043248, _wpos = 5469086,
_storage = {<std::_Vector_base<unsigned char, std::allocator<unsigned char> >> = {
_M_impl = {<std::allocator<unsigned char>> = {<__gnu_cxx::new_allocator<unsigned char>> = {<No data fields>}, <No data fields>}, _M_start = 0x41200000 <Address 0x41200000 out of bounds>,
_M_finish = 0x0,
_M_end_of_storage = 0x7fad00000000 <Address 0x7fad00000000 out of bounds>}}, <No data fields>}}, m_code = 51152}
#2 0x00000000007d01a3 in Session::HandleAction (this=0x7fadbdd44a20,
recv_data=#0x25d83780) at ../../../src/server/ActionHandler.cpp:862
pAction = (Action *) 0x0
ActionId = 1079
GoGuid = <value optimized out>
In frame #1, Action::DisplayInfo was called from Session::HandleAction on pAction. However frame #1 shows this=0x0, and frame #2 shows pAction = (Action *) 0x0.
I can't understand why this caused a crash. What does this possibly mean? DisplayInfo can't be called on a null reference !
Any help is most appreciated.
Thanks
m_tmap[tId]->slist[sId] = pItem;
If that's the crash position, you're most likely indexing into non-existent data. If m_tmap is a std::map it's ok - but did you verify slist[sId] is a valid subscript?
Or - you called a member function on a NULL (or otherwise invalid)-Pointer and crash the first time you're accessing a member of the object directly, even if it's a few frames away. Are you sure pAction can't be NULL?
Stack traces needn't be valid. Firstly, you can corrupt them in your application. Secondly, optimizing compilers optimize that much away that the resulting stack traces are not reliable. Try a build with compiler optimizations disabled and use assert to verify your array subscripting is ok.
It's pretty obvious that pAction is null, and you called pAction->DisplayInfo. Look at how the addresses in Action are all invalid in frame 1. Other than that, it's hard to tell why without seeing some code, but I guess DisplayInfo calls LoadInfoFromDB either directly or indirectly.