Closed Bug 8373 Opened 21 years ago Closed 20 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: 20 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.