Solaris 2.6, Purify. Compiled with gcc 2.7.2.3. A UMR in xptcall can't be good. I might be wrong though. **** Purify instrumented ./apprunner.pure (pid 3014) **** UMR: Uninitialized memory read (6 times): * This is occurring while in: *unknown func* [pc=0xef6e31f8] nsXPCWrappedNativeClass::CallWrappedMethod(JSContext*,nsXPCWrappedNative*,const XPCNativeMemberDescriptor*,int,unsigned int,long*,long*) [xpcwrappednativeclass.cpp:540] nsXPCWrappedNativeClass::GetAttributeAsJSVal(JSContext*,nsXPCWrappedNative*,cons t XPCNativeMemberDescriptor*,long*) [xpcprivate.h:483] WrappedNative_GetProperty(JSContext*,JSObject*,long,long*) [xpcwrappednativeclass.cpp:734] js_Interpret [jsinterp.c:2155] js_Execute [jsinterp.c:815] JS_EvaluateUCScriptForPrincipals [jsapi.c:2390] nsJSContext::EvaluateString(const nsString&,const char*,unsigned int,nsString&,int*) [nsJSEnvironment.cpp:120] XULContentSinkImpl::EvaluateScript(nsString&,unsigned int) [nsXULContentSink.cpp:1538] XULContentSinkImpl::DoneLoadingScript(nsIUnicharStreamLoader*,nsString&,void*,un signed int) [nsXULContentSink.cpp:1493] nsUnicharStreamLoader::OnStopBinding(nsIURL*,unsigned int,const unsigned short*) [nsNetStreamLoader.cpp:156] nsDocumentBindInfo::OnStopBinding(nsIURL*,unsigned int,const unsigned short*) [nsDocLoader.cpp:1527] stub_complete(_NET_StreamClass*) [nsStubContext.cpp:772] net_ProcessFile [mkfile.c:1360] NET_ProcessNet [mkgeturl.c:3355] NET_PollSockets [mkselect.c:298] nsNetlibService::NetPollSocketsCallback(nsITimer*,void*) [nsNetService.cpp:1276] TimerImpl::FireTimeout() [nsTimer.cpp:73] nsTimerExpired [nsTimer.cpp:189] g_timeout_dispatch [gmain.c:1147] g_main_dispatch [gmain.c:647] g_main_iterate [gmain.c:854] g_main_run [gmain.c:912] gtk_main [gtkmain.c:475] nsAppShell::Run() [nsAppShell.cpp:197] nsAppShellService::Run() [nsAppShellService.cpp:400] main [nsAppRunner.cpp:482] _start [crt1.o] * Reading 4 bytes from 0xefffe280 on the stack.

Reassigning to jband. Getting there...

Adding rogerl to the cc list... Roger, is your code likely doing something wrong or is Purify in error?

Well, without wanting to ignore the possibility that my code IS likely doing something wrong, I don't believe this is it. The InvokeByIndex code loads all the parameter registers (o0..o5) from the outgoing space allocated on the stack regardless of the number of parameters actually being used, so it's quite likely that some of them will be loading un-initialized values, but that's o.k. since they're not being used. InvokeCopyToStack could return the number of registers to load and have the assembly code dispatch to the appropriate slot in the load sequence, I'll take a look at that eventually.

reassigning to roger.

I need to verify that this still happens after the Sun guys contributed the updated code here. I'll attempt to do so this week.

Not going to make M13 for these.

Punt.

Per Clayton, bulk moving Solaris bugs to Sun.

Re-assigning to Rich Burridge, working on Solaris port of Netscape 6.

This now appears to be: UMR: Uninitialized memory read (234 times) This is occurring while in: *unknown func* [pc=0xef49ee0c] EventHandler(PLEvent*) [nsProxyEvent.cpp:478] if (proxyObject) { // invoke the magic of xptc... => nsresult rv = XPTC_InvokeByIndex( proxyObject->GetRealObject(), info->GetMethodIndex(), info->GetParameterCount(), info->GetParameterList()); nsProxyObject::Post(unsigned int,nsXPTMethodInfo*,nsXPTCMiniVariant*,nsIInterfaceInfo*) [nsProxyEvent.cpp:418] nsProxyEventObject::CallMethod(unsigned short,const nsXPTMethodInfo*,nsXPTCMiniVariant*) [nsProxyEventObject.cpp:403] nsProxyEventClass::CallQueryInterfaceOnProxy(nsProxyEventObject*,const nsID&,nsProxyEventObject**) [nsProxyEventClass.cpp:244] nsProxyEventClass::DelegatedQueryInterface(nsProxyEventObject*,const nsID&,void**) [nsProxyEventClass.cpp:346] nsProxyEventObject::QueryInterface(const nsID&,void**) [nsProxyEventObject.cpp:352] nsQueryInterface::operator ()(const nsID&,void**)const [nsCOMPtr.cpp:32] nsCOMPtr<nsIHTTPNotify>::assign_from_helper(const nsCOMPtr_helper&,const nsID&) [nsCOMPtr.h:813] nsCOMPtr<nsIHTTPNotify>::nsCOMPtr<nsIHTTPNotify>(const nsQueryInterface&) [nsCOMPtr.h:525] nsHTTPChannel::OnHeadersAvailable() [nsHTTPChannel.cpp:1491] nsHTTPChannel::FinishedResponseHeaders() [nsHTTPChannel.cpp:1651] nsHTTPChannel::ReadFromCache(unsigned int,int) [nsHTTPChannel.cpp:954] nsHTTPChannel::AsyncRead(unsigned int,int,nsISupports*,nsIStreamListener*) [nsHTTPChannel.cpp:282] nsDocumentOpenInfo::Open(nsIChannel*,int,const char*,nsISupports*) [nsURILoader.cpp:246] nsURILoader::OpenURIVia(nsIChannel*,int,const char*,nsISupports*,unsigned int) [nsURILoader.cpp:591] nsURILoader::OpenURI(nsIChannel*,int,const char*,nsISupports*) [nsURILoader.cpp:510] ImageNetContextImpl::GetURL(ilIURL*,NET_ReloadMethod,ilINetReader*) [nsImageNetContextAsync.cpp:751] il_image_complete(il_container_struct*) [if.cpp:1562] ImgDCallbk::ImgDCBHaveImageAll() [if.cpp:191] process_buffered_gif_input_data(gif_struct*) [gif.cpp:692] gif_delay_time_callback(void*) [gif.cpp:725] timer_callback(nsITimer*,void*) [nsImageSystemServices.cpp:70] nsTimerGtk::FireTimeout() [nsTimerGtk.cpp:58] nsTimerExpired [nsTimerGtk.cpp:175] g_timeout_dispatch [gmain.c:1147] g_main_dispatch [gmain.c:647] g_main_iterate [gmain.c:854] g_main_run [gmain.c:912] gtk_main [gtkmain.c:475] Reading 4 bytes from 0xefffe4e8 on the stack.

[richb - 22nd March 2000] I've attached: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=6791 This is a Purify log of the UMR's generated by calls to XPTC_InvokeByIndex when I startup Mozilla (M14), and then just Quit from the File menu after the Mozilla browser window is fully displayed. This is with Mozilla compiled with Sun 5.0 compilers and using Purify 4.5.1. There are 23 occurances of this error (each repeated multiple times). It's interesting to note that the number of bytes below the frame pointer varies with the different calls to XPTC_InvokeByIndex. I suspect there is a direct correlation between this value and the number of parameters (and their size) for the method being invoked, and Purify is getting confused by the XPTC_InvokeByIndex assembly code just adjusting the frame pointer. I'm not going to try to prove or disprove this theory.

How come this is still M15? M15 is already out!

[richb - 4/27/00] It was M15 because of my inexperience with Bugzilla. I've adjusted this to M17. I actually don't believe it's a bug; it's just Purify's inability to handle hand-coded assembler files. I just haven't found the time to prove that yet though.

Closing after discussing with richb. We can just suppress this. We've all got better work to do as this causes no real problems whatsoever.