Closed Bug 1277943 Opened 3 years ago Closed 3 years ago

Debug Thread of nsSocketTransportService::DebugMutexAutoLock not threadsafe

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
48 Branch
Type:
defect
Priority:
Not set

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla49
Tracking Flags:
Tracking Status
firefox49 --- fixed

People

(Reporter: mcmanus, Assigned: mcmanus)

References

Details

(Whiteboard: [necko-active])

Attachments

(1 file)

atomic fix to sockettransport::debugautomutex
7.73 KB, patch
u408661
: review+
Details | Diff | Splinter Review 
over in 1152048 we were looking for cases where the socketthread lock was obtained re-entrantly by adding a DIAGNOSTIC_ASSERT.. and we found and fixed one in the ~42 era.

Unfortunately there are a few crashes from that DIAGNOSTIC_ASSERT (which only happens on nighty/aurora) still hanging around in current builds that don't seem related to recursive locking.

This one is from 48 https://crash-stats.mozilla.com/report/index/270eb52d-4d51-40ac-8cfd-d4bb42160526#allthreads

everything in that stack trace looks fine to me.

however, the debug thread member variable is defined as relaxed - which provides no memory ordering guarnatees.
    static Atomic<PRThread *, Relaxed> sDebugOwningThread;

based on the fact that I don't see crashes of the flavor we are looking for, and this is a red herring I am posting a patch that removes the AutoLock wrapper and just returns it to a straight autolock.
Assignee: nobody → mcmanus
Whiteboard: [necko-active]
Attachment #8759817 - Flags: review?(hurley) → review+
https://hg.mozilla.org/mozilla-central/rev/f457175b1c4f
Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.