Current hypothesis from looking at the LocationAPI.dll disassembly is that ```GetLocationFromSession``` relies on an atomic/spinlock to make sure that whatever is going to give it ```ILocationInformation``` objects still exists, but that ```StartLocationSession``` has a single ATL::AtlComPtrAssign that is NOT under that lock, and which could wipe/rewrite that object at an in-opportune time. It's hard to infer the locking from looking at the disassembly, but this matches what David found with memory breakpoints. In any case it seems calling Start/Stop on one thread while another tread is in ```GetLocationForSession``` is bad news. I guess the CLSCTX_ALL avoids that?
Bug 1704500 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Current hypothesis from looking at the LocationAPI.dll disassembly is that ```GetLocationFromSession``` relies on an atomic/spinlock to make sure that whatever is going to give it ```ILocationInformation``` objects still exists, but that ```StartLocationSession``` has a single ```ATL::AtlComPtrAssign``` that is NOT under that lock, and which could wipe/rewrite that object at an in-opportune time. It's hard to infer the locking from looking at the disassembly, but this matches what David found with memory breakpoints. In any case it seems calling Start/Stop on one thread while another tread is in ```GetLocationForSession``` is bad news. I guess the CLSCTX_ALL avoids that?