498876 - Segmentation fault in nsXULPrototypeCache::WritePrototype during program startup with profile on full disk drive

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[Peter Trenholme]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4
Build Identifier: 3.0-2.3-b2

Here's an extract from gdb: (I include the "warning," but it's probably not relevant. Seg fault is at end.

[Thread 0xb51ffb70 (LWP 11675) exited]                       
warning: .dynamic section for "/usr/lib/libXss.so.1" is not at the expected address                                                                             
warning: difference appears to be caused by prelink, adjusting expectations     
[New Thread 0xb51ffb70 (LWP 11677)]                                             
[Thread 0xb5effb70 (LWP 11676) exited]                                          
[New Thread 0xb5effb70 (LWP 11679)]                                             

Program received signal SIGSEGV, Segmentation fault.
nsXULPrototypeCache::WritePrototype (this=0xb785b920, aPrototypeDocument=
    0xb539e700)
    at /usr/src/debug/thunderbird-3.0/mozilla/content/xul/document/src/nsXULPrototypeCache.cpp:523
523                 gFastLoadService->EndMuxedDocument(protoURI);


Reproducible: Always

Steps to Reproduce:
1. Set cache size to 500Mb in preferences
2. Exit TB
3. Try to restart TB
Actual Results:  
Seg fault in nsXULPrototypeCache.cpp, line 523

Expected Results:  
Normal start

The cache size was increased because TB was complaining that it could not store new mail. (There are several hundred messages in my wife's inbox, some more than 4 years old. She doesn't like to delete anything.) After increasing the cache size, new mail "flowed" again. However, after she closed TB, she was unable to restart it, getting, instead, the seg. fault error. (Only visible when TB is started from the command line, of course.)

Comment 1

[Peter Trenholme]

Oops! I may have misspoke! (Although a seg. fault is a bit much for a full drive condition. See below.)

After poking around on my wife's system some more, I (re)discovered that her profile was pointing to an old 20Gb XP drive rather than the 750Gb Linux drive. When I looked at that drive, it was 100% full and, when I cleaned out a couple Gb of garbage, her system (under Fedora 11) resumed working.

I then tried a simple copy of her profile to the Fedora drive, but got the (completely misleading) "Another TB seccion is running" pop-up. But that's another issue, eh?

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to Peter Trenholme from comment #1)
> ...
> I then tried a simple copy of her profile to the Fedora drive, but got the
> (completely misleading) "Another TB seccion is running" pop-up. But that's
> another issue, eh?

yes

Comment 3

[Wayne Mery (:wsmwk)]

current signatures are quite rare. And unclear whether they are same issue as comment 0 which does not have a full stacktrace

bp-8e3c5a6b-ae34-4890-8f88-2d7e40180716
bp-076c8260-6351-43b6-882f-7dd400180716 (same user)
 0 		@0x829d0c00	
1 	xul.dll	nsXULPrototypeCache::WritePrototype(nsXULPrototypeDocument*)	dom/xul/nsXULPrototypeCache.cpp:325
2 	xul.dll	mozilla::dom::XULDocument::EndLoad()	dom/xul/XULDocument.cpp:506
3 	xul.dll	XULContentSinkImpl::DidBuildModel(bool)	dom/xul/nsXULContentSink.cpp:228
4 	xul.dll	nsParser::DidBuildModel(nsresult)	parser/htmlparser/nsParser.cpp:492
5 	xul.dll	nsParser::ResumeParse(bool, bool, bool)	parser/htmlparser/nsParser.cpp:1098
6 	xul.dll	nsParser::OnStopRequest(nsIRequest*, nsISupports*, nsresult)	parser/htmlparser/nsParser.cpp:1468
7 	xul.dll	nsJARChannel::OnStopRequest(nsIRequest*, nsISupports*, nsresult)	modules/libjar/nsJARChannel.cpp:1019
8 	xul.dll	nsInputStreamPump::OnStateStop()	netwerk/base/nsInputStreamPump.cpp:714

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.