[lldb-dev] Odd error involving python subprocess.Popen and gdb-remote hangup on Windows

[Ted Woodward]

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.

 

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 J.

 

 

That reminds me of another (minor) bug. If the call to SendPacketAndWaitForResponse() doesn’t return PacketResult::Success, LLDB prints an error:

                exit_string.assign("failed to send the k packet");

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.

 

Ted

 

From: Zachary Turner [mailto:zturner at google.com] 
Sent: Thursday, August 28, 2014 3:01 PM
To: Ted Woodward
Cc: lldb-dev at cs.uiuc.edu
Subject: Re: [lldb-dev] Odd error involving python subprocess.Popen and gdb-remote hangup on Windows

 

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.

 

BTW, where is this particular call to Error::SetErrorToErrno() that this is coming from?

 

On Thu, Aug 28, 2014 at 11:53 AM, Ted Woodward <ted.woodward at codeaurora.org> wrote:

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.

 

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.

 

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.

 

I think maybe we shouldn’t rely on errno on Windows, but call GetLastError() and convert their error numbers to POSIX error values.

 

Ted

 


_______________________________________________
lldb-dev mailing list
lldb-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140828/3b045a88/attachment.html>