[lldb-dev] "Correctly use GetLoadedModuleList to take advantage of libraries-svr4" can cause LLDB to abort

[Jim Ingham via lldb-dev]

IIUC an llvm::Expected is only supposed to abort if you leave its scope with an un-consumed error.  LLDB_LOG_ERROR is supposed to consume the error - the code looks like it is doing that.  So if you are still seeing an abort when there's an error, then it sounds like something is wrong with LLDB_LOG_ERROR.

Expected is supposed to force you to check the error - by aborting if you don't - but you are free to discard the error if it is non-fatal by consuming it, and then you should not abort.

Jim


> On Aug 13, 2019, at 11:19 AM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> Hi Antonio,
>  
> This is in regards to https://reviews.llvm.org/D64013 , specifically this code in ProcessGDBRemote::GetImageInfoAddress:
>  
>   if (addr == LLDB_INVALID_ADDRESS) {
>     llvm::Expected<LoadedModuleInfoList> list = GetLoadedModuleList();
>     if (!list) {
>       Log *log(ProcessGDBRemoteLog::GetLogIfAllCategoriesSet(GDBR_LOG_PROCESS));
>       LLDB_LOG_ERROR(log, list.takeError(), "Failed to read module list: {0}");
>     } else {
>       addr = list->m_link_map;
>     }
>   }
>  
> If LLVM_ENABLE_ABI_BREAKING_CHECKS is set to 1 (which is true when asserts are enabled), llvm::Expected will call abort() if there is an error.
> GetLoadedModuleList() has many reasons to set an error, including when XML is not available, or when the stub doesn’t support remote modules.
>  
> I don’t think we ever want to crash LLDB if the remote stub doesn’t support something. I don’t think llvm::Expected is the right solution here, and I think it should be removed.
>  
> Ted
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev