crash in nsQueryInterface::operator() const for unbalanced {} in userChrome.css



3 years ago
2 years ago


(Reporter: tonymec, Unassigned)




SeaMonkey Tracking Flags

(seamonkey2.52 unaffected)


(Whiteboard: [startupcrash] [seamonkey-2.45-affected], crash signature)


(1 attachment)

This bug was filed from the Socorro interface and is 
report bp-81d7b785-b4e9-475c-b9ca-3ecbf2160309.
also: bp-fc07cfa9-b240-4b53-b3de-b85862160309

I made a change to my userChrome.css, and didn't notice that the ruleset I had modified was now without a closing }. On restart (going to Safe Mode and back via the Help menuitem), SeaMonkey crashed. Start again from the bash command-line: crash again. Look in more detail at userChrome.css, found the error, corrected it: no crash.

I admit that a syntax error in a stylesheet may cause "strange" behaviour in the browser; but it should ignore the invalid text and not crash. I'll (temporarily) undo the edit and attach the invalid file.
The missing } is between lines 199 and 200.
Comment on attachment 8728380 [details]
stylesheet with incorrect syntax

... at about ¼ of the length, just before the TABS section.
Attachment #8728380 - Attachment mime type: text/plain → text/css
QA Whiteboard: [seamonkey-2.45-affected]
And now, the crash data:

Signature 	nsQueryInterface::operator() const More Reports Search
UUID 	81d7b785-b4e9-475c-b9ca-3ecbf2160309
Date Processed 	2016-03-09T11:03:31.968377+00:00
Uptime 	80
Last Crash 	2517713 seconds before submission
Install Age 	50582 since version was first installed.
Install Time 	2016-03-08 20:59:48
Product 	SeaMonkey
Version 	2.45a1
Build ID 	20160308003002
Release Channel 	nightly
OS 	Linux
OS Version 	0.0.0 Linux 4.1.15-8-default #1 SMP PREEMPT Wed Jan 20 16:41:00 UTC 2016 (0e3b3ab) x86_64
Build Architecture 	amd64
Build Architecture Info 	family 6 model 23 stepping 10 | 2
Crash Reason 	SIGSEGV
Crash Address 	0x0
User Comments 	

during restart from safe mode
App Notes 	

FP(D000-L100000-W00000000-T0000) OpenGL: Intel Open Source Technology Center -- Mesa DRI Intel(R) Q45/Q43  -- 2.1 Mesa 11.0.8 -- texture_from_pixmap

Processor Notes 	processor_ip-172-31-1-150_1292; MozillaProcessorAlgorithm2015; skunk_classifier: reject - not a plugin hang


Winsock LSP 	


Adapter Vendor ID 	

Adapter Device ID 	

Bugzilla - Report this bug in SeaMonkey Core Plugins Toolkit
Related Bugs

Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	nsQueryInterface::operator()(nsID const&, void**) const 	xpcom/glue/nsCOMPtr.cpp
1 	nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) 	xpcom/glue/nsCOMPtr.cpp
2 	imgRequestProxy::UnblockOnload() 	/builds/slave/c-cen-t-lnx64/build/objdir/dist/include/nsCOMPtr.h:504
3 	mozilla::image::ImageObserverNotifier<const mozilla::image::ObserverTable*>::operator()<mozilla::image::SyncNotifyInternal(const T&, bool, mozilla::image::Progress, const nsIntRect&) [with T = const mozilla::image::ObserverTable*; mozilla::image::Progress = unsigned int; nsIntRect = mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>]::<lambda(mozilla::image::IProgressObserver*)> > 	/builds/slave/c-cen-t-lnx64/build/mozilla/image/ProgressTracker.cpp:346
4 	void mozilla::image::SyncNotifyInternal<mozilla::image::ObserverTable const*>(mozilla::image::ObserverTable const* const&, bool, unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&) 	/builds/slave/c-cen-t-lnx64/build/mozilla/image/ProgressTracker.cpp:346
5 	mozilla::image::ProgressTracker::SyncNotifyProgress(unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&) 	/builds/slave/c-cen-t-lnx64/build/mozilla/image/ProgressTracker.cpp:390
6 	mozilla::image::RasterImage::NotifyProgress(unsigned int, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::image::SurfaceFlags) 	/builds/slave/c-cen-t-lnx64/build/mozilla/image/RasterImage.cpp:1704
7 	mozilla::image::RasterImage::FinalizeDecoder(mozilla::image::Decoder*) 	/builds/slave/c-cen-t-lnx64/build/mozilla/image/RasterImage.cpp:1784
8 	mozilla::image::NotifyDecodeCompleteWorker::Run() 	image/DecodePool.cpp
9 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
10 	NS_ProcessNextEvent(nsIThread*, bool) 	/builds/slave/c-cen-t-lnx64/build/mozilla/xpcom/glue/nsThreadUtils.cpp:297
11 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
12 	MessageLoop::Run() 	ipc/chromium/src/base/
13 	nsBaseAppShell::Run() 	/builds/slave/c-cen-t-lnx64/build/mozilla/widget/nsBaseAppShell.cpp:156
14 	nsAppStartup::Run() 	/builds/slave/c-cen-t-lnx64/build/mozilla/toolkit/components/startup/nsAppStartup.cpp:281
15 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp
16 	XREMain::XRE_main(int, char**, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp
17 	XRE_main 	toolkit/xre/nsAppRunner.cpp
18 	seamonkey 	do_main 	/builds/slave/c-cen-t-lnx64-ntly/build/suite/app/nsSuiteApp.cpp:197
19 	seamonkey 	main 	/builds/slave/c-cen-t-lnx64-ntly/build/suite/app/nsSuiteApp.cpp:330
Ø 20 	
21 	seamonkey 	_init 	
22 	seamonkey 	_GLOBAL__sub_I_TimeStamp.cpp 	/builds/slave/c-cen-t-lnx64/build/mozilla/mozglue/misc/TimeStamp.cpp:47
23 		@0x7fffa527b87f 	
24 	seamonkey 	__libc_csu_fini 	
25 	seamonkey 	_GLOBAL__sub_I_TimeStamp.cpp 	/builds/slave/c-cen-t-lnx64/build/mozilla/mozglue/misc/TimeStamp.cpp:47
26 		@0x7fffa527b87f 	
27 	seamonkey 	_start 	

Show other threads
Oh, and I forgot: the build identification

UA:"Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 SeaMonkey/2.45a1"
ID:20160308003002 en-US

Comment 6

3 years ago
I can't reproduce it in a fresh profile using latest seamonkey-2.45a1 (Linux x86-64).
However, if I create a fresh profile using seamonkey-2.24a1, and then copy
the user style sheet into that and start seamonkey-2.45a1 on that profile,
then the crash occurs.

Here's the stack I get:

(rr) bt 24
#0  0x00007f9e31e8f9ae in nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ()
#1  0x00007f9e31e8d59e in TestNode::Propagate(InstantiationSet&, bool, bool&) ()
#2  0x00007f9e31e8d68f in TestNode::Propagate(InstantiationSet&, bool, bool&) ()
#3  0x00007f9e31e9db6f in nsXULTemplateQueryProcessorRDF::GenerateResults(nsISupports*, nsIXULTemplateResult*, nsISupports*, nsISimpleEnumerator**) ()
#4  0x00007f9e31e94331 in nsXULContentBuilder::CreateContainerContentsForQuerySet(nsIContent*, nsIXULTemplateResult*, bool, nsTemplateQuerySet*, nsIContent**, int*) ()
#5  0x00007f9e31e94a17 in nsXULContentBuilder::CreateContainerContents(nsIContent*, nsIXULTemplateResult*, bool, bool, bool) ()
#6  0x00007f9e31e94b9c in nsXULContentBuilder::CreateTemplateAndContainerContents(nsIContent*, bool) ()
#7  0x00007f9e31e76b57 in mozilla::dom::XULDocument::CreateTemplateBuilder(nsIContent*) ()
#8  0x00007f9e31e76ba2 in mozilla::dom::XULDocument::TemplateBuilderHookup::Resolve() ()
#9  0x00007f9e31e7de8b in mozilla::dom::XULDocument::ResolveForwardReferences() ()
#10 0x00007f9e31e87dc3 in mozilla::dom::XULDocument::ResumeWalk() ()
#11 0x00007f9e31e89569 in mozilla::dom::XULDocument::EndLoad() ()
#12 0x00007f9e31e821ba in XULContentSinkImpl::DidBuildModel(bool) ()
#13 0x00007f9e311cccaa in nsParser::DidBuildModel(nsresult) ()
#14 0x00007f9e311cf929 in nsParser::ResumeParse(bool, bool, bool) ()
#15 0x00007f9e311cfa89 in nsParser::OnStopRequest(nsIRequest*, nsISupports*, nsresult) ()
#16 0x00007f9e310ef082 in nsJARChannel::OnStopRequest(nsIRequest*, nsISupports*, nsresult) ()
#17 0x00007f9e30cd367c in nsInputStreamPump::OnStateStop() ()
#18 0x00007f9e30cd7097 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) ()
#19 0x00007f9e30c62037 in nsInputStreamReadyEvent::Run() ()
#20 0x00007f9e30c72a9f in nsThread::ProcessNextEvent(bool, bool*) ()
#21 0x00007f9e30c8d46b in NS_ProcessNextEvent(nsIThread*, bool) ()
#22 0x00007f9e30e8f158 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ()
#23 0x00007f9e30e76d0e in MessageLoop::Run() ()
(More stack frames follow...)

I don't have debug symbols though so I can't investigate exactly what went wrong.

Looking at crash stats for the top signature:
it appears it's almost exclusively SeaMonkey, and it's clearly a startup crash.
Here's one Firefox crash though, as an example:

Crash stats lists these bugs as related:

   bug 1092810 NEW --- startup Crash after migration data from Seamonkey v.2.30 Final to Seamonkey v2.31 Beta 1 Build 1 [@ nsRDFPropertyTestNode::FilterInstantiations(InstantiationSet&, bool*) const ]
   bug 1057581 UNCONFIRMED --- old profile crashes on startup [@ nsRDFPropertyTestNode::FilterInstantiations]

It seems those bugs don't have STR though.
Here's the exact commands that reproduce it for me:

rm -rf /tmp/p4
./seamonkey-2.24a1/seamonkey/seamonkey -profile /tmp/p4
# quit seamonkey
mkdir -p /tmp/p4/chrome/
cp /test/1254952.css /tmp/p4/chrome/userChrome.css # where /test/1254952.css is the file attached on this bug
./seamonkey-2.45a1/seamonkey/seamonkey -profile /tmp/p4

It's probably better if someone working on SeaMonkey have a look at this.
So reassigning there for now.
Component: CSS Parsing and Computation → General
Product: Core → SeaMonkey
Whiteboard: [startupcrash]

Comment 7

3 years ago
(In reply to Mats Palmgren (:mats) from comment #6)
> I can't reproduce it in a fresh profile using latest seamonkey-2.45a1 (Linux
> x86-64).
> However, if I create a fresh profile using seamonkey-2.24a1, and then copy
> the user style sheet into that and start seamonkey-2.45a1 on that profile,
> then the crash occurs.


> It's probably better if someone working on SeaMonkey have a look at this.
> So reassigning there for now.

Mats: we are all front end people with the exception of Neil. Unfortunately he's currently MIA. If you can give us some hints about how to investigate this?

Tonymec: Can you reproduce this with Firefox? e.g.

1. create a new profile with Firefox 27
2. copy the userChrome.css to that profile.
3. start Firefox 48 on that profile.
Flags: needinfo?(mats)
Build a debug build of SeaMonkey, debug it in gdb or rr, using the STR at the end of comment 6.
Flags: needinfo?(mats)
Sorry for the late reply, comment 7 escaped my attention.

Cannot reproduce on Fx 55.0a1 with the steps at the end of comment #7
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Now let's try to reproduce with SeaMonkey 2.52a1. In order to keep this bug open I'll do it with --no-remote.
No crash.
UA:"Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 SeaMonkey/2.52a1" 
ID:20170310003001 en-US 

I'm setting this bug to RESOLVED WORKSFORME for now. Feel free to REOPEN with details if you can reproduce it in a SeaMonkey version which is "release or newer" at the moment the bug strikes you.
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
status-firefox48: affected → ---
status-seamonkey2.52: --- → unaffected
Whiteboard: [startupcrash] → [startupcrash] [seamonkey-2.45-affected]
You need to log in before you can comment on or make changes to this bug.