1. 13 Apr, 2017 1 commit
    • maxmorin's avatar
      Fix double close in MojoAudioOutputStream. · d4bcb119
      maxmorin authored
      Currently, the sync socket in MojoAudioOutputStream is closed by both
      Mojo and the SyncSocket destructor. This causes problems if a handle
      happens to be reused.
      
      BUG=709394
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
      
      Review-Url: https://codereview.chromium.org/2809673002
      Cr-Commit-Position: refs/heads/master@{#464374}
      d4bcb119
  2. 08 Jun, 2016 1 commit
  3. 26 Dec, 2015 1 commit
  4. 24 Nov, 2015 1 commit
  5. 22 Sep, 2015 1 commit
  6. 18 Sep, 2015 1 commit
    • brucedawson's avatar
      Revert of Check for CloseHandle failures even when not debugging (patchset #4... · d350943f
      brucedawson authored
      Revert of Check for CloseHandle failures even when not debugging (patchset #4 id:60001 of https://codereview.chromium.org/1350493002/ )
      
      Reason for revert:
      The SharedMemory checks are causing CHECK crashes in the printing system. See bug 533310. Reverting to allow time for an investigation of that underlying problem.
      
      Original issue's description:
      > Check for CloseHandle failures even when not debugging
      >
      > Bug 524267 was a handle closing failure that only showed up when running
      > renderer processes under a debugger at startup, so it was not discovered
      > for a while.
      >
      > Similarly, bug 520305 is a long-standing base_unittests bug that only
      > shows up under a debugger.
      >
      > This change fixes 520305 and checks for many handle closing failures
      > always so that subsequent bugs of this type will be detected
      > immediately.
      >
      > Most of the CloseHandle calls in base are now checked.
      >
      > This replaces the uncommitted https://codereview.chromium.org/1343873002/
      >
      > R=grt@chromium.org,rvargas@chromium.org,dalecurtis@chromium.org
      > BUG=524267,520305
      >
      > Committed: https://crrev.com/9ae49a753d07f5a9266a63a89e7336d774f3fe37
      > Cr-Commit-Position: refs/heads/master@{#349333}
      
      TBR=dalecurtis@chromium.org,grt@chromium.org,rvargas@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=524267,520305
      
      Review URL: https://codereview.chromium.org/1356743003
      
      Cr-Commit-Position: refs/heads/master@{#349716}
      d350943f
  7. 17 Sep, 2015 1 commit
    • brucedawson's avatar
      Check for CloseHandle failures even when not debugging · 9ae49a75
      brucedawson authored
      Bug 524267 was a handle closing failure that only showed up when running
      renderer processes under a debugger at startup, so it was not discovered
      for a while.
      
      Similarly, bug 520305 is a long-standing base_unittests bug that only
      shows up under a debugger.
      
      This change fixes 520305 and checks for many handle closing failures
      always so that subsequent bugs of this type will be detected
      immediately.
      
      Most of the CloseHandle calls in base are now checked.
      
      This replaces the uncommitted https://codereview.chromium.org/1343873002/
      
      R=grt@chromium.org,rvargas@chromium.org,dalecurtis@chromium.org
      BUG=524267,520305
      
      Review URL: https://codereview.chromium.org/1350493002
      
      Cr-Commit-Position: refs/heads/master@{#349333}
      9ae49a75
  8. 16 Oct, 2014 1 commit
  9. 01 Oct, 2014 1 commit
  10. 23 Sep, 2014 1 commit
  11. 16 Sep, 2014 1 commit
  12. 08 Sep, 2014 1 commit
    • burnik's avatar
      Preparing |SyncSocket|'s handle for the peer process is different for POSIX and Windows · 3d670050
      burnik authored
      which leads to code duplication, platform #ifdef checks on multiple levels and
      general confusion on how to work with the SyncSocket.
      
      Typical use case for |SyncSocket|:
      1. Browser creates and connects the socket pair - one for browser and one for renderer.
      2. Browser prepares the foreign socket (Windows duplicates, POSIX creates file descriptor).
      3. Browser relays the foreign socket handle to the renderer via IPC.
      4. Renderer receives the IPC and creates the socket using the handle provided.
      5. Sockets are ready for send/receive on both ends.
      
      Steps 1-4 get simplified since there is no need to check the platform in order to prepare the socket for transit.
      
      What this CL brings:
      1. Adds |SyncSocket::TransitDescriptor| type which wraps the socket handle and is cross-platform.
      2. Adds |SyncSocket::PrepareTransitDescriptor| method which is implemented depending on the platform.
      3. Adds |SyncSocket::UnwrapHandle| method which unwraps |SyncSocket::Handle| from |SyncSocket::TransitDescriptor|.
      4. Removes #ifdefs for platform-checks in code using |SyncSocket| and simplifies preparing the SyncSocket.
      
      Note:
      - There is still some less evident duplication in the ppapi and pepper-broker code which should be addressed.
      - SyncSocket unit test should also be reviewed.
      - There is a similar pattern when using SharedMemory.
      
      BUG=409656
      
      Review URL: https://codereview.chromium.org/525313002
      
      Cr-Commit-Position: refs/heads/master@{#293680}
      3d670050
  13. 19 Oct, 2013 1 commit
  14. 23 May, 2013 1 commit
  15. 19 Apr, 2012 1 commit
    • xians@chromium.org's avatar
      Revert revert 132842 · 5d272095
      xians@chromium.org authored
      If we are using blocking write, when the renderer stop getting the data without notifying the browser, it will hang the browser. This happens with some plugins which use the sync sockets provided by the Pepper.
      This patch change CancellableSyncSocket to be non-blocking on sending, so that we don't need to worry the whole browser hangs by one plugin application.
      
      Also, we remove the lock in audio_sync_reader.cc since it is not really needed if we don't set the socket_ to NULL when calling Close(). By doing this we allow the user to close the socket while another thread is writing to the socket.
      
      BUG=121152
      TEST=ipc_tests
      
      TBR=tommi@chromium.org
      
      Review URL: https://chromiumcodereview.appspot.com/10124004
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@132975 0039d316-1c4b-4281-b951-d872f2087c98
      5d272095
  16. 18 Apr, 2012 2 commits
  17. 03 Feb, 2012 1 commit
  18. 25 Jan, 2012 1 commit
    • tommi@chromium.org's avatar
      Implement support for a cancelable SyncSocket. · 532e9bd6
      tommi@chromium.org authored
      Currently, blocking SyncSocket operations can not be unblocked from other threads, but this is now supported by using the CancelableSyncSocket class.
      
      The implementation on Mac and Linux is very simple and basically consists of adding a call to shutdown().
      
      On Windows however things are a tiny bit more complex since we use named pipes with synchronous IO and canceling synchronous IO is simply not possible on XP and arguably tricky on Vista+.  So, what we do instead is to use asynchronous IO in a synchronous fashion to support the SyncSocket semantics and as well as allowing the connection to be correctly shut down from another thread.
      
      Review URL: https://chromiumcodereview.appspot.com/8965053
      
      git-svn-id: svn://svn.chromium.org/chrome/trunk/src@119051 0039d316-1c4b-4281-b951-d872f2087c98
      532e9bd6
  19. 19 Jan, 2012 1 commit
  20. 22 Dec, 2011 1 commit
  21. 19 Jul, 2011 1 commit
  22. 22 Apr, 2011 1 commit
  23. 06 Aug, 2010 1 commit
  24. 04 Dec, 2009 1 commit
  25. 24 Nov, 2009 1 commit