Closed Bug 579273 Opened 11 years ago Closed 11 years ago

Crash [@ __memcpy]

Categories

(Core :: JavaScript Engine, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: gkw, Assigned: luke)

References

Details

(Keywords: crash, regression, testcase, Whiteboard: [ccbr][sg:critical?] fixed-in-tracemonkey [critsmash:patch])

Crash Data

Attachments

(3 files)

The attached testcase crashes js opt shell on TM tip without -j at __memcpy.

This is uber-scary and difficult to reduce. Assuming [sg:critical?] and setting s-s.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x012ffff0
0xffff0ee6 in __memcpy ()
(gdb) bt
#0  0xffff0ee6 in __memcpy ()
#1  0x000fae3a in js_NewStringCopyN ()
#2  0x001171dc in JSCompartment::wrap ()
#3  0x00117d39 in JSCompartment::wrap ()
#4  0x0011a692 in JSCrossCompartmentWrapper::defineProperty ()
#5  0x000c360a in js::proxy_DefineProperty ()
#6  0x0007c9c0 in js_obj_defineGetter ()
#7  0x0006e1a3 in js::InvokeCommon<int (*)(JSContext*, JSObject*, unsigned int, js::Value*, js::Value*)> ()
#8  0x0006ef3d in js::Invoke ()
#9  0x0006f943 in js::InternalInvoke ()
#10 0x000c1bed in js::JSProxyHandler::call ()
#11 0x0011c6c6 in JSCrossCompartmentWrapper::call ()
#12 0x000c256c in js::proxy_Call ()
#13 0x0006edf6 in js::Invoke ()
#14 0x0005dc80 in js::Interpret ()
#15 0x0006e65b in js::Execute ()
#16 0x00014a18 in JS_ExecuteScript ()
#17 0x00006100 in Process ()
#18 0x00009826 in shell ()
#19 0x00009d37 in main ()
(gdb) x/i $eip
0xffff0ee6 <__memcpy+1862>:     movdqa -0x40(%esi,%edx,1),%xmm3
(gdb) x/b $esi
0x11f90f0:      0x00
(gdb) x/b $edx
0x106f40 <_ZN18TypedArrayTemplateI13uint8_clampedE9fun_sliceEP9JSContextjPN2js5ValueE+1664>:    0x00
Attached file 2446-line testcase
(The attached testcase contains a large part of jsfunfuzz and should be treated as private)
This doesn't occur in debug.

Looking at the assembly, it seems to refer to the movdqa instruction - related to SSE2 in any way?
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   47546:9c869e64ee26
user:        Luke Wagner
date:        Wed Jul 14 23:19:36 2010 -0700
summary:     Bug 549143 - fatvals
Blocks: fatvals
Ah, I think I see the culprit:

    union {
        PropertyOp op;
        jsval v;
    } u;
    u.op = *propp;

Man, even my structification of jsval can't catch this statically.  This is why restricted casts like CastAsObject are awesome.
Attached patch fixSplinter Review
Simple fix
Assignee: general → lw
Status: NEW → ASSIGNED
Attachment #457920 - Flags: review?(dmandelin)
Attachment #457920 - Flags: review?(dmandelin) → review+
http://hg.mozilla.org/tracemonkey/rev/946ac3ca890e
Whiteboard: [ccbr][sg:critical?] → [ccbr][sg:critical?] fixed-in-tracemonkey
Duplicate of this bug: 579261
Duplicate of this bug: 579256
Duplicate of this bug: 579359
Duplicate of this bug: 579364
Whiteboard: [ccbr][sg:critical?] fixed-in-tracemonkey → [ccbr][sg:critical?] fixed-in-tracemonkey [critsmash:patch]
OS: Mac OS X → Windows 7
http://hg.mozilla.org/mozilla-central/rev/946ac3ca890e
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
blocking2.0: ? → betaN+
Group: core-security
Crash Signature: [@ __memcpy]
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.