Thanks a lot Greg! This helps alot, at the moment of reading I have already solved the issue.
clang 5.0.1 makes something wrong when using -fsanitize=address, with clang 7.0 everything is ok!! I have spent alot of time making sure the right standart lib is linked/loaded, it was the case I think… I will have a look later on your very good suggestions! (I am quite a newbie with lldb) :-) Gabriel > Am 14.01.2018 um 22:40 schrieb Greg Clayton <clayb...@gmail.com>: > > You can do a: > > (lldb) frame var --raw temp > > It will show you the internals of the std::string. If the string is over 22 > characters, one of the items in the raw std::string should point to the > buffer and the length should be contained inside there as well. The value you > see is due to a special summary plug-in that is extracting the std::string > value from the innards of the STL implementation. > > So a few things could be wrong: > 1 - compiler's location for the variable could be wrong (optimizations?) so > we show the wrong value > 2 - your STL is newer and might pull some tricks when storing the string and > our summary extracting code is doing the wrong thing for your std:string. > Many std::string implementations will store up to twenty some character > inlined into the std::string itself when the string is short. Maybe we aren't > handling that quite correctly. What is the actual length of your std::string > named "temp"? > > As a work around, try to run an expression to get the "const char *" > (lldb) p temp.c_str() > > See if this pointer is the output of the "frame var --raw temp" command. Also > to see if the string value is inlined you can do: > > (lldb) p &temp > (lldb) p sizeof(temp) > > Then see if the "const char *" value from "p temp.c_str()" falls between the > "&temp" and "&temp + sizeof(temp)". > > Let me know what you find. My guess is we might not be handling special cases > when the string is inlined, but that is just a guess. > > Greg Clayton > >> On Jan 13, 2018, at 6:29 AM, Gabriel Nützi via lldb-dev >> <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Dear Dev-Team >> >> Ok this question is not a really dev-question, but I more seeking for some >> hints: >> >> I have some troubles getting lldb to show me a correct string output in a >> CefSchemeHandlerFactory >> >> https://github.com/gabyx/ExecutionGraph/blob/a24f4c1b538edd6b138503fb96db6fbd71c3b1c5/gui/executionGraphGui/cefapp/FileSchemeHandlerFactory.cpp#L31 >> >> <https://github.com/gabyx/ExecutionGraph/blob/a24f4c1b538edd6b138503fb96db6fbd71c3b1c5/gui/executionGraphGui/cefapp/FileSchemeHandlerFactory.cpp#L31> >> >> When I debug this application built with clang-5.0.1 (llvm install with >> brew) with the debugger lldb: >> >> [code] >> [ 96%] Building CXX object >> gui/executionGraphGui/CMakeFiles/ExecutionGraphGUI.dir/cefapp/FileSchemeHandlerFactory.cpp.o >> /usr/local/opt/llvm/bin/clang++ >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/gui/executionGraphGui >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/include >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/build/include >> -I/usr/local/include/eigen3 >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/build/src/meta/include >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/build/external/args-src >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/build/external/cefbinaries-src >> -I/Users/gabrielnuetzi/Desktop/ExecutionGraph/build/external/cefbinaries-src/include >> -g -arch x86_64 -mmacosx-version-min=10.9 -std=c++14 -lc++experimental >> -ferror-limit=50 -Werror=return-type -g -g3 -fno-omit-frame-pointer >> -Weverything -Wpedantic -Wno-deprecated-register -Wno-documentation >> -Wno-old-style-cast -Wno-comment -Wno-float-equal -Wno-deprecated >> -Wno-c++98-compat-pedantic -Wno-undef -Wno-unused-macros -fsanitize=leak >> -fsanitize=address -o >> CMakeFiles/ExecutionGraphGUI.dir/cefapp/FileSchemeHandlerFactory.cpp.o -c >> /Users/gabrielnuetzi/Desktop/ExecutionGraph/gui/executionGraphGui/cefapp/FileSchemeHandlerFactory.cpp >> [/code] >> >> I only see really weird output, such as: >> >> [code] >> Process 3741 stopped >> * thread #22, name = 'Chrome_IOThread', stop reason = breakpoint 1.1 >> frame #0: 0x000000010011eb09 >> ExecutionGraphGUI`FileSchemeHandlerFactory::Create(this=0x00006060000dc340, >> scheme_name=0x0000700007ac9c18, request=(ptr_ = 0x0000700007ac9c10)) at >> FileSchemeHandlerFactory.cpp:37 >> 34 { >> 35 ++itC; >> 36 } >> -> 37 std::path url(itC, temp.end()); >> 38 // e.g. url : "host/folderA/folderB/file.ext"" >> 39 >> 40 // Split urlPrefix from front (e.g "host/folderA") >> >> Process 3741 launched: >> '/Users/gabrielnuetzi/Desktop/ExecutionGraph/build/gui/executionGraphGui/Debug/ExecutionGraphGUI.app/Contents/MacOS/ExecutionGraphGUI' >> (x86_64) >> (lldb) fr v temp >> (std::__1::string) temp = >> "\x85\xac\a\0p\0\0\x10\x85\xac\a\0p\0\0�\a\0p\0\0\xa0\x83\xac\a\0p\0\0`\x83\xac\a\0p\0\0@" >> [/code] >> >> Why is this, or where could the problem be? I have a really hard time to >> figure out why I cannot successfully debug these strings in my application. >> The above example has been done by launching lldb from the terminal. (No >> python formatters have been loaded I think…? at least not by me) >> In a normal main.cpp Application like the one here: >> https://github.com/gabyx/ExecutionGraph/blob/devGUI/gui/testDebugger/build.sh >> >> <https://github.com/gabyx/ExecutionGraph/blob/devGUI/gui/testDebugger/build.sh> >> everything works and the strings are formatted normally. >> >> Any help really welcome! >> BR >> >> Gabriel Nützi >> MSc ETH Mechanical Engineering >> >> gnue...@gmail.com <mailto:gnue...@gmail.com> >> +41 (0) 77 424 86 45 >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > Gabriel Nützi MSc ETH Mechanical Engineering gnue...@gmail.com +41 (0) 77 424 86 45
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
