Closed
Bug 824484
Opened 12 years ago
Closed 12 years ago
Intermittent crash in test_privatebrowsing_cancel.js, test_bug430120.js [@ntdll.dll + 0x2fc47], with nsCacheEntryDescriptor::nsOutputStreamWrapper::Close() on the stack
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: Gavin, Assigned: michal)
References
Details
(Keywords: crash, intermittent-failure)
Attachments
(2 files, 2 obsolete files)
5.99 KB,
text/plain
|
Details | |
17.91 KB,
patch
|
michal
:
review+
|
Details | Diff | Splinter Review |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Updated•12 years ago
|
Component: Private Browsing → Networking: Cache
Product: Firefox → Core
Summary: Intermittent crash in test_privatebrowsing_cancel.js [@ntdll.dll + 0x2fc47], with nsCacheEntryDescriptor::nsOutputStreamWrapper::Close() on the stack → Intermittent crash in test_privatebrowsing_cancel.js, test_bug430120.js [@ntdll.dll + 0x2fc47], with nsCacheEntryDescriptor::nsOutputStreamWrapper::Close() on the stack
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Assignee | ||
Comment 10•12 years ago
|
||
Grabbing a reference to the stream under the cache lock in nsCacheService::CloseAllStreams() doesn't ensure that it won't go away since it might be already waiting for the lock in the destructor. This patch fixes the problem.
Assignee | ||
Comment 11•12 years ago
|
||
Tryserver looks good.
https://tbpl.mozilla.org/?tree=Try&rev=f4c3ab6166fe
Assignee | ||
Comment 12•12 years ago
|
||
With the change from bug #808997, input and output streams can live longer than cache service. So we must not grab the cache lock when we are not sure that the cache service exists, i.e. when mDescriptor is null.
tryserver push: https://tbpl.mozilla.org/?tree=Try&rev=3664f349ba47
Attachment #696883 -
Attachment is obsolete: true
Attachment #696883 -
Flags: review?(bsmith)
Attachment #697008 -
Flags: review?(bsmith)
Assignee | ||
Comment 13•12 years ago
|
||
Comment on attachment 697008 [details] [diff] [review]
patch v2
Brian seems to be busy, reassigning to Nick.
Attachment #697008 -
Flags: review?(bsmith) → review?(hurley)
Comment 14•12 years ago
|
||
Comment on attachment 697008 [details] [diff] [review]
patch v2
Review of attachment 697008 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good to me, just one minor nit below.
::: netwerk/cache/nsCacheEntryDescriptor.cpp
@@ +674,5 @@
> + count = NS_AtomicDecrementRefcnt(mRefCnt);
> + NS_LOG_RELEASE(this, count, "nsCacheEntryDescriptor::nsInputStreamWrapper");
> +
> + if (0 == count) {
> + if (mDescriptor) {
Is there a particular reason to use mDescriptor instead of desc here? Just seems odd to me to use the thing you've already gotten a local reference to. If there's a reason I'm missing, please add a comment explaining why you use mDescriptor instead of desc before landing. (Same goes for other Release functions in other places in this patch.)
Attachment #697008 -
Flags: review?(hurley) → review+
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to Nick Hurley [:hurley] from comment #14)
> Is there a particular reason to use mDescriptor instead of desc here? Just
> seems odd to me to use the thing you've already gotten a local reference to.
> If there's a reason I'm missing, please add a comment explaining why you use
> mDescriptor instead of desc before landing. (Same goes for other Release
> functions in other places in this patch.)
mDescriptor can be nulled out on another thread between releasing mLock and acquiring cache lock. We would need to grab the cache lock under the mLock but then we would release these locks in non-LIFO order which causes warning here:
http://hg.mozilla.org/mozilla-central/annotate/6955309291ee/xpcom/glue/BlockingResourceBase.cpp#l167
Even with the current locking, it wouldn't be a big problem to use desc instead of mDescriptor because output streams just null out back-reference. But in case of input streams the assertion would need to be removed since the wrapper might be already removed from the array. Anyway, the current code is more clean and correct.
Attachment #697008 -
Attachment is obsolete: true
Attachment #697567 -
Flags: review+
Assignee | ||
Comment 19•12 years ago
|
||
Comment 20•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
You need to log in
before you can comment on or make changes to this bug.
Description
•