[Lldb-commits] [PATCH] D13201: Fix segmentation fault in lldb_private::Symbols::LocateExecutableSymbolFile()

Zachary Turner via lldb-commits lldb-commits at lists.llvm.org
Mon Sep 28 14:14:44 PDT 2015


zturner added a comment.

As for the test, this could be a good candidate for a unit test.  It's not advertised very well so there's definitely some work for us to do on that front, but basically you can run `ninja check-lldb-unit`.  Seems like you could just create a `ModuleSpec` on the stack, construct it the way you want, and pass it to this function, and verify the output in a couple of different scenarios.  At a minimum the one you ran into this segfault with, but if you can think of a couple of other useful scenarios to test it wouldn't hurt to have a couple go in at the same time.


================
Comment at: source/Host/common/Symbols.cpp:238-250
@@ -237,15 +237,15 @@
 
         // Add /usr/lib/debug directory.
         debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", true));
 
         std::string uuid_str;
         const UUID &module_uuid = module_spec.GetUUID();
         if (module_uuid.IsValid())
         {
             // Some debug files are stored in the .build-id directory like this:
             //   /usr/lib/debug/.build-id/ff/e7fe727889ad82bb153de2ad065b2189693315.debug
             uuid_str = module_uuid.GetAsString("");
             uuid_str.insert (2, 1, '/');
             uuid_str = uuid_str + ".debug";
         }
 
----------------
enlight wrote:
> zturner wrote:
> > Can you do all of this only if the target is not Windows?
> You mean if the **host** is not Windows? Skipping `/usr/lib/debug` on Windows makes sense, but it seems like the `uuid_str` stuff could still apply if the symbol files are copied to or shared with Windows.
You're right, the host.  Also seems reasonable about the `uuid_str` stuff.


Repository:
  rL LLVM

http://reviews.llvm.org/D13201





More information about the lldb-commits mailing list