Windows file lock is tied to a file handle - using handle duplication effectively applies locking on duplicated handle, not on original, so your original handle will be blocked on IO trying to read/write. Maybe we can just eliminate CloseHandle call ( https://github.com/llvm-mirror/lldb/blob/master/source/Host/windows/LockFileWindows.cpp#L50) if file will be eventually closed by LockFileWindows caller.
On Thu, May 21, 2015 at 9:58 AM, Zachary Turner <ztur...@google.com> wrote: > I don't experience this crash but looking at the proposed fix it certainly > seems like a plausible explanation. Seems to me like something should > transfer ownership though rather than duplicating the handle > > On Thu, May 21, 2015 at 9:52 AM Colin Riley <co...@codeplay.com> wrote: > >> Windows 7 64, Debug, latest vs13. >> >> >> On 21/05/2015 17:39, Oleksiy Vyalov wrote: >> >> Hi Colin, >> >> could you give more context about crash - what build configuration do >> you use (debug, release,..) and which OS? >> I'm running this code on Windows 7 and haven't noticed any failures. >> >> >> On Thu, May 21, 2015 at 8:57 AM, Colin Riley <co...@codeplay.com> wrote: >> >>> >>> Zachary, do you see this on windows at all? Tip for us results in >>> crashes when releasing file descriptors without the below fix. >>> >>> Colin >>> >>> >>> On 19/05/2015 12:52, Aidan Dodds wrote: >>> >>> Hi, >>> >>> We have been seeing a crash on windows when connecting to an android >>> target using lldb-server. >>> I am not sure if this affects other platforms too. >>> I think this was introduced with http://reviews.llvm.org/D9056. >>> >>> I tracked the crash back to the workings of ModuleCache::GetAndPut(). >>> >>> The crash seems to be due to a file descriptor being released twice, >>> once by the original "File lock_file" and again by the "LockFile lock" who >>> share the same file descriptor. >>> >>> The file descriptor sharing happens because of this line: >>> ModuleCache.cpp @ 164 >>> LockFile lock (lock_file.GetDescriptor ()); >>> >>> Both destructors attempt to release effectively the same file >>> descriptor. I was able to fix the crash by duplicating the file handle in >>> the lock file constructor using _dup(). (patch attached) >>> I wasn't sure if this was the right fix however. Has anyone else seen >>> this? >>> Should "File lock_file" perhaps transfer its file descriptor completely >>> rather then share it? >>> >>> Thanks, >>> Aidan >>> >>> >>> _______________________________________________ >>> lldb-dev mailing >>> listlldb-...@cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >>> -- >>> - Colin Riley >>> Senior Director, >>> Parallel/Graphics Debugger Systems >>> >>> Codeplay Software Ltd >>> 45 York Place, Edinburgh, EH1 3HP >>> Tel: 0131 466 0503 >>> Fax: 0131 557 6600 >>> Website: http://www.codeplay.com >>> Twitter: https://twitter.com/codeplaysoft >>> >>> This email and any attachments may contain confidential and /or privileged >>> information and is for use by the addressee only. If you are not the >>> intended recipient, please notify Codeplay Software Ltd immediately and >>> delete the message from your computer. You may not copy or forward it,or >>> use or disclose its contents to any other person. Any views or other >>> information in this message which do not relate to our business are not >>> authorized by Codeplay software Ltd, nor does this message form part of any >>> contract unless so stated. >>> As internet communications are capable of data corruption Codeplay Software >>> Ltd does not accept any responsibility for any changes made to this message >>> after it was sent. Please note that Codeplay Software Ltd does not accept >>> any liability or responsibility for viruses and it is your responsibility >>> to scan any attachments. >>> Company registered in England and Wales, number: 04567874 >>> Registered office: 81 Linkfield Street, Redhill RH1 6BY >>> >>> >> >> >> -- >> Oleksiy Vyalov | Software Engineer | ovya...@google.com >> >> >> -- >> - Colin Riley >> Senior Director, >> Parallel/Graphics Debugger Systems >> >> Codeplay Software Ltd >> 45 York Place, Edinburgh, EH1 3HP >> Tel: 0131 466 0503 >> Fax: 0131 557 6600 >> Website: http://www.codeplay.com >> Twitter: https://twitter.com/codeplaysoft >> >> This email and any attachments may contain confidential and /or privileged >> information and is for use by the addressee only. If you are not the >> intended recipient, please notify Codeplay Software Ltd immediately and >> delete the message from your computer. You may not copy or forward it,or use >> or disclose its contents to any other person. Any views or other information >> in this message which do not relate to our business are not authorized by >> Codeplay software Ltd, nor does this message form part of any contract >> unless so stated. >> As internet communications are capable of data corruption Codeplay Software >> Ltd does not accept any responsibility for any changes made to this message >> after it was sent. Please note that Codeplay Software Ltd does not accept >> any liability or responsibility for viruses and it is your responsibility to >> scan any attachments. >> Company registered in England and Wales, number: 04567874 >> Registered office: 81 Linkfield Street, Redhill RH1 6BY >> >> -- Oleksiy Vyalov | Software Engineer | ovya...@google.com
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
