Summary:
There was a race condition regarding the output of the inferior process. The reading of the
output is performed on a separate thread, and there was no guarantee that the output will get
eventually consumed. Because of that, it was happening that calling Process::GetSTDOUT was not
returning anything even though the process was terminated and would definitely not produce any
further output. This was usually happening only under very heavy system load, but it can be
reproduced by placing an usleep in the stdio thread (Process::STDIOReadThreadBytesReceived).
This patch addresses this by adding synchronization capabilities to the Communication thread.
After calling Communication::SynchronizeWithReadThread one can be sure that all pending input has
been processed by the read thread. This function is then called after every public event which
stops the process to obtain the entire process output.
Test Plan: TestProcessIO.py should now succeed every time instead of flaking in and out.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8246
llvm-svn: 232023
Fixed test case to copy redirected stdout/stderr files from remote
target to host
llgs wasn't bothering to put the pty master file handle in the right
place if stdout/stderr were redirected to a file. It is still needed
for stdin.
Corrected some log message text
llvm-svn: 229141
We want to forward stdin when stdio is not disabled and when we're not
redirecting stdin from a file.
renamed m_stdio_disable to m_stdin_forward and inverted value because
that's what we want to remember.
There was previously a bug that if you redirected stdin from a file,
stdout and stderr would also be redirected to /dev/null
Adds support for remote target to TestProcessIO.py
Fixes ProcessIOTestCase.test_stdin_redirection_with_dwarf for remote
Linux targets
llvm-svn: 228744
These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them. In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775
The main issue was if you didn't specify all three (stdin/out/err), you would get file actions added to the launch that would always use the pseudo terminal. This is now fixed.
Also fixed the test suite test that handles IO to test redirecting things individually and all together and in other combinations to make sure we don't regress.
<rdar://problem/18638226>
llvm-svn: 219711
This has led to many test suite failures because of copy and paste where new test cases were based off of other test cases and the "mydir" variable wasn't updated.
Now you can call your superclasses "compute_mydir()" function with "__file__" as the sole argument and the relative path will be computed for you.
llvm-svn: 196985
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
This test is incorrect as functions that return lldb.SBThread objects never return None, they just return lldb.SBThread objects that contain invalid opaque classes.
llvm-svn: 177416
- rework the way SBDebugger.SetAsync() is used to avoid side effects (reset original value at TearDownHook)
- refactor expectedFailureClang (and add expectedFailureGcc decorator)
- mark TestChangeValueAPI.py as expectedFailureGcc due to PR-15039
llvm-svn: 175523
SBProcess.GetSTDERR() not getting stderr of the launched process
Since we are launch the inferior with:
process = target.LaunchSimple(None, None, os.getcwd())
i.e., without specifying stdin/out/err. A pseudo terminal is used for
handling the process I/O, and we are satisfied once the expected output
appears in process.GetSTDOUT().
llvm-svn: 147983
Instead of getting the location of the variable and converting the hex string to an int, just use
val.AddressOf().GetValueAsUnsigned() to compute the address of the memory region to read from.
llvm-svn: 146719
so that we can do Python scripting like this:
target = self.dbg.CreateTarget(self.exe)
self.dbg.SetAsync(True)
process = target.LaunchSimple(None, None, os.getcwd())
process.PutSTDIN("Line 1 Entered.\n")
process.PutSTDIN("Line 2 Entered.\n")
process.PutSTDIN("Line 3 Entered.\n")
Add TestProcessIO.py to exercise the process IO API: PutSTDIN()/GetSTDOUT()/GetSTDERR().
llvm-svn: 145282
the SBType implementation classes.
Fixed LLDB core and the test suite to not use deprecated SBValue APIs.
Added a few new APIs to SBValue:
int64_t
SBValue::GetValueAsSigned(int64_t fail_value=0);
uint64_t
SBValue::GetValueAsUnsigned(uint64_t fail_value=0)
llvm-svn: 136829
is just wrong and resulted in the inferior's output getting mixed into the GDB remote communication's
log file. Change all test cases to not pass os.ctermid() and either use SBTarget.LaunchSimple() or
SBTarget.Launch() and pass None as stdin_path/stdout_path/srderr_path to use a pseudo terminal.
rdar://problem/9716499 program output is getting mixed into the GDB remote communications
llvm-svn: 134940
those lldb objects which implement the IsValid() method, let's change the rest of
the test suite to use the more compact truth value testing pattern (the Python way).
llvm-svn: 131970
expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.
The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.
There's also a general setting:
target.prefer-dynamic-value (boolean) = 'true'
which is consulted if you call "frame var" without supplying a value for the -d option.
llvm-svn: 129623
API with a process not in eStateConnected, and checks that the remote launch failed.
Modify SBProcess::RemoteLaunch()/RemoteAttachToProcessWithID()'s log statements to fix a
crasher when logging is turned on.
llvm-svn: 127055
// When stopped on breakppint 1, and then 2, we can get the line entries using
// SBFrame API SBFrame.GetLineEntry(). We'll get the start addresses for the
// two line entries; with the start address (of SBAddress type), we can then
// resolve the symbol context using the SBTarget API
// SBTarget.ResolveSymbolContextForAddress().
//
// The two symbol context should point to the same symbol, i.e., 'a' function.
Add two utility functions to lldbutil.py:
o get_stopped_threads(process, reason):
return the list of threads with the specified stop reason or an empty list if not found
o get_stopped_thread(process, reason):
return the first thread with the given stop reason or None if not found
llvm-svn: 126916
o int_to_bytearray()
o bytearray_to_int()
They return/interpret the bytearray in the little endian format.
For big endian, simply perform ba.reverse() on the bytearray object.
And modify TestProcessAPI.py to take advantage of the functions.
llvm-svn: 126813
among other SBProcess APIs, to write (int)256 into a memory location of a global variable
(int)my_int and reads/checks the variable afterwards.
llvm-svn: 126792
the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.
On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.
llvm-svn: 126736
Pavel Labath