Closed Bug 1136969 Opened 11 years ago Closed 11 years ago

Assert that we're not sending OnStartRequest more than once

Categories

(Core :: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox40 --- fixed

People

(Reporter: seth, Assigned: dragana)

References

Details

Attachments

(1 file, 1 obsolete file)

We've seen multiple crashes and assertion failures in ImageLib lately that suggest that OnStartRequest may be getting delivered more than once. Examples are bug 1130607 and bug 1135272. I'm adding checks inside ImageLib for this, but if this theory is correct they're just working around the real issue. I think we'll catch it faster if we assert for this everywhere, not just in ImageLib. It'd be great if we assert that we're not sending duplicate OnStartRequest calls in Necko itself.
this is just a drive-by kibitzing comment. make sure that what you are observing in imageLib isn't the result of a redirect somehow. A single channel should only onStartRequest() you once, but if a redirect was involved you would certainly get multiple channels and onStartRequest()s for the same resource load. I'm certainly fine with the asserts in the channel code :)
I'm not sure that the ImageLib code has been designed consciously with that in mind, unfortunately. I at least had assumed that we only got OnStartRequest after all redirects were complete. I'll audit the code with that in mind. However, at least one of those crashes seems to involve a case where we get OnStartRequest again after OnDataAvailable is delivered. I'm pretty sure that shouldn't be possible except in the multipart/x-mixed-replace case (which wasn't what was happening).
Dragana, can you take this? I think just adding a mOnStartRequest variable and checking it before we call OnStartRequest is the right fix here.
Assignee: nobody → dd.mozilla
Attached patch bug_1136969_v1.patch (obsolete) — Splinter Review
Attachment #8569816 - Flags: review?(jduell.mcbugs)
Jason, it looks like this is waiting on review from you. It'd be awesome if you could look at this soon. This is a big concern for folks working on image and graphics-related crashes.
Flags: needinfo?(jduell.mcbugs)
See Also: → 1148640
It'd be great to get this landed. Evidence keeps mounting that we may be sending OnStartRequest more than once, though I've never been able to get it to happen locally.
Comment on attachment 8569816 [details] [diff] [review] bug_1136969_v1.patch Review of attachment 8569816 [details] [diff] [review]: ----------------------------------------------------------------- ::: netwerk/protocol/http/HttpBaseChannel.h @@ +414,5 @@ > nsCOMPtr<nsIPrincipal> mPrincipal; > > bool mForcePending; > nsCOMPtr<nsIURI> mTopWindowURI; > + mozilla::Atomic<bool> mOnStartRequestCalled; why the atomic? Is non-main thread involved somehow?
(In reply to Patrick McManus [:mcmanus] from comment #8) > Comment on attachment 8569816 [details] [diff] [review] > bug_1136969_v1.patch > > Review of attachment 8569816 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: netwerk/protocol/http/HttpBaseChannel.h > @@ +414,5 @@ > > nsCOMPtr<nsIPrincipal> mPrincipal; > > > > bool mForcePending; > > nsCOMPtr<nsIURI> mTopWindowURI; > > + mozilla::Atomic<bool> mOnStartRequestCalled; > > why the atomic? Is non-main thread involved somehow? No of course it is should be all on the main thread.
Attachment #8569816 - Attachment is obsolete: true
Attachment #8569816 - Flags: review?(jduell.mcbugs)
Attachment #8587380 - Flags: review?(mcmanus)
Attachment #8587380 - Flags: review?(mcmanus) → review+
Thanks so much for getting this finished! Really appreciated!
Status: NEW → ASSIGNED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: