Closed Bug 574171 Opened 14 years ago Closed 8 years ago

3.6.4: Silverlight 4 hang and random errors with WCF RIA Services [@ hang | mozilla::plugins::PPluginScriptableObjectParent::CallInvokeDefault(nsTArray<mozilla::plugins::Variant> const&, mozilla::plugins::Variant*, bool*)][@ hang | npctrl.dll@0x65cbe]

Categories

(Plugins Graveyard :: Silverlight (Microsoft), defect)

Product:
Plugins Graveyard
Component:
Silverlight (Microsoft)
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: suicidalsquirrel, Unassigned)

Details

(Keywords: hang) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4

Silverlight 4 WCF/RIA Services Application, built with the default Visual Studio 2010 Business Template and customized (unfortunately no public demo yet).

Calling WCF/RIA service methods leads to random error messages on the client side (= Silverlight Host), and to plug-in crashes in ~25% of the attempts. Error seems to be related to deserialization of network messages in Silverlight (complains about bad formatting, wrong data types etc.).

Network messages inspected and proofed valid in Fiddler2.

Application continues to work without any problems in IE8 and Firefox 3.6.3.

Reproducible: Always

Steps to Reproduce:
1. Unknown. Seems to be related to a certain constellation of SL4/RIA Services. Default Visual Studio sample (without customization) works. No public demo of the problem yet, unfortunately.

Actual Results:  
Plug-in crashes, deserialization errors in SL4 (filed several reports).

Expected Results:  
Not crash :-); work as in 3.6.3

Default theme. Some developing related addons (Dev Toolbar, Firebug etc.). All working in 3.6.3
Are you seeing errors on the Error Console?
If you firefox crashes, they should show up in about:crashes

Can you go to about:crashes in the location bar and check if you have crash links there, you can submit those and then paste the relevant links to them from the crash stats website in this bug report.
Additionally, you might want to check your Issue with OOPP for the Silverlight Plugin disabled:
* load "about:config"
* set "dom.ipc.plugins.enabled.npctrl.dll" to "false"
* restart Firefox
https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
Component: General → Silverlight (Microsoft)
Keywords: stackwanted
Product: Firefox → Plugins
QA Contact: general → microsoft-silverlight
Version: unspecified → 4.x
Ok, here is the information you wanted.

1.) No, when the Plug-In crashes, there are no errors in the console.

2.) Every crash seems to produce two entries in the crash list (at least there are always two with very close/similar timestamps). Here are the three last ones from last night. Please note that for the third ones I was first redirected to http://crash-stats.mozilla.com/about/throttling.

http://crash-stats.mozilla.com/report/index/745df6ae-9e35-4995-bc9b-2d3a62100623
http://crash-stats.mozilla.com/report/index/52f65ef2-8ac2-4cd2-8c5a-767822100623

http://crash-stats.mozilla.com/report/index/a4a04fbc-f783-462f-b73b-c09052100623
http://crash-stats.mozilla.com/report/index/10d574a2-41f7-4051-906a-dc6062100623

http://crash-stats.mozilla.com/report/index/3855c422-6b80-4a82-af36-88cad2100624
http://crash-stats.mozilla.com/report/index/991fe5d8-80e4-437e-a987-4601a2100624

3.) Disabling OOPP fixes the issue. I couldn't produce a crash and also receive no error messages from the SL runtime anymore. No surprise here I think because each crash was related to the npctrl.dll. 

I hope this information helps. Let me know if you need more, and thank you for your support.
fwiw, the reason you're seeing two reports is that what's happening is the browser process asks the plugin process to do something, the plugin process doesn't respond w/in a "reasonable time period", and we kill the plugin. In order to recognize cases where the browser has done something "problematic", we send a report containing what the browser was doing. Before we split plugins out of process, the stack trace that a plugin dev would have seen would have contained these browser frames and they can be helpful to plugin devs too.

Signature	hang | mozilla::plugins::PPluginScriptableObjectParent::CallInvokeDefault(nsTArray<mozilla::plugins::Variant> const&, mozilla::plugins::Variant*, bool*)
UUID	a4a04fbc-f783-462f-b73b-c09052100623
Time 	2010-06-23 15:00:18.196204
Uptime	67
Install Age	15341 seconds (4.3 hours) since version was first installed.
Product	Firefox
Version	3.6.4
Build ID	20100611143157
Branch	1.9.2
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x6fc675fd
User Comments	
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
6 	xul.dll 	CrashReporter::CreatePairedMinidumps 	toolkit/crashreporter/nsExceptionHandler.cpp:1707
7 	xul.dll 	mozilla::plugins::PluginModuleParent::ShouldContinueFromReplyTimeout 	dom/plugins/PluginModuleParent.cpp:226
8 	xul.dll 	mozilla::ipc::SyncChannel::ShouldContinueFromTimeout 	ipc/glue/SyncChannel.cpp:261
9 	xul.dll 	mozilla::ipc::RPCChannel::Call 	ipc/glue/RPCChannel.cpp:210
10 	xul.dll 	mozilla::plugins::PPluginScriptableObjectParent::CallInvokeDefault 	obj-firefox/ipc/ipdl/PPluginScriptableObjectParent.cpp:367
11 	xul.dll 	mozilla::plugins::PluginScriptableObjectParent::ScriptableInvokeDefault 	dom/plugins/PluginScriptableObjectParent.cpp:265
12 	xul.dll 	CallNPMethodInternal 	modules/plugin/base/src/nsJSNPRuntime.cpp:1512
13 	xul.dll 	NPObjWrapper_Call 	modules/plugin/base/src/nsJSNPRuntime.cpp:1747
14 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1360
15 	js3250.dll 	js_Interpret 	js/src/jsops.cpp:2240
16 	js3250.dll 	js_Invoke 	js/src/jsinterp.cpp:1368
17 	xul.dll 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1696
18 	xul.dll 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:570
19 	xul.dll 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
20 	xul.dll 	SharedStub 	xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
21 	xul.dll 	nsDOMEventListenerWrapper::HandleEvent 	content/events/src/nsDOMEventTargetHelper.cpp:65
22 	xul.dll 	nsEventListenerManager::HandleEventSubType 	content/events/src/nsEventListenerManager.cpp:1041

Signature	hang | npctrl.dll@0x246c7
UUID	10d574a2-41f7-4051-906a-dc6062100623
Process Type	plugin Version: Filename: npctrl.dll
Time 	2010-06-23 15:00:17.702996
Uptime	48
Install Age	15341 seconds (4.3 hours) since version was first installed.
Product	Firefox
Version	3.6.4
Build ID	20100611143157
Branch	1.9.2
OS	Windows NT
OS Version	6.1.7600
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x73d646c7
User Comments	
Processor Notes 	
EMCheckCompatibility	False
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	npctrl.dll 	npctrl.dll@0x246c7 	
1 	npctrl.dll 	npctrl.dll@0x24487 	
2 	npctrl.dll 	npctrl.dll@0x65cbe 	[topmost common stack frame of the 3 reports]
3 	npctrl.dll 	npctrl.dll@0x66540 	
4 	npctrl.dll 	npctrl.dll@0x66f22 	
5 	npctrl.dll 	npctrl.dll@0x8ad41 	
6 	npctrl.dll 	npctrl.dll@0xcf105 	
7 	xul.dll 	mozilla::plugins::PluginScriptableObjectChild::AnswerInvokeDefault 	dom/plugins/PluginScriptableObjectChild.cpp:779
8 	xul.dll 	mozilla::plugins::PPluginScriptableObjectChild::OnCallReceived 	obj-firefox/ipc/ipdl/PPluginScriptableObjectChild.cpp:1316
9 	xul.dll 	mozilla::plugins::PPluginModuleChild::OnCallReceived 	obj-firefox/ipc/ipdl/PPluginModuleChild.cpp:408
10 	xul.dll 	mozilla::ipc::RPCChannel::DispatchIncall 	ipc/glue/RPCChannel.cpp:506
11 	xul.dll 	mozilla::ipc::RPCChannel::Incall 	ipc/glue/RPCChannel.cpp:492
12 	xul.dll 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne 	ipc/glue/RPCChannel.cpp:432
13 	xul.dll 	MessageLoop::RunTask 	ipc/chromium/src/base/message_loop.cc:336

Filename 	Version 	Debug Identifier 	Debug Filename
coreclr.dll 	4.0.50524.0 	87ABA647C05D44A1B2828F6D57E347CB2 	coreclr.pdb
agcore.dll 	4.0.50524.0 	CF2901BE704D439D8E80278649BE73962 	agcore.pdb
npctrl.dll 	4.0.50524.0 	40AE1273AD864F2E859DC875D3EB259C2 	npctrl.pdb
Keywords: stackwanted → hang
Hardware: x86_64 → x86
Summary: 3.6.4: Silverlight 4 crash and random errors with WCF RIA Services → 3.6.4: Silverlight 4 hang and random errors with WCF RIA Services [@ hang | mozilla::plugins::PPluginScriptableObjectParent::CallInvokeDefault(nsTArray<mozilla::plugins::Variant> const&, mozilla::plugins::Variant*, bool*)][@ hang | npctrl.dll@0x65cbe]
I have now identified the reason for these crashes/Silverlight runtime errors and passing on the information on how to reproduce it consistently. In my application, I have customized the requests sent to the WCF/RIA service and added my own HTTP headers to transmit additional meta data.

For example, in some requests I add the header:

X-ClientUICulture: en-US

This causes either:

* A crash of the Silverlight Plugin in Firefox 3.6.3. Most of the time this happens when I run the application for the first time after Firefox has started.
* A Silverlight runtime error: "[Character garbage] contains invalid UTF-8 bytes"
* A Silverlight runtime error: "The value [very large, sometimes negative number] cannot be parsed as the type 'DateTime'"
* A Silverlight runtime error: "The input source is not correctly formatted."

All symptons (crashes and runtime errors) are gone if I:

* Remove that custom HTTP header.
* Disable OOPP.
* Downgrade to FF 3.6.3.
* Use any other browser supported by Silverlight.
Sorry for the confusion: obviously in the previous comment I meant

"[...]This causes either:

* A crash of the Silverlight Plugin in Firefox 3.6._4_.[...]"
I can confirm: removing custom HTTP headers solve the issue.
But this is not a solution.

The Silverlight exception is always about not being able to deserialize the incoming request data. Here is one exception example for a specific request:

System.ServiceModel.Dispatcher.NetDispatcherFaultException was unhandled by user code
  Message=The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:GetWorkersResult. The InnerException message was 'There was an error deserializing the object of type System.ServiceModel.DomainServices.Client.QueryResult`1[[Canesto.Libraries.Models.Worker, Canesto.Libraries.Services, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]. The value '9103481365029219072' cannot be parsed as the type 'DateTime'.'.  Please see InnerException for more details.
  Action=http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher/fault
  StackTrace:
       at System.ServiceModel.DomainServices.Client.WebDomainClient`1.EndQueryCore(IAsyncResult asyncResult)
       at System.ServiceModel.DomainServices.Client.DomainClient.EndQuery(IAsyncResult asyncResult)
       at Canesto.Libraries.Services.EntityQueryExtensions.<>c__DisplayClass3`1.<QueryCompleted>b__2(Object result)
  InnerException: System.Runtime.Serialization.SerializationException
       Message=There was an error deserializing the object of type System.ServiceModel.DomainServices.Client.QueryResult`1[[Canesto.Libraries.Models.Worker, Canesto.Libraries.Services, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]. The value '9103481365029219072' cannot be parsed as the type 'DateTime'.
       StackTrace:
            at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName)
            at System.Runtime.Serialization.DataContractSerializer.ReadObject(XmlDictionaryReader reader, Boolean verifyObjectName)
            at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.DeserializeParameterPart(XmlDictionaryReader reader, PartInfo part, Boolean isRequest)
       InnerException: System.Xml.XmlException
            Message=The value '9103481365029219072' cannot be parsed as the type 'DateTime'.
            LineNumber=0
            LinePosition=0
            StackTrace:
                 at System.Xml.XmlBufferReader.ReadDateTime()
                 at System.Xml.XmlBinaryReader.ReadElementContentAsDateTime()
                 at System.Runtime.Serialization.XmlReaderDelegator.ReadElementContentAsDateTime()
                 at ReadWorkerFromXml(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )
                 at System.Runtime.Serialization.ClassDataContract.ReadXmlValue(XmlReaderDelegator xmlReader, XmlObjectSerializerReadContext context)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.ReadDataContractValue(DataContract dataContract, XmlReaderDelegator reader)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator reader, String name, String ns, DataContract& dataContract)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator xmlReader, Int32 id, RuntimeTypeHandle declaredTypeHandle, String name, String ns)
                 at ReadArrayOfWorkerFromXml(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString , XmlDictionaryString , CollectionDataContract )
                 at System.Runtime.Serialization.CollectionDataContract.ReadXmlValue(XmlReaderDelegator xmlReader, XmlObjectSerializerReadContext context)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.ReadDataContractValue(DataContract dataContract, XmlReaderDelegator reader)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator reader, String name, String ns, DataContract& dataContract)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator xmlReader, Int32 id, RuntimeTypeHandle declaredTypeHandle, String name, String ns)
                 at ReadQueryResultOfWorkerFromXml(XmlReaderDelegator , XmlObjectSerializerReadContext , XmlDictionaryString[] , XmlDictionaryString[] )
                 at System.Runtime.Serialization.ClassDataContract.ReadXmlValue(XmlReaderDelegator xmlReader, XmlObjectSerializerReadContext context)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.ReadDataContractValue(DataContract dataContract, XmlReaderDelegator reader)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator reader, String name, String ns, DataContract& dataContract)
                 at System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator xmlReader, Type declaredType, DataContract dataContract, String name, String ns)
                 at System.Runtime.Serialization.DataContractSerializer.InternalReadObject(XmlReaderDelegator xmlReader, Boolean verifyObjectName)
                 at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName)
            InnerException: System.ArgumentException
                 Message=The binary data must result in a DateTime with ticks between DateTime.MinValue.Ticks and DateTime.MaxValue.Ticks.
Parameter name: dateData
                 StackTrace:
                      at System.DateTime.FromBinaryRaw(Int64 dateData)
                      at System.DateTime.FromBinary(Int64 dateData)
                      at System.Xml.XmlBufferReader.ReadDateTime()
                 InnerException:
This crash is due to Firefox and the custom HTTP headers that you're adding. Unfortunately, this is a browser-specific issue that cannot be addressed through WCF RIA Services or Silverlight.
Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Product: Plugins → Plugins Graveyard
You need to log in before you can comment on or make changes to this bug.