Closed
Bug 8373
Opened 25 years ago
Closed 25 years ago
Stack array bounds read in xptcall
Categories
(Core :: XPConnect, defect, P3)
Tracking
()
M15
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*).
Updated•25 years ago
|
Status: NEW → ASSIGNED
Comment 1•25 years ago
|
||
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?
Reporter | ||
Comment 2•25 years ago
|
||
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.
Updated•25 years ago
|
Target Milestone: M8
Comment 3•25 years ago
|
||
M8
Updated•25 years ago
|
Target Milestone: M8 → M9
Updated•25 years ago
|
Target Milestone: M9 → M10
Comment 4•25 years ago
|
||
Moving out to M10 per choffman's request
Updated•25 years ago
|
Target Milestone: M10 → M11
Comment 5•25 years ago
|
||
No fix pending, so moving out to m11
Updated•25 years ago
|
Target Milestone: M11 → M12
Updated•25 years ago
|
Target Milestone: M12 → M13
Updated•25 years ago
|
Target Milestone: M13 → M14
Comment 6•25 years ago
|
||
Not going to make M13 for these.
Comment 9•25 years ago
|
||
Per Clayton, bulk moving Solaris bugs to Sun.
Assignee: rogerl → drapeau
Status: ASSIGNED → NEW
Comment 10•25 years ago
|
||
Re-assigning to Margaret Chan, working on Solaris port of Netscape 6.
Assignee: drapeau → mtchan
Assignee | ||
Comment 11•25 years ago
|
||
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?
Assignee | ||
Comment 12•25 years ago
|
||
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.
Assignee | ||
Comment 13•25 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•