Closed Bug 49668 Opened 24 years ago Closed 24 years ago

lots of assertions in nsLanguageAtomService.cpp

Categories

(Core :: Networking, defect, P3)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: dbaron, Assigned: warrensomebody)

Details

(Whiteboard: [dogfood-])

I see lots of assertions in nsLanguageAtomService.cpp in the tinderbox run logs. These started appearing after warren's checkin at 2000-08-21 01:23. Assuming these are XP, lots of assertions make it hard for Windows folks to get work done, so marking smoketest blocker for now.
Sample assertions: ###!!! ASSERTION: SetPipeliningAllowed: 'Not Reached', file nsResChannel.cpp, line 624 ###!!! Break: at file nsResChannel.cpp, line 624 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(NS_OpenURI(getter_AddRefs(in), uri))) failed: '(!((NS_OpenURI(getter_AddRefs(in), uri)) & 0x80000000))', file nsLanguageAtomService.cpp, line 130 ###!!! Break: at file nsLanguageAtomService.cpp, line 130 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(InitLangGroupTable())) failed: '(!((InitLangGroupTable()) & 0x80000000))', file nsLanguageAtomService.cpp, line 177 ###!!! Break: at file nsLanguageAtomService.cpp, line 177 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(res)) failed: '(!((res) & 0x80000000))', file nsLanguageAtomService.cpp, line 286 ###!!! Break: at file nsLanguageAtomService.cpp, line 286 ###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(res)) failed: '(!((res) & 0x80000000))', file nsLanguageAtomService.cpp, line 231 ###!!! Break: at file nsLanguageAtomService.cpp, line 231
I'm beginning to think this could be some dependencies problem. The assertion is reached by the following call stack: nsResChannel::SetPipeliningAllowed NS_OpenURI(nsIInputStream**, nsIURI*, ...) nsLanguageAtomService::InitLangGroupTable ... and the rest of the assertions are triggered by the failure of NS_OpenURI. I'm not sure how NS_OpenURI ends up calling nsResChannel::SetPipeliningAllowed. It looks like it's trynig to call nsResChannel::OpenInputStream.
Stack from gdb: #0 nsDebug::Assertion (aStr=0x40e2851f "SetPipeliningAllowed", aExpr=0x40181534 "Not Reached", aFile=0x40e28205 "nsResChannel.cpp", aLine=624) at nsDebug.cpp:191 #1 0x40125122 in nsDebug::NotReached ( aMessage=0x40e2851f "SetPipeliningAllowed", aFile=0x40e28205 "nsResChannel.cpp", aLine=624) at nsDebug.cpp:411 #2 0x40dce134 in nsResChannel::SetPipeliningAllowed (this=0x8298c20, aPipeliningAllowed=-1073751508) at nsResChannel.cpp:624 #3 0x41aad523 in NS_OpenURI (result=0xbfffda88, uri=0x8287140, ioService=0x0, loadGroup=0x0, notificationCallbacks=0x0, loadAttributes=0, bufferSegmentSize=0, bufferMaxSize=0) at ../../../dist/include/nsNetUtil.h:160 #4 0x41a9fd81 in nsLanguageAtomService::InitLangGroupTable (this=0x81ce8d0) at nsLanguageAtomService.cpp:130 #5 0x41aa053c in nsLanguageAtomService::LookupLanguage (this=0x81ce8d0, aLanguage=0x829bd68, aResult=0xbfffde10) at nsLanguageAtomService.cpp:177 #6 0x41aa168e in nsLanguageAtomService::GetLocaleLanguageGroup ( this=0x81ce8d0, aResult=0x8230ba8) at nsLanguageAtomService.cpp:285 #7 0x40032bc9 in DeviceContextImpl::GetLocaleLangGroup (this=0x8230b88) at nsDeviceContext.cpp:248 #8 0x40032c86 in DeviceContextImpl::GetMetricsFor (this=0x8230b88, aFont=@0x8286334, aLangGroup=0x82323b0, aMetrics=@0xbfffdfe4) at nsDeviceContext.cpp:266
David, what are you doing to see this? I'm running a debug build from 8am this morning on Windows and I've been to a number of pages and have started mail without seeing this assertion.
I see this both in the tinderbox logs (all three machines that run tests) and by running a build that I grabbed off coffee (my build hasn't finished).
I marked this as a blocker on the assumption that it would be cross-platform. Considering that nobody other than tinderbox has seen it yet, it probably shouldn't be. (My own Linux debug build isn't finished yet.)
Most definitely a dependency problem. NS_OpenURI never calls SetPipeliningAllowed, it's trying to call OpenInputStream. A new method was added to nsIRequest last night (GetName), which is a superclass of nsIChannel. Try a clobber build.
not a smoketest blocker, release builds don't see this.
Severity: blocker → critical
Keywords: smoketest → dogfood
The linux clobber build on tinderbox also doesn't see this. I think it's a bug in gcc. Here's the deal -- nsLanguageAtomService.cpp gets compiled with nsNetUtil.h which contains inlines that call nsIChannel::OpenInputStream. Then we changed nsIRequest (a superclass of nsIChannel) to add a method. nsLanguageAtomService.cpp should get rebuilt, but is not. Leaf: can you try touching nsLanguageAtomService.cpp on one of the depends machines and rebuilding it to see if the problem goes away? I wouldn't hold the tree closed for this.
The interesting thing is, nsLanguageAtomService *did* rebuild on the depend tinderboxes -- see the log. So I'm not sure what it is that needs to be clobbered. Also, which Linux clobber build on tinderbox are you referring to? The only one I see is puma, which doesn't run tests. Is there a commercial clobber with tests?
I don't see nsLanguageAtomService being built on the one I'm looking at (harpoon). Doh -- I didn't notice that puma wasn't running the tests. Are you seeing this on your machine?
No, I'm not seeing it on my machine. I wonder if it could be a problem related to parallel-make stuff...
Putting on [dogfood-] radar.
Whiteboard: [dogfood-]
What's the status on this? Can I close it now?
Yeah, sure.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
marking verified per engineer's comments
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.