<div dir="ltr">Ahh yes, ConnectionFileDescriptor. I have that on my Todo list, but a real fix is going to be a very large undertaking. Assuming you upstream your fix, please include me on the review, because I'm already pretty familiar with this problem.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 4:49 PM, Ted Woodward <span dir="ltr"><<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I did the kill command, which gets down to ProcessGDBRemote::DoDestroy(), which sends a “k” packet by calling GDBRemoteCommunicationClient::SendPacketAndWaitForResponse(), which goes through a couple layers to GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock(). That calls Communication::Read(), which calls ConnectionFileDescriptor::Read(). That calls recv(), which returns -1, and then calls Error::SetErrorToErrno(). ConnectionFileDescriptor::Read() then parses the error, assuming the error value is a POSIX error.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Adding a call to GetLastError() and converting certain error codes to POSIX errors solved my crash issue. Inside #ifdef _WIN32, of course, because I don’t want to break my Linux version </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That reminds me of another (minor) bug. If the call to SendPacketAndWaitForResponse() doesn’t return PacketResult::Success, LLDB prints an error:<u></u><u></u></span></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:9.5pt;font-family:Consolas;color:black;background:white"> exit_string.assign(</span><span style="font-size:9.5pt;font-family:Consolas;color:#a31515;background:white">"failed to send the k packet"</span><span style="font-size:9.5pt;font-family:Consolas;color:black;background:white">);<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But the RSP standard says the server doesn’t have to send a response to the “k” packet. Hanging up is legal. If the return value is PacketResult::ErrorDisconnected, it shouldn’t print the error.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ted<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Zachary Turner [mailto:<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>] <br>
<b>Sent:</b> Thursday, August 28, 2014 3:01 PM<br><b>To:</b> Ted Woodward<br><b>Cc:</b> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br><b>Subject:</b> Re: [lldb-dev] Odd error involving python subprocess.Popen and gdb-remote hangup on Windows<u></u><u></u></span></p>
<div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Indeed, relying on errno on Windows is not the correct solution for many reasons. Actually I don't think converting their error numbers to POSIX error values is a good solution either. I'm of the philosophy that if you're on Windows you should be writing windows code. Recently I added eErrorTypeWin32 as a category to lldb::Error. When you create an error with that category, you can directly pass it the result of GetLastError(). Unfortunately, that's literally all I did. Planned for the future would be an implementation of Success() and Failure() that returns the right thing when type == eErrorTypeWin32, and calling FormatMessage() with the error code so that the message is set automatically. If you would like to post patches toward making lldb::Error better handle the case when type == eErrorTypeWin32, that would be very welcome.<u></u><u></u></p>
<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">BTW, where is this particular call to Error::SetErrorToErrno() that this is coming from?<u></u><u></u></p></div></div><div><p class="MsoNormal" style="margin-bottom:12.0pt">
<u></u> <u></u></p><div><p class="MsoNormal">On Thu, Aug 28, 2014 at 11:53 AM, Ted Woodward <<a href="mailto:ted.woodward@codeaurora.org" target="_blank">ted.woodward@codeaurora.org</a>> wrote:<u></u><u></u></p><div>
<div><p class="MsoNormal">I have a python script that automatically launches a simulator and connects to it with gdb-remote. Everything works fine on Linux. But when I issue the “kill” command on Windows, LLDB crashes.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">This only happens if I launch the simulator (or any external program) using python. I’m using subprocess.Popen, but I’ve also tried os.spawnl. I’ve traced the problem down to reading errno in Error::SetErrorToErrno(). In this case, errno is 0, so no error is reported, and the -1 that recv returns is used as a buffer size and LLDB crashes. If I don’t launch a program using Popen, errno is 2, and everything is handled correctly.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Stepping into the errno access, GetLastError() is correctly set to WSAECONNRESET, but ptd->_terrno, which errno is set to, is 0. This seems like a Visual Studio 2012 runtime bug.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">I think maybe we shouldn’t rely on errno on Windows, but call GetLastError() and convert their error numbers to POSIX error values.<u></u><u></u></p><p class="MsoNormal">
<span style="color:#888888"> <u></u><u></u></span></p><p class="MsoNormal"><span style="color:#888888">Ted<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#888888"> <u></u><u></u></span></p></div></div><p class="MsoNormal" style="margin-bottom:12.0pt">
<br>_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><u></u><u></u></p>
</div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></blockquote></div><br></div>