We should implement a timeout of say 5 seconds (since this is a locally spawned lldb-server) and also watch for the spawned lldb-server process to be reaped. If the lldb-server gets reaped we need to cancel. Don't do any fancy thread canceling (no pthread_cancel or anything like that) if you do fix this, just have something locally connect to the socket and allow the accept thread to exit normally.
> On Jun 17, 2015, at 11:32 AM, Ted Woodward <ted.woodw...@codeaurora.org> > wrote: > > > With reverse-connect, lldb gets a port from the OS, spawns a listen thread > using the port, and launches lldb-server/debugserver, telling it to connect > back to lldb. lldb with then join with the listen thread. The listen thread > calls accept() to wait for the server to connect back to it. > > On Linux (and possibly other OSes), if lldb-server dies or quits before > connecting, lldb will hang. It sits waiting for accept() to return, but it > never will. > > If the child dies, the listen thread should be killed, and an error returned > to the user. > > > This is easily seen on Linux. Simply point to an alternate debugserver. Set > LLDB_DEBUGSERVER_PATH to something else, say /bin/ls. This will finish and > never connect back to lldb. > > -> setenv LLDB_DEBUGSERVER_PATH /bin/ls > ->bin/lldb /bin/ls > (lldb) target create "/bin/ls" > Current executable set to '/bin/ls' (x86_64). > (lldb) r > > <hang> > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > _______________________________________________ > lldb-dev mailing list > lldb-dev@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
