summaryrefslogtreecommitdiff
path: root/indra/llcommon/llprocess.cpp
AgeCommit message (Collapse)Author
2012-06-06MAINT-1144: Defend against NULL LLPluginProcessParent::mProcess.Nat Goodspeed
The change from LLProcessLauncher to LLProcess introduces the possibility of a NULL (default-constructed) LLProcessPtr. Add certain static LLProcess methods accepting LLProcessPtr, forwarding to nonstatic method when non-NULL but doing something reasonable with NULL. Use these methods in LLPLuginProcessParent.
2012-05-09CHOP-900: Use new apr_procattr_constrain_handle_set() extension.Nat Goodspeed
Now LLProcess explicitly requests APR to limit the handles passed to any child process, instead of wantonly passing whatever happens to be lying around the parent process at the time. This requires the latest APR build. Also revert LLUpdateDownloader::Implementation::mDownloadStream to llofstream (as in rev 1878a57aebd7) instead of apr_file_t*. Using APR for that file was a Band-Aid -- a single whacked mole -- for the problem more systemically addressed by apr_procattr_constrain_handle_set().
2012-04-23IQA-463: Use APR file I/O for downloaded viewer installer .exe.Nat Goodspeed
On Windows, calling CreateProcess(bInheritHandles=FALSE) is the wrong idea. In that case, CreateProcess() passes NO handles -- even the files you've explicitly designated as the child's stdin, stdout, stderr in the STARTUPINFO struct! Remove LLProcess code to tweak bInheritHandles; we should also remove the corresponding (useless) APR extension. Instead, given that the Windows file-locking problem we've observed is specific to the viewer installer .exe file downloaded by the background updater logic, use APR file I/O for that specific file. Empirically, both llofstream and std::ofstream seem to make the open file handle inheritable; but apr_file_open() documentation says: "By default, the returned file descriptor will not be inherited by child processes created by apr_proc_create()." And indeed, it does appear to sidestep the locking problem.
2012-04-18IQA-463: Make LLProcess call apr_procattr_inherit_set() extension.Nat Goodspeed
On Windows, Bad Things happen when apr_proc_create() is allowed to pass TRUE to CreateProcess(bInheritHandles). For instance, the open handle for a new installer executable file being downloaded by the background updater gets inadvertently passed to a couple slplugin.exe instances. When the viewer finishes downloading, closes the file and tries to remove it, Windows balks because the file is still open by another process. Require an apr_suite package that includes the new Linden apr_procattr_inherit_set() extension, and call it to turn off CreateProcess(bInheritHandles).
2012-03-15Promote LLProcess::ReadPipe::size() to BasePipe (hence WritePipe).Nat Goodspeed
Certain use cases need to know whether the WritePipe buffer has been flushed to the pipe, or is still pending.
2012-03-13Protect LLProcess destructor when run after APR shutdown.Nat Goodspeed
A static LLProcessPtr variable won't be destroyed until after procedural code has shut down APR. The trouble is that LLProcess's destructor unregisters itself from APR -- and, for an autokill LLProcess, attempts to kill the child process. All that is ill-advised after APR shutdown. Disable use of apr_pool_note_subprocess() mechanism. This should be another viable way of coping with static autokill LLProcessPtr variables: when the designated APR pool is cleaned up, APR promises to kill the child process. But whether it's an APR bug or a calling error, the present (now disabled) call in LLProcess results in OUR process, the viewer, getting SIGTERM when it asks to clean up the global APR pool.
2012-03-05Further reduce the block size that LLProcess writes to child pipe.Nat Goodspeed
It seems that on Windows, even 32K is too big: one in three load-test runs fails with a duplicated block. Empirically, reducing it to 4K makes it much more stable -- at least we can run successfully 100 consecutive times, which is a step in the right direction.
2012-03-03Break large buffer into chunks to write to LLProcess child pipe.Nat Goodspeed
On Windows we ran into trouble trying to write a biggish (~1 MB) buffer of data to the child process's stdin pipe with a single apr_file_write() call. The child actually received corrupted data -- suggesting a possible bug in either APR or Windows pipes; the same test driving the same logic worked fine on Mac and Linux. Empirically, iterating over chunks of the buffered data is more robust.
2012-03-02Clarify LLProcess debug log message about reading from child pipe.Nat Goodspeed
Previous "read N of M bytes" wording implied that the child had M bytes to send, but we only read N of them. In reality we have no idea how many bytes the child is trying to send, only how many the OS is willing to deliver at this moment. To me, "filled N of M bytes" more clearly implies that M is the buffer size.
2012-03-01Log better error message in case of apr_proc_create() failure.Nat Goodspeed
We were using uniform macro to report the APR function and its C++ parameter expressions. But specifically for apr_proc_create() failure, better to report the command we're attempting to execute.
2012-02-29When constructing a pipe to child stdin on Posix, ignore SIGPIPE.Nat Goodspeed
We can't count on every child process reading everything we try to write to it. And if the child terminates with WritePipe data still pending, unless we explicitly suppress it, Posix will hit us with SIGPIPE. That would terminate the calling process, boom. "Ignoring" it means APR gets the correct errno, passes it back to us, we log it, etc.
2012-02-29Guarantee LLProcess::Params::postend listener any ReadPipe data.Nat Goodspeed
Previously one might get process-terminated notification but still have to wait for the child process's final data to arrive on one or more ReadPipes. That required complex consumer timing logic to handle incomplete pending ReadPipe data, e.g. a partial last line with no terminating newline. New code guarantees that by the time LLProcess sends process-terminated notification, all pending pipe data will have been buffered in ReadPipes. Document LLProcess::ReadPipe::getPump() notification event; add "eof" key. Add LLProcess::ReadPipe::getline() and read() convenience methods. Add static LLProcess::getline() and basename() convenience methods, publishing logic already present elsewhere. Use ReadPipe::getline() and read() in unit tests. Add unit test for "eof" event on ReadPipe::getPump(). Add unit test verifying that final data have been buffered by termination notification event.
2012-02-23Tighten up LLProcess pipe support, per Richard's code review.Nat Goodspeed
Clarify wording in some of the doc comments; be a bit more explicit about some of the parameter fields. Make some query methods 'const'. Change default LLProcess::ReadPipe::getLimit() value to 0: don't post any incoming data with notification event unless caller requests it. But do post pertinent FILESLOT in case caller reuses same listener for both stdout and stderr. Use more idiomatic, readable syntax for accessing LLProcess::Params data.
2012-02-20Let LLProcess consumer specify desired description for logging.Nat Goodspeed
If caller runs (e.g.) a Python script, it's not very helpful to a human log reader to keep seeing LLProcess instances logged as /pathname/to/python (pid). If caller is aware, the code can at least use the script name as the desc -- or maybe even a hint as to the script's purpose. If caller doesn't explicitly pass a desc, at least shorten to just the basename of the executable.
2012-02-20Make LLProcess post termination event to specified pump if desired.Nat Goodspeed
This way a caller need not spin on isRunning(); we can just listen for the requested termination event. Post a similar event containing error message if for any reason LLProcess::create() failed to launch the child. Add unit tests for both cases.
2012-02-18Fix subtle bug in ReadPipeImpl: wouldn't tolerate multiple instances.Nat Goodspeed
That is, trying to instantiate a ReadPipeImpl while another already existed would throw an LLEventPump::DupPumpName exception. Fortunately this behavior is easily bypassed.
2012-02-16Fix bug in LLProcess::ReadPipe::peek() substring computation.Nat Goodspeed
Add unit tests for peek() with substring args, reimplemented contains(), various forms of find(). (yay unit tests)
2012-02-16Add LLProcess::ReadPipe::find() methods, with corresponding npos.Nat Goodspeed
If it's useful to have contains() to tell you whether incoming data contains a particular substring, and if it's useful for contains() and peek() to accept an offset within that data, then it's useful to allow you to get the offset of a desired substring within that data. But of course a find() returning offset needs something like std::string::npos for "not found"; borrow that convention. Support both find(const std::string&) and find(char); the latter permits a more efficient implementation. In fact, make find(string) recognize a string of length 1 and leverage the find(char) implementation. Given that, reimplement contains(mumble) as shorthand for find(mumble) != npos. Implement find() overloads using std::search() and std::find() on boost::asio::streambuf character iterators, rather than copying to std::string and then using string search like previous contains() implementation. Reimplement WritePipeImpl::tick() and ReadPipeImpl::tick() to write/read directly from/to boost::asio::streambuf data, instead of copying to/from a temporary flat buffer. As long as ReadPipeImpl::tick() keeps successfully filling buffers, keep reading. Previous implementation would only handle a long child write over successive tick() calls. Stop on read error or when we come up short.
2012-02-15Add LLProcess::ReadPipe::size(), peek(), contains().Nat Goodspeed
Also add "len" key to event data on LLProcess::getPump(). If you've used setLimit(), event["data"].length() may not reflect the length of the accumulated data in the ReadPipe. Add unit test with stdin/stdout handshake with child process.
2012-02-15VS2010 doesn't know how to compute min(4096, size_t) :-PNat Goodspeed
2012-02-15Preliminary pipe support for LLProcess.Nat Goodspeed
Add LLProcess::FileParam to specify how to construct each child's standard file slot, with lots of comments about features designed but not yet implemented. The point is to design it with enough flexibility to be able to extend to foreseeable use cases. Add LLProcess::Params::files to collect up to 3 FileParam items. Naturally this extends the accepted LLSD syntax as well. Implement type="" (child inherits parent file descriptor) and "pipe" (parent constructs anonymous pipe to pass to child). Add LLProcess::FILESLOT enum, plus methods: getReadPipe(FILESLOT), getOptReadPipe(FILESLOT) getWritePipe(), getOptWritePipe() getPipeName(FILESLOT): placeholder implementation for now Add LLProcess::ReadPipe and WritePipe classes, as returned by get*Pipe(). WritePipe supports get_ostream() method for streaming to child stdin. ReadPipe supports get_istream() method for reading from child stdout/stderr. It also provides getPump() returning LLEventPump& so interested parties can listen for arrival of new data on the aforementioned std::istream. For "pipe" slots, instantiate appropriate *Pipe class. ReadPipe and WritePipe classes are pure virtual bases for ReadPipeImpl and WritePipeImpl, respectively: all implementation data are hidden in the latter classes, visible only in llprocess.cpp. In fact each *PipeImpl class registers itself for "mainloop" ticks, attempting nonblocking I/O to the underlying apr_file_t on each tick. Data are buffered in a boost::asio::streambuf, which bridges between std::[io]stream and the APR I/O calls. Sanity-test ReadPipeImpl by using a pipe to absorb the Python "SyntaxError" output from the successful syntax_error test, rather than alarming the user. Add first few unit tests for validating FileParam. More tests coming!
2012-02-13Use per-frame ticks on "mainloop" LLEventPump to update LLProcess.Nat Goodspeed
When we reimplemented LLProcess on APR, necessitating APR's funny callback mechanism to sense child-process status, every isRunning() or getStatus() call called the APR poll function that calls ALL registered LLProcess callbacks. In other words, every time any consumer called any LLProcess::isRunning() method, all LLProcess callbacks were redundantly fired. Change that so that the single APR poll function is called once per frame, courtesy of the "mainloop" LLEventPump. Once per viewer frame should be well within the realtime duration in which it's reasonable to expect child-process status to change. In effect, this changes LLProcess's public API to introduce a dependency on "mainloop" ticks. Add such ticks to llprocess_test.cpp as well.
2012-02-13Suppress a specific unused-var warning on Posix platforms.Nat Goodspeed
2012-02-09Remove LLJob class: apr_procattr_autokill_set() should now handle.Nat Goodspeed
LLJob was vestigial code from before migrating Job Object support into APR. Also add APR signal-name string to getStatusString() output.
2012-02-07LLProcess::Status enum values need qualification in helper function.Nat Goodspeed
2012-02-07Convert LLProcess implementation from platform-specific to using APR.Nat Goodspeed
Include logic to engage Linden apr_procattr_autokill_set() extension: on Windows, magic CreateProcess() flag must be pushed down into apr_proc_create() level. When using an APR package without that extension, present implementation should lock (e.g.) SLVoice.exe lifespan to viewer's on Windows XP but probably won't on Windows 7: need magic flag on CreateProcess(). Using APR child-termination callback requires us to define state (e.g. LLProcess::RUNNING). Take the opportunity to present Status, capturing state and (if terminated) rc or signal number; but since most of the time all caller really wants is to log the outcome, also present status string, encapsulating logic to examine state and describe exited-with-rc vs. killed-by-signal. New Status logic may report clearer results in the case of a Windows child process killed by exception. Clarify that static LLProcess::isRunning(handle) overload is only for use when the original LLProcess object has been destroyed: really only for unit tests. We necessarily retain our original platform-specific implementations for just that one method. (Nonstatic isRunning() no longer calls static method.) Clarify log output from llprocess_test.cpp in a couple places.
2012-01-30Set bit flag on CreateProcess() to allow AssignProcessToJobObject().Nat Goodspeed
Windows 7 and friends tend to create a process already implicitly allocated to a job object, and a process can only belong to a single job object. Passing CREATE_BREAKAWAY_FROM_JOB in CreateProcessA()'s dwCreationFlags seems to bypass the access-denied error observed with AssignProcessToJobObject() otherwise. This change should (!) enable OS lifespan management for SLVoice.exe et al.
2012-01-30LLProcess::handle must be qualified when used in LLJob class.Nat Goodspeed
2012-01-30Expose 'handle' as well as 'id' on LLProcess objects.Nat Goodspeed
On Posix, these and the corresponding getProcessID()/getProcessHandle() accessors produce the same pid_t value; but on Windows, it's useful to distinguish an int-like 'id' useful to human log readers versus an opaque 'handle' for passing to platform-specific API functions. So make the distinction in a platform-independent way.
2012-01-30Trim trailing "\r\n" from Windows FormatMessage() string for logging.Nat Goodspeed
2012-01-27On Windows, only quote LLProcess arguments if they seem to need it.Nat Goodspeed
On Posix platforms, the OS argument mechanism makes quoting/reparsing unnecessary anyway, so this only affects Windows. Add optional 'triggers' parameter to LLStringUtils::quote() (default: space and double-quote). Only if the passed string contains a character in 'triggers' will it be double-quoted. This is observed to fix a Windows-specific problem in which plugin child process would fail to start because it wasn't expecting a quoted number. Use LLStringUtils::quote() more consistently in LLProcess implementation for logging.
2012-01-23Per Richard: close unusable Job Object; move quote() to LLStringUtil.Nat Goodspeed
If LLProcess can't set the right flag on a Windows Job Object, the object isn't useful to us, so we might as well discard it. quote() is sufficiently general that it belongs in LLStringUtil instead of buried as a static helper function in llprocess.cpp.
2012-01-22Every singleton needs a friend...Nat Goodspeed
2012-01-22Add LLProcess logging on launch(), kill(), isRunning().Nat Goodspeed
Much as I dislike viewer log spam, seems to me starting a child process, killing it and observing its termination are noteworthy events. New logging makes LLExternalEditor launch message redundant; removed.
2012-01-22Make LLProcess::Params streamable; use that in LLExternalEditor.Nat Goodspeed
2012-01-22On Windows, introduce viewer Job Object and assign children to it.Nat Goodspeed
The idea is that, with the right flag settings, this will cause the OS to terminate remaining viewer child processes when the viewer terminates -- whether or not it terminates intentionally. Of course, if LLProcess's caller specifies autokill=false, e.g. to run the viewer updater, that asserts that we WANT the child to persist beyond the viewer session itself.
2012-01-20Define LLProcess::Params; accept create(const LLSDParamAdapter<Params>&).Nat Goodspeed
This allows callers to pass either LLSD formatted as before -- which all callers still do -- or an actual LLProcess::Params block.
2012-01-20Per Richard, replace LLProcessLauncher with LLProcess.Nat Goodspeed
LLProcessLauncher had the somewhat fuzzy mandate of (1) accumulating parameters with which to launch a child process and (2) sometimes tracking the lifespan of the ensuing child process. But a valid LLProcessLauncher object might or might not have ever been associated with an actual child process. LLProcess specifically tracks a child process. In effect, it's a fairly thin wrapper around a process HANDLE (on Windows) or pid_t (elsewhere), with lifespan management thrown in. A static LLProcess::create() method launches a new child; create() accepts an LLSD bundle with child parameters. So building up a parameter bundle is deferred to LLSD rather than conflated with the process management object. Reconcile all known LLProcessLauncher consumers in the viewer code base, notably the class unit tests.