1. simon_linden
  2. viewer-rabbit

Commits

Author Commit Message Date Builds
nat_linden
Introduce LLLeapListener, associating one with each LLLeap object. Every LEAP plugin gets its own LLLeapListener, managing its own collection of listeners to various LLEventPumps. LLLeapListener's command LLEventPump now has a UUID for a name, both for uniqueness and to make it tough for a plugin to mess with any other.
nat_linden
Make LLLeap intercept LL_ERRS termination and notify LEAP plugin. Have to pump "mainloop" a few times to flush the buffer to the pipe, a potentially risky strategy: we have to trust that whatever condition led to the LL_ERRS fatal error didn't break anything that listens on "mainloop". But the worst that could happen is that the plugin won't be notified -- just as if we didn't try in the first place. In other words, no harm in trying.
nat_linden
Promote LLProcess::ReadPipe::size() to BasePipe (hence WritePipe). Certain use cases need to know whether the WritePipe buffer has been flushed to the pipe, or is still pending.
nat_linden
On Windows, make "very large message" test ridiculously small. This test must not be subject to spurious environmental failures, else some kind soul will disable it entirely. We observe that APR specifies a hard-coded buffer size of 64Kbytes for pipe creation -- use that and cross fingers.
nat_linden
Explicitly clean up all LLLeap instances during viewer shutdown. This code replaces the previous cleanup of DLLs loaded by APR.
nat_linden
Fix --leap assumption that LeapCommand setting is ALWAYS an array. Nuance of command-line processing: when there's exactly one --leap switch, the resulting LLSD is a scalar string rather than an array with one entry. Fix processing code to handle either case.
nat_linden
Add --leap command-line switch to launch one or more LEAP plugins. You can specify one or more instances of --leap 'command line'. Each such command line is parsed using bash-like conventions, notably honoring double quotes, e.g. --leap '"c:/Program Files/Something/something.exe" arg1 arg2'. (Specifying such an argument in a Windows Command Prompt may be tricky.) Such a program should read its stdin and write to its stdout using LLSD Event API Plugin protocol: le…
nat_linden
Commit merge of reinstating Windows APR pipe write bug fix.
nat_linden
Backed out changeset 22664c76b59e (reinstate Windows pipe workaround) Sigh, the rejoicing was premature.
nat_linden
Commit merge of backout of Windows APR pipe write bug workaround.
nat_linden
Backed out changeset 51205a909e2c (Windows APR pipe bug workaround) If in fact we've managed to fix the APR bug writing to a Windows named pipe, it should no longer be necessary to try to work around it by testing with a much smaller data volume on Windows!
nat_linden
Try new 20120314 APR build to verify Windows pipe write bug fix.
nat_linden
On Windows, try cutting down the size of a "very large message." Ideally we'd love to be able to nail the underlying bug, but log output suggests it may actually go all the way down to the OS level. To move forward, try to bypass it.
nat_linden
If very-large-message test fails, search for a size that works. We want to write a robust test that consistently works. On Windows, that appears to require constraining the max message size. I, the coder, could try submitting test runs of varying sizes to TC until I found a size that works... but that could take quite a while. If I were clever, I might even use a manual binary search. But computers are good at binary searching; there are even prepackaged algor…
nat_linden
Protect LLProcess destructor when run after APR shutdown. 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…
nat_linden
Increase timeout for very-large-message test. Apparently, at least on Mac, there are circumstances in which the very-large- message test can take several times longer than normal, yet still complete successfully. This is always the problem with timeouts: does timeout expiration mean that the code in question is actually hung, or would it complete if given a bit longer? If very-large-message test fails, retry a few times with smaller sizes to …
nat_linden
Add timeout functionality to waitfor() helper functions. Otherwise, a stuck child process could potentially hang the test, and thus the whole viewer build.
nat_linden
Normalize LLErrorThread::run() loop exit condition.
nat_linden
For a test program killed by signal, display signal name.
nat_linden
nat_linden
Alphabetize cmd_line.xml. This separate commit is just to order the keys. Data are unchanged, as established by: $ hg cat -rtip cmd_line.xml >cmd_line.xml.tip $ python Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from llbase import llsd >>> tipdata = llsd.parse(open("…
nat_linden
Further reduce the block size that LLProcess writes to child pipe. 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.
nat_linden
Additional diagnostic code to track down strange Windows pipe error. It seems that under certain circumstances, write logic was duplicating a chunk of the data being streamed down our pipe. But as this condition is only driven with a very large data stream, eyeballing that data stream is tedious. Add code to compare the raw received data with the expected stream, reporting where and how they first differ.
nat_linden
Introduce (disabled) LLLeap debugging code to validate stdin writes. While debugging mysterious problem on Windows, one potential failure mode to rule out was the possibility that streaming std::ostringstream << LLSDNotationStreamer(large_LLSD) might itself cause trouble -- even before attempting to write to the LLProcess::WritePipe. The debugging code validated that the correct length is being reported, and that deserializing the resulting buffer produces equivale…
nat_linden
Make test.cpp support LOGFAIL env var: only failed tests show log. Set LOGFAIL= one of ALL, DEBUG, INFO, WARN, ERROR, NONE. A passing test will run silently, as now; but a failing test will replay log output at the specified level or higher. While at it, support LOGTEST environment variable, same values. This is like setting --debug (or -d), but allows specifying an arbitrary level -- and, unlike --debug, can be set for a TeamCity build config without modifying a…
nat_linden
Move std::ostream << CaptureLog logic into CaptureLog::streamto(). That lets us reliably declare the operator<<() free function inline, which permits multiple translation units in the same executable to #include "wrapllerrs.h".
nat_linden
Simplify llleap_test.cpp plugin by reading individual characters. While we're accumulating the 'length:' prefix, the present socket-based logic reads 20 characters, then reads 'length' more, then discards any excess (in case the whole 'length:data' packet ends up being less than 20 characters). That's probably a bug: whatever characters follow that packet, however short it may be, are probably the 'length:' prefix of the next packet. We probably only get away wi…
nat_linden
Make llleap_test.cpp avoid hard limit on MSVC std::ostringstream max. In load testing, we have observed intermittent failures on Windows in which LLSDNotationStreamer into std::ostringstream seems to bump into a hard limit of 1048590 bytes. ostringstream reports that much buffered data and returns that much -- even though, on examination, the notation-serialized stream is incomplete at that point. It's our intention to load-test LLLeap and LLProcess, not the local i…
nat_linden
Break large buffer into chunks to write to LLProcess child pipe. 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.
nat_linden
Add debugging output in case LLLeap writes corrupt data to plugin. New llleap_test.cpp load testing turned up Windows issue in which plugin process received corrupt packet, producing LLSDParseError. Add code to dump the bad packet in that case -- but if LLSDParseError is willing to state the offset of the problem, not ALL of the packet. Quiet MSVC warning about little internal base class needing virtual destructor.
  1. Prev
  2. Next