Open Bug 1111355 Opened 11 years ago Updated 3 years ago

Incorrectly assuming __builtin_alloca return value in NS_InvokeByIndex (x86_64_unix)

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
34 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: goughostt, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 Build ID: 20141214161703 Steps to reproduce: compile firefox 34.0.5 with cflags: -O2 -march=native -pipe. CPU is Core i5-3317U. Actual results: Segfault in functions called by NS_InvokeByIndex. Usually the ``_retval`` is not correctly passed to the callee.
The disassembled code for the inlined function __builtin_alloca: 0x00007ffff254437b <+123>: add $0x2e,%rax 0x00007ffff254438f <+143>: shr $0x4,%rax 0x00007ffff2544393 <+147>: shl $0x4,%rax 0x00007ffff2544397 <+151>: sub %rax,%rsp 0x00007ffff254439a <+154>: lea 0x1f(%rsp),%r8 0x00007ffff254439f <+159>: and $0xffffffffffffffe0,%r8 The returned address (%r8) is 32 byte aligned; while %rax and %rsp are only assumed to be 16 byte aligned. So it's possible that %r8!=%rsp in the end. But the following code needs this equality to correctly pass arguments in stack. Usually __builtin_alloca returns 16 byte aligned address; while with -mavx, gcc generates code for 32 byte alignment. It happens when using -march=native on Core i? CPUs. My suggestion is to replace __builtin_alloca(x) with __builtin_alloca_with_align(x, 128). Or best, replace it with inline assembly.
Component: Untriaged → Build Config
Product: Firefox → Core
Component: Build Config → XPCOM
Looks like __builtin_alloca_with_align is available in GCC 4.7-ish, so we could conceivably use it on desktop. __BIGGEST_ALIGNMENT__ is 32 when compiling with -mavx, rather than 16.
Can someone confirm if bug 1117023 and bug 1121608 could be related to this bug?
(In reply to Dâniel Fraga from comment #3) > Can someone confirm if bug 1117023 and bug 1121608 could be related to this > bug? Try __builtin_alloca_with_align, as shown in my previous post. If that works, I'd say they are the same. If this function is not available, some inline assembly should be used. It's not a gcc bug, as long as alloca return value is not required, by any standard, to be equal to the current rsp.
(In reply to gou from comment #4) > Try __builtin_alloca_with_align, as shown in my previous post. If that > works, I'd say they are the same. If this function is not available, some > inline assembly should be used. Unfortunately it seems to be not the same issue. I tried __builtin_alloca_with_align and it keeps segfaulting: Program received signal SIGSEGV, Segmentation fault. js::IsInRequest (cx=cx@entry=0x1a0060) at /home/fraga/src/mozilla/js/src/jsfriendapi.cpp:1434 1434 return !!cx->runtime()->requestDepth; (gdb) bt #0 js::IsInRequest (cx=cx@entry=0x1a0060) at /home/fraga/src/mozilla/js/src/jsfriendapi.cpp:1434 #1 0x00007ffff25d539e in JS::Rooted<JSObject*>::Rooted (this=0x7fffffff6d60, cx=0x1a0060, _notifier=...) at ../../dist/include/js/RootingAPI.h:746 #2 0x00007ffff2611ece in nsXPCComponents_Utils::EvalInSandbox (this=<optimized out>, source=..., sandboxVal=..., version=..., filenameArg=..., lineNumber=0, cx=0x1a0060, optionalArgc=22 '\026', retval=$jsval(6.9533558060057757e-310)) at /home/fraga/src/mozilla/js/xpconnect/src/XPCComponents.cpp:2635 #3 0x00007ffff2656432 in Invoke (this=0x7fffffff6e20) at /home/fraga/src/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:2396 #4 CallMethodHelper::Call (this=0x7fffffff6e20) at /home/fraga/src/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1748 #5 0x00007ffff2653c51 in XPCWrappedNative::CallMethod (ccx=..., mode=mode@entry=XPCWrappedNative::CALL_METHOD) at /home/fraga/src/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1715 #6 0x00007ffff265bb3f in XPC_WN_CallMethod (cx=0x7ffff6a6b690, argc=<optimized out>, vp=0x7fffffff7748) at /home/fraga/src/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1247 #7 0x00007ffff45ea5e4 in js::CallJSNative (cx=0x7ffff6a6b690, native=0x7ffff265b948 <XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/fraga/src/mozilla/js/src/jscntxtinlines.h:231 #8 0x00007ffff45e809a in js::Invoke (cx=cx@entry=0x7ffff6a6b690, args=..., construct=construct@entry=js::NO_CONSTRUCT) at /home/fraga/src/mozilla/js/src/vm/Interpreter.cpp:481 #9 0x00007ffff45e8794 in js::Invoke (cx=cx@entry=0x7ffff6a6b690, thisv=..., fval=..., argc=argc@entry=3, argv=argv@entry=0x7fffffff7b40, rval=JSVAL_VOID) at /home/fraga/src/mozilla/js/src/vm/Interpreter.cpp:537 #10 0x00007ffff4802c3f in js::jit::DoCallFallback (cx=0x7ffff6a6b690, frame=0x7fffffff7bd0, stub_=<optimized out>, argc=3, vp=0x7fffffff7b30, res=JSVAL_VOID) at /home/fraga/src/mozilla/js/src/jit/BaselineIC.cpp:8663 #11 0x00007ffff7fef04b in ?? () #12 0x00007ffff4f7e8e8 in JS::NullPtr::constNullValue () from /home/fraga/src/firefox/dist/bin/libxul.so #13 0x00007fffffff7ae8 in ?? () #14 0x00007ffff4f7e8e8 in JS::NullPtr::constNullValue () from /home/fraga/src/firefox/dist/bin/libxul.so #15 0xfff9000000000000 in ?? () #16 0x00007ffff6317900 in js::jit::DoSpreadCallFallbackInfo () from /home/fraga/src/firefox/dist/bin/libxul.so #17 0x00007fffe3129040 in ?? () #18 0x00007fffe5553d97 in ?? () #19 0x0000000000000582 in ?? () #20 0x00007fffffff7bd0 in ?? () #21 0x00007fffe1908d90 in ?? () #22 0x0000000000000003 in ?? () #23 0x00007fffffff7b30 in ?? () #24 0xfffc7fffe0d635e0 in ?? () #25 0xfffc7fffe156d6d0 in ?? () #26 0xfffaffffe15944d8 in ?? () #27 0xfffc7fffe0d52080 in ?? () #28 0xfffaffffe15944f0 in ?? () #29 0x00007fffffff7c10 in ?? () #30 0x00007fffe1908d90 in ?? () #31 0x00007fffe4b7779c in ?? () #32 0x0000000000000a01 in ?? () #33 0xfffaffffe15944f0 in ?? () #34 0xfffc7fffe0d52080 in ?? () #35 0xfffaffffe15944d8 in ?? () #36 0xfffc7fffe156d6d0 in ?? () #37 0xfffc7fffe0d635e0 in ?? () #38 0xfffa000000000011 in ?? () #39 0xfffaffffe313e340 in ?? () #40 0xfffc7fffe0d55130 in ?? () #41 0xfffaffffe0d4cd18 in ?? () #42 0xfffc7fffe0d28d60 in ?? () #43 0xfffc7fffe3c210a0 in ?? () #44 0xfffc7fffe3c211f0 in ?? () #45 0x0000000000000000 in ?? ()
> #0 js::IsInRequest (cx=cx@entry=0x1a0060) at > /home/fraga/src/mozilla/js/src/jsfriendapi.cpp:1434 > #1 0x00007ffff25d539e in JS::Rooted<JSObject*>::Rooted > (this=0x7fffffff6d60, cx=0x1a0060, _notifier=...) at > ../../dist/include/js/RootingAPI.h:746 > #2 0x00007ffff2611ece in nsXPCComponents_Utils::EvalInSandbox > (this=<optimized out>, source=..., sandboxVal=..., version=..., > filenameArg=..., lineNumber=0, cx=0x1a0060, > optionalArgc=22 '\026', retval=$jsval(6.9533558060057757e-310)) at > /home/fraga/src/mozilla/js/xpconnect/src/XPCComponents.cpp:2635 > #3 0x00007ffff2656432 in Invoke (this=0x7fffffff6e20) at > /home/fraga/src/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:2396 strange backtrace. Is there a call to 'EvalInSandbox' from 'Invoke'? __builtin_alloca_with_align(x, 128). Try other powers of 2 instead of 128. But that should be 128 for x86_64.
Maybe duplicate of bug 680547, though with more detail?
I posted a workaround there. Not sure if it's worth keeping this bug open for a better fix.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.