Closed Bug 8373 Opened 25 years ago Closed 25 years ago

Stack array bounds read in xptcall

Categories

(Core :: XPConnect, defect, P3)

Sun
Solaris
defect

Tracking

()

VERIFIED DUPLICATE of bug 15604

People

(Reporter: bruce, Assigned: margaret.chan)

Details

**** Purify instrumented ./apprunner.pure (pid 100) **** SBR: Stack array bounds read: * This is occurring while in: *unknown func* [pc=0xef6e99d0] nsXPCWrappedNativeClass::CallWrappedMethod(JSContext*,nsXPCWrappedNative*,const XPCNativeMemberDescriptor*,nsXPCWrappedNativeClass::CallMode,unsigned int,long*,long*) [xpcwrappednativeclass.cpp:605] WrappedNative_CallMethod(JSContext*,JSObject*,unsigned int,long*,long*) [xpcwrappednativeclass.cpp:732] js_Invoke [jsinterp.c:655] js_Interpret [jsinterp.c:2206] js_Invoke [jsinterp.c:671] js_Interpret [jsinterp.c:2206] js_Invoke [jsinterp.c:671] js_Interpret [jsinterp.c:2206] js_Execute [jsinterp.c:820] JS_EvaluateUCScriptForPrincipals [jsapi.c:2507] JS_EvaluateUCScript [jsapi.c:2488] JS_EvaluateScript [jsapi.c:2456] GlobalWindowImpl::RunTimeout(nsTimeoutImpl*) [nsGlobalWindow.cpp:1489] nsGlobalWindow_RunTimeout(nsITimer*,void*) [nsGlobalWindow.cpp:1402] TimerImpl::FireTimeout() [nsTimer.cpp:73] nsTimerExpired [nsTimer.cpp:196] 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:237] nsAppShellService::Run() [nsAppShellService.cpp:404] main [nsAppRunner.cpp:648] _start [crt1.o] * Reading 4 bytes from 0xefffe12c. * Frame pointer 0xefffe128 * Address 0xefffe12c is 4 bytes above stack pointer in function nsXPCWrappedNativeClass::CallWrappedMethod(JSContext*,nsXPCWrappedNative*,const XPCNativeMemberDescriptor*,nsXPCWrappedNativeClass::CallMode,unsigned int,long*,long*).
Status: NEW → ASSIGNED
I don't know enough about Purify on a Sparc to understand this - what is a stack array bounds read? is it a bad thing?
From what I understand, this is a combination of a 'BSR' (Beyond stack read) and a ABR (Array bounds read). An array bounds read is an obvious thing. A BSR is when you have something like this: FunctionA() calls FunctionB(). FunctionB() returns a local variable that was allocated on the stack rather than the heap to FunctionA(). So, I belive that an SBR is an array bounds read of something beyond the stack frame. Make sense or seem relevant here? If I'm correct, this doesn't seem like an entirely healthy course of action. Unfortunately, this could mean that the problem is really in whatever code got called from here, so additional debugging would be required. This does seem to happen fairly often during the runtime though, and happens during startup of the browser.
Target Milestone: M8
M8
Target Milestone: M8 → M9
Target Milestone: M9 → M10
Moving out to M10 per choffman's request
Target Milestone: M10 → M11
No fix pending, so moving out to m11
Target Milestone: M11 → M12
QA Contact: desale → cbegle
Target Milestone: M12 → M13
Target Milestone: M13 → M14
Not going to make M13 for these.
Punt.
Target Milestone: M14 → M15
Moving all XPConnect QA contact to rginda
QA Contact: cbegle → rginda
Per Clayton, bulk moving Solaris bugs to Sun.
Assignee: rogerl → drapeau
Status: ASSIGNED → NEW
Re-assigning to Margaret Chan, working on Solaris port of Netscape 6.
Assignee: drapeau → mtchan
With an attempt to reproduce this, I saw quite a few SBR when I tried to purify mozilla. The stack trace leads to my suspicion that Rich's fix for bug 15604 may resolve this problem as well. I am going to apply his patch to see how it goes. Bruce, would you mind trying his patch out and see if it fixes the SBR problem in your environment as well?
I have done some testings with both Sun Workshop 4.2 & 5.0 compilers. I have purified mozilla using my 4.2 and 5.0 builds on M14. I purified it up to the point when the browser came up. Both times, I saw SBR and the stacks were pretty similar to what I saw in this report. I have attached two SBR instances below: >>> 4.2 build <<< **** Purify instrumented ./mozilla-bin.pure (pid 1923) **** SBR: Stack array bounds read: * This is occurring while in: *unknown func* [pc=0xfefcc9f4] nsXPCWrappedNativeClass::CallWrappedMethod(JSContext*, nsXPCWrappedNative*, c onst XPCNativeMemberDescriptor*, nsXPCWrappedNativeClass::CallMode, unsigned int, lon g*, long*) [xpcwrappednativeclass.cpp:897] WrappedNative_CallMethod(JSContext*, JSObject*, unsigned int, long*, long*) [ xpcwrappednativejsops.cpp:198] js_Invoke [jsinterp.c:665] js_Interpret [jsinterp.c:2292] js_Invoke [jsinterp.c:681] * Reading 4 bytes from 0xffbec6c0. * Frame pointer 0xffbec6b8 * Address 0xffbec6c0 is 8 bytes above stack pointer in function nsXPCWrapped NativeClass::CallWrappedMethod(JSContext*, nsXPCWrappedNative*, const XPCNativeMember Descriptor*, nsXPCWrappedNativeClass::CallMode, unsigned int, long*, long*). >>> 5.0 build <<< **** Purify instrumented ./mozilla-bin.pure (pid 23991) **** SBR: Stack array bounds read (18 times): * This is occurring while in: XPTC_InvokeByIndex [libxpcom.so] int nsXPCWrappedNativeClass::CallWrappedMethod(JSContext*,nsXPCWrappedNative* ,const XPCNativeMemberDescriptor*,nsXPCWrappedNativeClass::CallMode,unsigned,long*,lo ng*) [xpcwrappednativeclass.cpp:897] int nsXPCWrappedNativeClass::GetAttributeAsJSVal(JSContext*,nsXPCWrappedNativ e*,const XPCNativeMemberDescriptor*,long*) [xpcprivate.h:874] int WrappedNative_GetProperty(JSContext*,JSObject*,long,long*) [xpcwrappednat ivejsops.cpp:244] js_Interpret [jsinterp.c:2248] js_Execute [jsinterp.c:836] * Reading 4 bytes from 0xffbedda8. * Frame pointer 0xffbedda8 * Address 0xffbedda8 is 0 bytes above stack pointer in function int nsXPCWra ppedNativeClass::CallWrappedMethod(JSContext*,nsXPCWrappedNative*,const XPCNativeMemb erDescriptor*,nsXPCWrappedNativeClass::CallMode,unsigned,long*,long*). Applying Rich's patch for 15604, SBR no longer showed up for the 5.0 build. However, it still showed up for the 4.2 build. I've, therefore, applied the same change to one more file, ../mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_asm_sparc_solaris_GCC.s, the SBR also went away in the 4.2 build. Obviously, the 4.2 build uses this file instead of the xptcinvoke_asm_sparc_solaris_SUNW.s. Specifically, the change is for this save instruction: XPTC_InvokeByIndex: save %sp,-(64 + 32),%sp ! room for the register window and ! struct pointer, rounded up to 0 % 16 To my knowledge, Rich's fix for 15604 with the abovementioned change to the above file should fix this bug as well. cc this to Rich to make sure that the above file got changed as well for bug 15604. Bruce, would you verify this fix for me? As it works for me, I want to make sure that it works for you as well. Thanks.
Did not hear from Bruce. Am closing it as duplicate of bug #15604 based on the comments I have provided earlier. *** This bug has been marked as a duplicate of 15604 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
since no objection from reporter: VERIFY dupe
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.