Skip to content
Snippets Groups Projects
  1. Apr 09, 2020
  2. Mar 25, 2020
    • Nat Goodspeed's avatar
      DRTVWR-476: Disable test_httprequest.hpp on Mac Release builds. · 4174bb36
      Nat Goodspeed authored
      For reasons not yet diagnosed, specifically in Mac Release builds, the tests
      in test_httprequest.hpp consistently crash with a backtrace suggesting that
      the worker thread is calling LLCore::HttpLibcurl::completeRequest() after the
      foreground thread calls HttpRequest::destroyService().
      
      Weirdly, even executing a tut::skip() call in every test<n>() function up to
      the point of the crash does not eliminate the crash.
      4174bb36
    • Nat Goodspeed's avatar
      DRTVWR-476: Remove special llcorehttp test memory manager. · 2902f23a
      Nat Goodspeed authored
      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.
      2902f23a
    • Nat Goodspeed's avatar
      DRTVWR-476: Add LLCOREHTTP_TESTS CMake var, OFF by default on Mac. · c56601bc
      Nat Goodspeed authored
      Hopefully this is temporary until we solve the problem of crashy llcorehttp
      test executable on Mac.
      c56601bc
    • Anchor's avatar
      [DRTVWR-476] - revert · ca66cea7
      Anchor authored
      ca66cea7
    • Anchor's avatar
      [DRTVWR-476] - disable llcorehttp test on mac · cc230eef
      Anchor authored
      cc230eef
    • Anchor's avatar
      201ff48c
    • Anchor's avatar
      [DRTVWR-476] - fix linking · b5bb0794
      Anchor authored
      b5bb0794
    • Nat Goodspeed's avatar
    • Nat Goodspeed's avatar
      DRTVWR-476: Remove throw(T) from operator new(), operator delete(). · 25a65844
      Nat Goodspeed authored
      llcorehttp's test_allocator.{h,cpp} overrides global operator new(), operator
      new[](), operator delete() and operator delete[](). The two operator new()
      functions used to be declared with throw(std::bad_alloc). Worse, for VS 2013
      and previous, we needed _THROW0() and _THROW1(std::bad_alloc) instead,
      requiring #if logic.
      
      But with dynamic throw declarations deprecated, we must actually remove those.
      That obviates the THROW_BAD_ALLOC() / THROW_NOTHING() workarounds in
      test_allocator.cpp.
      25a65844
    • Nat Goodspeed's avatar
      DRTVWR-476: Use OpenSSL API suitable for 64-bit pointers. · 3753dbd5
      Nat Goodspeed authored
      In three different places we use the same pattern: an ssl_thread_id_callback()
      function (a static member of LLCrashLogger, in that case) that used to be
      passed to CRYPTO_set_id_callback() and therefore returned an unsigned long
      representing the ID of the current thread.
      
      But GetCurrentThread() is a HANDLE, an alias for a pointer, and you can't
      uniquely cram a 64-bit pointer into an unsigned long.
      
      Fortunately OpenSSL has a more modern API for retrieving thread ID. Pass
      each ssl_thread_id_callback() function to CRYPTO_THREADID_set_callback()
      instead, converting it to accept CRYPTO_THREADID* and call
      CRYPTO_THREADID_set_pointer() or CRYPTO_THREADID_set_numeric() as appropriate().
      3753dbd5
    • Nat Goodspeed's avatar
      DRTVWR-494: Use std::thread::id for LLThread::currentID(). · 5e7df752
      Nat Goodspeed authored
      LLThread::currentID() used to return a U32, a distinct unsigned value
      incremented by explicitly constructing LLThread or by calling LLThread::
      registerThreadID() early in a thread launched by other means. The latter
      imposed an unobvious requirement on new code based on std::thread. Using
      std::thread::id instead delegates to the compiler/library the problem of
      distinguishing threads launched by any means.
      
      Change lots of explicit U32 declarations. Introduce LLThread::id_t typedef to
      avoid having to run around fixing uses again if we later revisit this decision.
      
      LLMutex, which stores an LLThread::id_t, wants a distinguished value meaning
      NO_THREAD, and had an enum with that name. But as std::thread::id promises
      that the default-constructed value is distinct from every valid value,
      NO_THREAD becomes unnecessary and goes away.
      
      Because LLMutex now stores LLThread::id_t instead of U32, make llmutex.h
      #include "llthread.h" instead of the other way around. This makes LLMutex an
      incomplete type within llthread.h, so move LLThread::lockData() and
      unlockData() to the .cpp file. Similarly, remove llrefcount.h's #include
      "llmutex.h" to break circularity; instead forward-declare LLMutex.
      
      It turns out that a number of source files assumed that #include "llthread.h"
      would get the definition for LLMutex. Sprinkle #include "llmutex.h" as needed.
      
      In the SAFE_SSL code in llcorehttp/httpcommon.cpp, there's an ssl_thread_id()
      callback that returns an unsigned long to the SSL library. When LLThread::
      currentID() was U32, we could simply return that. But std::thread::id is very
      deliberately opaque, and can't be reinterpret_cast to unsigned long.
      Fortunately it can be hashed because std::hash is specialized with that type.
      5e7df752
  3. Oct 23, 2019
  4. Apr 11, 2019
  5. Mar 13, 2019
  6. Mar 12, 2019
  7. Mar 11, 2019
  8. Feb 15, 2019
  9. Feb 08, 2019
  10. Jan 29, 2019
  11. Jan 15, 2019
  12. Jan 14, 2019
  13. Sep 12, 2018
  14. Sep 07, 2018
  15. Sep 05, 2018
  16. Aug 30, 2018
  17. Aug 29, 2018
  18. May 24, 2018
  19. Jun 04, 2018
  20. Jan 18, 2018
  21. Oct 24, 2017
  22. Sep 30, 2017
    • Nat Goodspeed's avatar
      MAINT-7081: Eliminate unused variable errors after new refactoring. · 6b508cd9
      Nat Goodspeed authored
      The new helper functions check_curl_easy_setopt() and
      check_curl_multi_setopt() encapsulate the pervasive idiom:
      
          code = curl_{easy,multi}_setopt(handle, option, arg);
          check_curl_{easy,multi}_code(code, option);
      
      But since each of these helper functions contains its own local CURL{,M}code
      variable 'code', having a caller-scope variable reused for every such call is
      no longer necessary -- in fact is no longer used at all. That produces a fatal
      warning with MSVC. Get rid of those now-unused variables.
      6b508cd9
  23. Sep 29, 2017
  24. Sep 27, 2017
  25. Sep 20, 2017
  26. Aug 15, 2017
  27. Aug 14, 2017
  28. Aug 08, 2017
Loading