Closed Bug 551001 Opened 15 years ago Closed 9 years ago

Crash [@ nsACString_internal::Equals(nsACString_internal const&)]

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Version:
1.9.2 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE
Tracking Flags:
Tracking Status
blocking1.9.2 --- -
status1.9.2 --- wanted

People

(Reporter: johnjbarton, Unassigned)

Details

(Keywords: crash, Whiteboard: [firebug-p2])

Crash Data

Almost every time I test Firebug 1.5: http://crash-stats.mozilla.com/report/index/bp-7d060055-e221-4780-9818-f57e22100219 1. Install Firebug 1.5.3, http://getfirebug.com/releases/firebug 2. Install FBTest 1.6, from svn at https://fbug.googlecode.com/svn/fbtest/branches/fbtest1.6, add a file to your profile extensions directory pointing to that directory (sorry we don't distribute this) 3. Open Firebug F12 4. Open FBTest: Firebug > Firebug Icon menu > Open Firebug Test Console 5. Put the URL: https://getfirebug.com/tests/content/testlists/firebug1.5.html, enter 6. Push the button "Run All" Sometimes all the tests will run (<3 min). Most times we crash.
Whiteboard: [firebug-p1]
Looks like this is 1.9.2something, right? 0 xul.dll nsACString_internal::Equals xpcom/string/src/nsTSubstring.cpp:626 1 xul.dll SearchTable obj-firefox/xpcom/build/pldhash.c:439 2 xul.dll nsSafeFileOutputStream::Finish netwerk/base/src/nsFileStreams.cpp:576 3 xul.dll PL_DHashTableOperate obj-firefox/xpcom/build/pldhash.c:625 4 mozcrt19.dll malloc obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:5790 5 xul.dll nsCacheService::ProcessRequest netwerk/cache/src/nsCacheService.cpp:1151 6 xul.dll nsCacheService::OpenCacheEntry netwerk/cache/src/nsCacheService.cpp:1236 7 xul.dll nsCacheSession::OpenCacheEntry netwerk/cache/src/nsCacheSession.cpp:98 8 xul.dll nsHttpChannel::OpenCacheEntry netwerk/protocol/http/src/nsHttpChannel.cpp:1831 9 xul.dll nsHttpChannel::Connect That top part of the stack seems to be garbage...
blocking1.9.2: --- → ?
status1.9.2: --- → ?
Component: XPCOM → Networking: Cache
QA Contact: xpcom → networking.cache
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2pre) Gecko/20100308 Namoroka/3.6.2pre But it has been happening for some time.
Based on comment 2 I don't think that this blocks, but we'd take a reviewed patch.
blocking1.9.2: ? → -
status1.9.2: ? → wanted
I am not able to test Firebug 1.6 on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3pre) Gecko/20100326 Namoroka/3.6.3pre
We still crash almost half the time we run. http://crash-stats.mozilla.com/report/index/197069f7-6405-455b-a8e9-5d7bf2101023
Severity: normal → critical
Keywords: crash
Summary: Crash nsACString_internal::Equals(nsACString_internal const&) → Crash [@ nsACString_internal::Equals(nsACString_internal const&)]
John, I can't reproduce this. I just ran all tests at least 5 times and no crash. - Firefox 3.6.12pre - Firebug 1.7a4 - FBTest 1.7b3 - Test list: firebug1.7.html - Windows XP What could be different in our settings...? Honza
I really don't know. I have Win7 on both machines that crash on this. Sometimes it happens three times in a row and I get started to make "steps to reproduce". Then the fourth time it works.
I now have to fix this or find a workaround. I can't continue this way. I now see that the crashes are not all the same signature. http://crash-stats.mozilla.com/report/index/bp-015d5b66-4f67-4b7c-bb7a-0a29d2101115 This one says nsSegmentedBuffer::DeleteLastSegment() http://crash-stats.mozilla.com/report/index/bp-23dbe69e-9703-44ef-a857-aad4c2101115 This one is more common and it is the one reported one this bug. http://crash-stats.mozilla.com/report/index/bp-d69cb6d0-3a2b-48b3-8c0f-05ff02101116 was reported as bug 591647. Most often I hit this on exit, but I see some of my comments "fbtest". So I wonder: are there three crashers here that add up or one that hits in different ways?
Signature nsSegmentedBuffer::DeleteLastSegment() UUID 015d5b66-4f67-4b7c-bb7a-0a29d2101115 Crash Address 0x7c 130 nsSegmentedBuffer::DeleteLastSegment() 131 { 132 PRInt32 last = ModSegArraySize(mLastSegmentIndex - 1); 133 NS_ASSERTION(mSegmentArray[last] != nsnull, "deleting bad segment"); 134 (void)mSegAllocator->Free(mSegmentArray[last]); this crash has a .dump file. Someone can try to determine which is null... odds favor the assertion as having failed.
At the crash we are on return mLength == str.mLength && char_traits::compare(mData, str.mData, mLength) == 0; And the Locals are: - this 0x000000ff {mData=??? mLength=??? mFlags=??? } const nsACString_internal * const mData CXX0030: Error: expression cannot be evaluated mLength CXX0030: Error: expression cannot be evaluated mFlags CXX0030: Error: expression cannot be evaluated - str {mData=0x08b9b5b0 "HTTP:https://getfirebug.com/tests/content/script/1483/index.js" mLength=62 mFlags=5 } const nsACString_internal & + mData 0x08b9b5b0 "HTTP:https://getfirebug.com/tests/content/script/1483/index.js" char * mLength 62 unsigned int mFlags 5 unsigned int
(In reply to comment #9) > Signature nsSegmentedBuffer::DeleteLastSegment() Maybe this one is not related...I'll try to focus on the original crash
The 'this' ptr in the crashing function is cacheEntry->mKey in the caller, MatchEntry() cacheEntry looks like someone walked on it with 0xff == 255: - cacheEntry 0x08881f70 {mKey=0x000000ff mFetchCount=255 mLastFetched=255 ...} nsCacheEntry * + PRCListStr {next=0x000001a4 prev=0x000000ff } PRCListStr + mKey 0x000000ff nsCString * mFetchCount 255 unsigned int mLastFetched 255 unsigned int mLastModified 255 unsigned int mLastValidated 255 unsigned int mExpirationTime 255 unsigned int mFlags 255 unsigned int mDataSize 255 unsigned int + mCacheDevice 0x000000ff nsCacheDevice * + mSecurityInfo {...} nsCOMPtr<nsISupports> + mData 0x000000ff nsISupports * + mThread {...} nsCOMPtr<nsIThread> + mMetaData {mData=0x000000ff mMetaSize=255 } nsCacheMetaData + mRequestQ {next=0x000000ff prev=0x000000ff } PRCListStr + mDescriptorQ {next=0x000000ff prev=0x000000ff } PRCListStr
boris, can you help me determine if this bug is visible to the right people?
> This one says nsSegmentedBuffer::DeleteLastSegment() That stack is garbage too. John, it's not clear who the right people are, because all I can tell from your stacks is that something has stomped on the stack....
Here is the recent part of the stack from MSVC++, it look ok yes? xul.dll!nsACString_internal::Equals(const nsACString_internal & str) Line 626 C++ > xul.dll!nsCacheEntryHashTable::MatchEntry(PLDHashTable * __formal, const PLDHashEntryHdr * hashEntry, const void * key) Line 518 C++ xul.dll!SearchTable(PLDHashTable * table, const void * key, unsigned int keyHash, PLDHashOperator op) Line 439 C xul.dll!PL_DHashTableOperate(PLDHashTable * table, const void * key, PLDHashOperator op) Line 625 C xul.dll!nsCacheEntryHashTable::GetEntry(const nsCString * key) Line 445 C++ xul.dll!nsCacheService::ActivateEntry(nsCacheRequest * request, nsCacheEntry * * result) Line 1265 C++ xul.dll!nsCacheService::ProcessRequest(nsCacheRequest * request, int calledFromOpenCacheEntry, nsICacheEntryDescriptor * * result) Line 1151 C++ xul.dll!nsCacheService::OpenCacheEntry(nsCacheSession * session, const nsACString_internal & key, int accessRequested, int blockingMode, nsICacheListener * listener, nsICacheEntryDescriptor * * result) Line 1236 C++ xul.dll!nsCacheSession::OpenCacheEntry(const nsACString_internal & key, int accessRequested, int blockingMode, nsICacheEntryDescriptor * * result) Line 98 C++ xul.dll!nsHttpChannel::OpenCacheEntry(int offline, int * delayed) Line 1832 C++ xul.dll!nsHttpChannel::Connect(int firstTime) Line 315 C++ xul.dll!nsHttpChannel::AsyncOpen(nsIStreamListener * listener, nsISupports * context) Line 4499 C++ xul.dll!nsScriptLoader::StartLoad(nsScriptLoadRequest * aRequest, const nsAString_internal & aType) Line 294 C++ xul.dll!nsScriptLoader::ProcessScriptElement(nsIScriptElement * aElement) Line 561 C++ xul.dll!nsScriptElement::MaybeProcessScript() Line 193 C++ xul.dll!nsHTMLScriptElement::MaybeProcessScript() Line 564 C++ xul.dll!nsHTMLScriptElement::DoneAddingChildren(int aHaveNotified) Line 490 C++ xul.dll!HTMLContentSink::ProcessSCRIPTEndTag(nsGenericHTMLElement * content, int aMalformed) Line 3112 C++ xul.dll!SinkContext::CloseContainer(nsHTMLTag aTag, int aMalformed) Line 1014 C++ xul.dll!HTMLContentSink::CloseContainer(nsHTMLTag aTag) Line 2392 C++ xul.dll!CNavDTD::CloseContainer(nsHTMLTag aTag, int aMalformed) Line 2762 C++ xul.dll!CNavDTD::HandleEndToken(CToken * aToken) Line 1641 C++ xul.dll!CNavDTD::HandleToken(CToken * aToken) Line 721 C++ xul.dll!CNavDTD::BuildModel(nsITokenizer * aTokenizer, int aCanInterrupt, int aCountLines, const nsCString * __formal) Line 304 C++ xul.dll!nsParser::BuildModel() Line 2456 C++ xul.dll!nsParser::ResumeParse(int allowIteration, int aIsFinalChunk, int aCanInterrupt) Line 2337 C++ xul.dll!nsParser::OnDataAvailable(nsIRequest * request, nsISupports * aContext, nsIInputStream * pIStream, unsigned int sourceOffset, unsigned int aLength) Line 2985 C++ xul.dll!nsDocumentOpenInfo::OnDataAvailable(nsIRequest * request, nsISupports * aCtxt, nsIInputStream * inStr, unsigned int sourceOffset, unsigned int count) Line 306 C++ xul.dll!nsStreamListenerWrapper::OnDataAvailable(nsIRequest * aRequest, nsISupports * aContext, nsIInputStream * aInputStream, unsigned int aOffset, unsigned int aCount) Line 5962 C++ xul.dll!nsStreamListenerTee::OnDataAvailable(nsIRequest * request, nsISupports * context, nsIInputStream * input, unsigned int offset, unsigned int count) Line 108 C++ xul.dll!nsHTTPCompressConv::do_OnDataAvailable(nsIRequest * request, nsISupports * context, unsigned int offset, const char * buffer, unsigned int count) Line 375 C++ xul.dll!nsHTTPCompressConv::OnDataAvailable(nsIRequest * request, nsISupports * aContext, nsIInputStream * iStr, unsigned int aSourceOffset, unsigned int aCount) Line 306 C++ xul.dll!nsStreamListenerTee::OnDataAvailable(nsIRequest * request, nsISupports * context, nsIInputStream * input, unsigned int offset, unsigned int count) Line 108 C++ xul.dll!nsHttpChannel::OnDataAvailable(nsIRequest * request, nsISupports * ctxt, nsIInputStream * input, unsigned int offset, unsigned int count) Line 5391 C++ xul.dll!nsInputStreamPump::OnStateTransfer() Line 510 C++ xul.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream) Line 400 C++ xul.dll!nsInputStreamReadyEvent::Run() Line 113 C++ xul.dll!nsThread::ProcessNextEvent(int mayWait, int * result) Line 527 C++
You have this in a debugger right now? And you're crashing in that Equals() call? What can you tell me about the argument to nsCacheEntryHashTable::GetEntry?
yes, yes and: - key 0x088d9a48 const nsCString * - nsACString_internal {mData=0x08b9b5b0 "HTTP:https://getfirebug.com/tests/content/script/1483/index.js" mLength=0x0000003e mFlags=0x00000005 } nsACString_internal + mData 0x08b9b5b0 "HTTP:https://getfirebug.com/tests/content/script/1483/index.js" char * mLength 0x0000003e unsigned int mFlags 0x00000005 unsigned int
OK, that looks fine. In nsCacheEntryHashTable::MatchEntry, what can you tell me about cacheEntry->mKey and about *(nsCString*)key?
cacheEntry->mKey is in comment 12, it has 0xff all over it.
Ah, indeed. That doesn't sound like a happy cacheEntry. :( I have no idea where 0x000000ff would come from in cache code... Bjarne?
No bells ringing on 0x55, no... does it always crash in the same test? Does it crash when starting or stopping the test (or somewhere in the middle)? How does the test-suite treat the cache (ie is cache cleared at startup or is is populated already)?
(In reply to comment #21) > No bells ringing on 0x55, no... 0xff no 0x55 > does it always crash in the same test? It crashes my browser about half the time, not at the same place. > Does it > crash when starting or stopping the test (or somewhere in the middle)? Middle. The app also crashes at exit also, but a different stack. > How does > the test-suite treat the cache (ie is cache cleared at startup or is is > populated already)? We are all Javascript, just a XUL window running a long JS programming driving the browser as hard as possible.
(In reply to comment #22) > 0xff no 0x55 Still no bells... :) (sorry - fingertrouble) > The app also crashes at exit also, but a different stack. Consistently? > We are all Javascript, just a XUL window running a long JS programming driving > the browser as hard as possible. From what I read it sounds like it is the sheer load on the cache which causes the issue, not any particular usage-pattern or url. Is that also your impression?
(In reply to comment #23) > (In reply to comment #22) > > 0xff no 0x55 > Still no bells... :) (sorry - fingertrouble) > > > The app also crashes at exit also, but a different stack. > Consistently? Commonly, I can't say consistently since most of the time I kill the process. > > > We are all Javascript, just a XUL window running a long JS programming driving > > the browser as hard as possible. > From what I read it sounds like it is the sheer load on the cache which causes > the issue, not any particular usage-pattern or url. Is that also your > impression? Since the crash occurs on two Win7 machines and earlier on WinXP, but not on other users machines I assume the problem has to do with different I/O timing triggering a race condition.
I can imagine there are race-conditions in the disk-cache, yes... :( Have you tried disabling the disk-cache, running only with the memory-cache? What about the entries in question: are they typically small ones (<4k) which fit into the block-files in the cache or are they larger and will be stored in separate files? (Just to narrow this down as much as possible...)
(In reply to comment #25) > Have you tried disabling the disk-cache, running only with the memory-cache? No, I don't know how to do this. > What about the entries in question: are they typically small ones (<4k) which > fit into the block-files in the cache or are they larger and will be stored in > separate files? I have no idea even what the cache is or what entries may mean. I can build Firefox and operate the debugger, but I have no idea what this code is doing or why.
I set browser.cache.disk.capacity to 0 (zero) and I crash at the same point. I set browser.cache.memory.enable to false. I have not crashed so far.
Both settings the same time? And, btw, which point do you refer to? Can we narrow this down to a particular test?
No, one setting at a time. The crash usually happens on the same test case during a run, but we cannot narrow it down. Running the single test case by itself never crashes in my experience. Several different tests crash, so getting past the first one (1483) does not mean the entire run will succeed.
It's interesting that disabling memory-cache seems to do the trick.... we (well I, at least) normally suspect the disk-cache when things go bad. Would it be possible to stop the test immediately before the "first one" starts and dump the cache? (I.e. gzip the cache-directory and attach it here.)
Moving this one to [firebug-p2] since we can workaround it.
Whiteboard: [firebug-p1] → [firebug-p2]
Does this happen in FF4? If not, then perhaps we can make the forced setting browser.cache.memory.enable=false only happen on FF3.6.
Crash Signature: [@ nsACString_internal::Equals(nsACString_internal const&)]
Crash Signature: [@ nsACString_internal::Equals(nsACString_internal const&)] → [@ nsACString_internal::Equals(nsACString_internal const&)] [@ nsACString_internal::Equals]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.