Closed Bug 1709459 Opened 3 years ago Closed 3 years ago

ASAN error in ctypes ffi_closure_inner on 32-bit

Categories

(Core :: js-ctypes, task, P3)

task

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: sfink, Assigned: sfink)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

See https://treeherder.mozilla.org/logviewer?job_id=337472220&repo=try&lineNumber=3849 but it's 100% reproducible locally.

I encountered it while attempting to add in some 32-bit fuzzing builds.

================================================================
==350==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 0xffff66ec at pc 0x59edd494 bp 0xffff6608 sp 0xffff6600
READ of size 4 at 0xffff66ec thread T0
#0 0x59edd493 in ffi_closure_inner /builds/worker/checkouts/gecko/js/src/ctypes/libffi/src/x86/ffi.c:425:25
#1 0x59eddb1e in ffi_closure_i386 /builds/worker/checkouts/gecko/js/src/ctypes/libffi/src/x86/sysv.S:354
#2 0x59edd9e7 in ffi_call_i386 /builds/worker/checkouts/gecko/js/src/ctypes/libffi/src/x86/sysv.S:120
#3 0x59edccd5 in ffi_call_int /builds/worker/checkouts/gecko/js/src/ctypes/libffi/src/x86/ffi.c:391:3
#4 0x59edc586 in ffi_call /builds/worker/checkouts/gecko/js/src/ctypes/libffi/src/x86/ffi.c:397:3
#5 0x56c47f1e in js::ctypes::CDataFinalizer::CallFinalizer(js::ctypes::CDataFinalizer::Private*, int*, int*) /builds/worker/checkouts/gecko/js/src/ctypes/CTypes.cpp:8486:3
#6 0x56c47f1e in js::ctypes::CDataFinalizer::Methods::Dispose(JSContext*, unsigned int, JS::Value*) /builds/worker/checkouts/gecko/js/src/ctypes/CTypes.cpp:8604:3
#7 0x56cedb8a in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:437:13
#8 0x56cedb8a in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:522:12
#9 0x56cb932a in InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:582:10
#10 0x56cb932a in js::CallFromStack(JSContext*, JS::CallArgs const&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:586:10
#11 0x56cb932a in Interpret(JSContext*, js::RunState&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:3248:16
#12 0x56c92058 in js::RunScript(JSContext*, js::RunState&) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:406:13
#13 0x56cf7536 in js::ExecuteKernel(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, JS::Handle<JS::Value>, js::AbstractFramePtr, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:776:13
#14 0x56cf7f8e in js::Execute(JSContext*, JS::Handle<JSScript*>, JS::Handle<JSObject*>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/Interpreter.cpp:808:10
#15 0x5718ae8e in ExecuteScript(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSScript*>, JS::MutableHandle<JS::Value>) /builds/worker/checkouts/gecko/js/src/vm/CompilationAndEvaluation.cpp:442:10
#16 0x5718b71d in JS_ExecuteScript(JSContext*, JS::Handle<JSScript*>) /builds/worker/checkouts/gecko/js/src/vm/CompilationAndEvaluation.cpp:466:10
#17 0x56a17303 in RunFile(JSContext*, char const*, _IO_FILE*, CompileUtf8, bool) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:1062:10
#18 0x56a1549f in Process(JSContext*, char const*, bool, FileKind) /builds/worker/checkouts/gecko/js/src/shell/js.cpp
#19 0x56964df7 in ProcessArgs(JSContext*, js::cli::OptionParser*) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:10801:12
#20 0x56964df7 in Shell(JSContext*, js::cli::OptionParser*, char**) /builds/worker/checkouts/gecko/js/src/shell/js.cpp:11576:12
#21 0x569537e9 in main /builds/worker/checkouts/gecko/js/src/shell/js.cpp:12526:12
#22 0xf7a82b40 in __libc_start_main (/lib32/libc.so.6+0x1ab40)
#23 0x5687ed61 in _start (/builds/worker/workspace/obj-spider/dist/bin/js+0x329d61)

I tried to poke at it a little bit. It's dying on a stack address in a finalizer.

Blocks: 1707001

sounds like the same issue as bug 1279096, that applied a workaround only to ffi64.c, and I guess we need the same workaround for ffi.c

See Also: → 1279096
Severity: -- → S3
Priority: -- → P3
Assignee: nobody → sphink
Status: NEW → ASSIGNED
Pushed by sfink@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/225d9db4ad36
make ASAN skip 32-bit ffi_call in addition to 64-bit ones (see bug 1279096) r=glandium
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: