summaryrefslogtreecommitdiff
path: root/indra/llcorehttp/tests/test_bufferarray.hpp
AgeCommit message (Collapse)Author
2020-03-25DRTVWR-476: Remove special llcorehttp test memory manager.Nat Goodspeed
NickyD discovered that the substitute default allocator used for llcorehttp tests was returning badly-aligned storage, which caused access violations on alignment-sensitive data such as std::atomic. Thanks Nicky!! Moreover, the llcorehttp test assertions regarding memory usage, well- intentioned though they are, have been causing us trouble for years. Many have already been disabled. The problem is that use of test_allocator.h affected *everything* defined with that header file's declarations visible. That inevitably included specific functions in other subsystems. Those functions then (unintentionally) consumed the special allocator, throwing off the memory tracking and making certain memory-related assertions consistently fail. This is a particular, observable bad effect of One Definition Rule violations. Within a given program, C++ allows multiple definitions for the same entity, but requires that all such definitions be the same. Partial visibility of the global operator new() and operator delete() overrides meant that some definitions of certain entities used the default global allocator, some used llcorehttp's. There may have been other, more subtle bad effects of these ODR violations. If one wanted to reimplement verification of the memory consumption of llcorehttp classes: * Each llcorehttp class (for which memory tracking was desired) should declare class-specific operator new() and operator delete() methods. Naturally, these would all consume a central llcorehttp-specific allocator, but that allocator should *not* be named global operator new(). * Presumably that would require runtime indirection to allow using the default allocator in production while substituting the special allocator for tests. * Recording and verifying the memory consumption in each test should be performed in the test-object constructor and destructor, rather than being sprinkled throughout the test<n>() methods. * With that mechanism in place, the test object should provide methods to adjust (or entirely disable) memory verification for a particular test. * The test object should also provide a "yes, we're still consuming llcorehttp memory" method to be used for spot checks in the middle of tests -- instead of sprinkling in explicit comparisons as before. * In fact, the llcorehttp test object in each test_*.hpp file should be derived from a central llcorehttp test-object base class providing those methods.
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2012-06-21SH-3177 Add streambuf/iostream adapters to BufferArray object.Monty Brandenberg
Initial version that should have enough of the plumbing to produce a working adapter. Memory test is showing 8 bytes held after one of the tests so I'm going to revisit that later. But basic functionality is there going by the unit tests.
2012-06-11Convert BufferArray interfaces to void * (not char *). ↵Monty Brandenberg
HttpRequest::update() honor time limit. Generally, opaque data operations are expected to be over 'void *' and have now converted interfaces to do that. Update() method honors millisecond limit to dwell time. Might want to homologate the millis/uSecs mix later....
2012-06-01Do some work on BufferArray to make it a bit less naive aboutMonty Brandenberg
chunking data. Remove the stateful use of a seek pointer so that shared read is possible (though maybe not interesting).
2012-05-07Build llcorehttp as part of a viewer dependency with unit tests. This requiredMonty Brandenberg
boost::thread and the easiest path to that was to go with the 1.48 Boost release in the 3P tree (eliminating a fork for a modified 1.45 packaging). One unit test, the most important one, is failing in test_httprequest but that can be attended to later. This test issues a GET to http://localhost:2/ and that is hitting the wire but the libcurl plumbing isn't delivering the failure, only the eventual timeout. An unexpected change in behavior.
2012-04-23Okay, imported the core-http library and got it compiling suspiciously easily.Monty Brandenberg
The unit/integration tests don't work yet as I'm still battling cmake/autobuild as usual but first milestone passed.