1. 21 Dec, 2018 10 commits
  2. 19 Dec, 2018 4 commits
  3. 18 Dec, 2018 8 commits
  4. 17 Dec, 2018 1 commit
  5. 16 Dec, 2018 2 commits
  6. 15 Dec, 2018 5 commits
  7. 14 Dec, 2018 3 commits
  8. 13 Dec, 2018 2 commits
    • Lioncash's avatar
      audio_core: Make g_sink_details internally linked · 6beb823f
      Lioncash authored
      We can hide the direct array from external view and instead provide
      functions to retrieve the necessary info. This has the benefit of
      completely hiding the makeup of the SinkDetails structure from the rest
      of the code.
      
      Given that this makes the array hidden, we can also make the array
      constexpr by altering the members slightly. This gets rid of several
      static constructor calls related to std::vector and std::function.
      
      Now we don't have heap allocations here that need to occur before the
      program can even enter main(). It also has the benefit of saving a
      little bit of heap space, but this doesn't matter too much, since the
      savings in that regard are pretty tiny.
      6beb823f
    • Jens Schmer's avatar
      Fix Service object leak on emulation stop · 27a9cc2e
      Jens Schmer authored
      Services created with the ServiceFramework base class install themselves as HleHandlers with an owning shared_ptr in the ServerPort ServiceFrameworkBase::port member variable, creating a cyclic ownership between ServiceFrameworkBase and the ServerPort, preventing deletion of the service objects.
      
      Fix that by removing the ServiceFrameworkBase::port member because that was only used to detect multiple attempts at installing a port. Instead store a flag if the port was already installed to achieve the same functionality.
      27a9cc2e
  9. 12 Dec, 2018 5 commits
    • Mat M's avatar
      Merge pull request #1890 from jschmer/master · 700075be
      Mat M authored
      Fix Process object leak on emulation stop
      700075be
    • Lioncash's avatar
      svc: Enable svcQueryProcessMemory · b79f0866
      Lioncash authored
      svcQueryProcessMemory is trivial to implement, given all the behavior
      necessary for it is present, it just needs a handler for it.
      b79f0866
    • Lioncash's avatar
      svc: Write out the complete MemoryInfo structure in QueryProcessMemory · 09a219d5
      Lioncash authored
      In the previous change, the memory writing was moved into the service
      function itself, however it still had a problem, in that the entire
      MemoryInfo structure wasn't being written out, only the first 32 bytes
      of it were being written out. We still need to write out the trailing
      two reference count members and zero out the padding bits.
      
      Not doing this can result in wrong behavior in userland code in the following
      scenario:
      
      MemoryInfo info;                 // Put on the stack, not quaranteed to be zeroed out.
      svcQueryMemory(&info, ...);
      
      if (info.device_refcount == ...) // Whoops, uninitialized read.
      
      This can also cause the wrong thing to happen if the user code uses
      std::memcmp to compare the struct, with another one (questionable, but
      allowed), as the padding bits are not guaranteed to be a deterministic
      value. Note that the kernel itself also fully zeroes out the structure
      before writing it out including the padding bits.
      09a219d5
    • Lioncash's avatar
      svc: Handle memory writing explicitly within QueryProcessMemory · d8deb39b
      Lioncash authored
      Moves the memory writes directly into QueryProcessMemory instead of
      letting the wrapper function do it. It would be inaccurate to allow the
      handler to do it because there's cases where memory shouldn't even be
      written to. For example, if the given process handle is invalid.
      
      HOWEVER, if the memory writing is within the wrapper, then we have no
      control over if these memory writes occur, meaning in an error case, 68
      bytes of memory randomly get trashed with zeroes, 64 of those being
      written to wherever the memory info address points to, and the remaining
      4 being written wherever the page info address points to.
      
      One solution in this case would be to just conditionally check within
      the handler itself, but this is kind of smelly, given the handler
      shouldn't be performing conditional behavior itself, it's a behavior of
      the managed function. In other words, if you remove the handler from the
      equation entirely, does the function still retain its proper behavior?
      In this case, no.
      
      Now, we don't potentially trash memory from this function if an invalid
      query is performed.
      d8deb39b
    • Lioncash's avatar
      vm_manager: Correct ordering of last two struct members of MemoryInfo · b1b855c5
      Lioncash authored
      These should be swapped.
      b1b855c5