You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We encountered an issue that on a hello world scenario with ChakraCore, Linux Skylake server generates a segmentation fault. This issue only happens on Skylake server, not on Haswell server, not on Skylake client system either. It only happens on Linux, not on Windows.
Following is hello world test case and call stack info when the segmentation fault happens:
/home/git/ttt/ChakraCore/out/Debug$ cat hello.js
console.log("hello");
/home/git/ttt/ChakraCore/out/Debug$ ./ch hello.js
Segmentation fault (core dumped)
/home/git/ttt/ChakraCore/out/Debug$ lldb ch hello.js
(lldb) target create "ch"
Current executable set to 'ch' (x86_64).
(lldb) settings set -- target.run-args "hello.js"
(lldb) br set -n NewThunkBlock
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 238376 launched: '/home/git/ttt/ChakraCore/out/Debug/ch' (x86_64)
1 location added to breakpoint 1
Process 238376 stopped
thread performance tab crashes in f12 on pages with asm.js #1: tid = 238376, 0x00007ffff4b14248 libChakraCore.soInterpreterThunkEmitter::NewThunkBlock(this=0x00005555558ba3a8) + 24 at InterpreterThunkEmitter.cpp:328, name = 'ch', stop reason = breakpoint 1.1 frame #0: 0x00007ffff4b14248 libChakraCore.soInterpreterThunkEmitter::NewThunkBlock(this=0x00005555558ba3a8) + 24 at InterpreterThunkEmitter.cpp:328
325 }
326 #endif
327
-> 328 Assert(this->thunkCount == 0);
329 BYTE* buffer;
330
331 EmitBufferAllocation<VirtualAllocWrapper, PreReservedVirtualAllocWrapper> * allocation = emitBufferManager.AllocateBuffer(BlockSize, &buffer);
(lldb) continue
Process 238376 resuming
Process 238376 stopped
thread performance tab crashes in f12 on pages with asm.js #1: tid = 238376, 0x00007ffff7126d80 libgcc_s.so.1__register_frame, name = 'ch', stop reason = signal SIGSEGV frame #0: 0x00007ffff7126d80 libgcc_s.so.1__register_frame
libgcc_s.so.1`__register_frame:
-> 0x7ffff7126d80 <+0>: movl (%rdi), %eax
0x7ffff7126d82 <+2>: testl %eax, %eax
0x7ffff7126d84 <+4>: jne 0x7ffff7126d90 ; <+16>
0x7ffff7126d86 <+6>: rep
(lldb) bt
Merge pull request #3263 from litian2025:page_execute
The root cause of the issue is because on Windows, if memory is protected as PAGE_EXECUTE, it is implies that it is also PAGE_EXECUTE_READ. This works fine on Haswell server and Skylake client on Linux. However, On Linux Skylake server, it is more restrict and explict, PROT_EXE is Executable only, not readable. The fix is to ensure PAL emulates Windows API. This fix the issue #3262.
We encountered an issue that on a hello world scenario with ChakraCore, Linux Skylake server generates a segmentation fault. This issue only happens on Skylake server, not on Haswell server, not on Skylake client system either. It only happens on Linux, not on Windows.
Following is hello world test case and call stack info when the segmentation fault happens:
/home/git/ttt/ChakraCore/out/Debug$ cat hello.js
console.log("hello");
/home/git/ttt/ChakraCore/out/Debug$ ./ch hello.js
Segmentation fault (core dumped)
/home/git/ttt/ChakraCore/out/Debug$ lldb ch hello.js
(lldb) target create "ch"
Current executable set to 'ch' (x86_64).
(lldb) settings set -- target.run-args "hello.js"
(lldb) br set -n NewThunkBlock
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 238376 launched: '/home/git/ttt/ChakraCore/out/Debug/ch' (x86_64)
1 location added to breakpoint 1
Process 238376 stopped
InterpreterThunkEmitter::NewThunkBlock(this=0x00005555558ba3a8) + 24 at InterpreterThunkEmitter.cpp:328, name = 'ch', stop reason = breakpoint 1.1 frame #0: 0x00007ffff4b14248 libChakraCore.so
InterpreterThunkEmitter::NewThunkBlock(this=0x00005555558ba3a8) + 24 at InterpreterThunkEmitter.cpp:328325 }
326 #endif
327
-> 328 Assert(this->thunkCount == 0);
329 BYTE* buffer;
330
331 EmitBufferAllocation<VirtualAllocWrapper, PreReservedVirtualAllocWrapper> * allocation = emitBufferManager.AllocateBuffer(BlockSize, &buffer);
(lldb) continue
Process 238376 resuming
Process 238376 stopped
__register_frame, name = 'ch', stop reason = signal SIGSEGV frame #0: 0x00007ffff7126d80 libgcc_s.so.1
__register_framelibgcc_s.so.1`__register_frame:
-> 0x7ffff7126d80 <+0>: movl (%rdi), %eax
0x7ffff7126d82 <+2>: testl %eax, %eax
0x7ffff7126d84 <+4>: jne 0x7ffff7126d90 ; <+16>
0x7ffff7126d86 <+6>: rep
(lldb) bt
__register_frame frame #1: 0x00007ffff4c3ac5c libChakraCore.so
PDataManager::RegisterPdata(pdataStart=0x00007ffff0290fc0, functionStart=140737222606848, functionEnd=140737222610864, pdataTable=0x00007fffffffcd38, entryCount=1, maxEntryCount=1) + 44 at PDataManager.cpp:67frame Revert the original fix to 5424307 #2: 0x00007ffff4b14469 libChakraCore.so
InterpreterThunkEmitter::NewThunkBlock(this=0x00005555558ba3a8) + 569 at InterpreterThunkEmitter.cpp:372 frame #3: 0x00007ffff4b13f9d libChakraCore.so
InterpreterThunkEmitter::GetNextThunk(this=0x00005555558ba3a8, ppDynamicInterpreterThunk=0x00007ffff02ec048) + 413 at InterpreterThunkEmitter.cpp:274frame Add switch to turn off JIT #4: 0x00007ffff4e8cfa4 libChakraCore.so
Js::ScriptContext::GetNextDynamicInterpreterThunk(this=0x00005555558a9c78, ppDynamicInterpreterThunk=0x00007ffff02ec048) + 36 at ScriptContext.cpp:5117 frame #5: 0x00007ffff4e33706 libChakraCore.so
Js::FunctionBody::GenerateDynamicInterpreterThunk(this=0x00007ffff02ec000) + 134 at FunctionBody.cpp:3644frame Remove oldest ES6 feature switches #6: 0x00007ffff4e33c51 libChakraCore.so
Js::FunctionBody::EnsureDynamicInterpreterThunk(this=0x00007ffff02ec000, entryPointInfo=0x00007ffff02b0000) + 1265 at FunctionBody.cpp:3695 frame #7: 0x00007ffff5278ef7 libChakraCore.so
Js::InterpreterStackFrame::EnsureDynamicInterpreterThunk(function=0x00007ffff032c1e0) + 215 at InterpreterStackFrame.cpp:1734frame Allocation failed silently in some AsmJs tests #8: 0x00007ffff553b78c libChakraCore.so
Js::InterpreterStackFrame::DelayDynamicInterpreterThunk(Js::RecyclableObject*, Js::CallInfo, ...) + 12 at amd64_Thunks.S:32 frame #9: 0x00007ffff5909dce libChakraCore.so
amd64_CallFunction + 78 at JavascriptFunctionA.S:100frame [Continuous Integration] Jenkins Daily Build Tasks #10: 0x00007ffff562683d libChakraCore.so
void* Js::JavascriptFunction::CallFunction<true>(function=0x00007ffff032c1e0, entryPoint=(libChakraCore.so
NativeCodeGenerator::CheckCodeGenThunk(Js::RecyclableObject*, Js::CallInfo, ...)), args=Arguments @ 0x00007fffffffd308)(Js::RecyclableObject*, Js::CallInfo, ...), Js::Arguments) + 189 at JavascriptFunction.cpp:1353frame [Continuous Integration] Add check for Microsoft copyright headers in committed files #11: 0x00007ffff561d58d libChakraCore.so
Js::JavascriptFunction::CallRootFunctionInternal(obj=0x00007ffff032c1e0, args=Arguments @ 0x00007fffffffd380, scriptContext=0x00005555558a9c78, inScript=true) + 365 at JavascriptFunction.cpp:742 frame #12: 0x00007ffff561d36c libChakraCore.so
Js::JavascriptFunction::CallRootFunction(obj=0x00007ffff032c1e0, args=, scriptContext=0x00005555558a9c78, inScript=true) + 76 at JavascriptFunction.cpp:689frame Fix build break #13: 0x00007ffff561d314 libChakraCore.so
Js::JavascriptFunction::CallRootFunction(this=0x00007ffff032c1e0, args=<unavailable>, scriptContext=0x00005555558a9c78, inScript=true) + 68 at JavascriptFunction.cpp:797 frame #14: 0x00007ffff47d8c3d libChakraCore.so
RunScriptCore(this=0x00007fffffffd790, scriptContext=0x00005555558a9c78, _actionEntryPopper=0x00007fffffffd770)::$_77::operator()(Js::ScriptContext*, TTD::TTDJsRTActionResultAutoRecorder&) const + 1181 at Jsrt.cpp:3099frame fix bug in reattaching debugger for asm.js #15: 0x00007ffff47d8797 libChakraCore.so
_JsErrorCode ContextAPIWrapper<false, RunScriptCore(void*, unsigned char const*, unsigned long, LoadScriptFlag, unsigned long, char16_t const*, bool, _JsParseScriptAttributes, bool, void**)::$_77>(this=0x00007fffffffd728, scriptContext=0x00005555558a9c78)::$_77)::{lambda(Js::ScriptContext*)#1}::operator()(Js::ScriptContext*) const + 39 at JsrtInternal.h:216 frame #16: 0x00007ffff47d8109 libChakraCore.so
_JsErrorCode ContextAPIWrapper_Core<false, _JsErrorCode ContextAPIWrapper<false, RunScriptCore(void*, unsigned char const*, unsigned long, LoadScriptFlag, unsigned long, char16_t const*, bool, _JsParseScriptAttributes, bool, void**)::$_77>(RunScriptCore(void*, unsigned char const*, unsigned long, LoadScriptFlag, unsigned long, char16_t const*, bool, _JsParseScriptAttributes, bool, void**)::$_77)::{lambda(Js::ScriptContext*)performance tab crashes in f12 on pages with asm.js #1}>(fn=(anonymous class) @ 0x00007fffffffd728)::$_77>(RunScriptCore(void*, unsigned char const*, unsigned long, LoadScriptFlag, unsigned long, char16_t const*, bool, _JsParseScriptAttributes, bool, void**)::$_77)::{lambda(Js::ScriptContext*)performance tab crashes in f12 on pages with asm.js #1}) + 233 at JsrtInternal.h:171frame Adding a new configuration to build binaries for code coverage analysis #17: 0x00007ffff47aa6b6 libChakraCore.so
_JsErrorCode ContextAPIWrapper<false, RunScriptCore(void*, unsigned char const*, unsigned long, LoadScriptFlag, unsigned long, char16_t const*, bool, _JsParseScriptAttributes, bool, void**)::$_77>(fn=(anonymous class) @ 0x00007fffffffd790)::$_77) + 54 at JsrtInternal.h:214 frame #18: 0x00007ffff47aa5c7 libChakraCore.so
RunScriptCore(scriptSource=0x00007ffff02e4000, script="console.log("hello");\n", cb=22, loadScriptFlag=320, sourceContext=0, sourceUrl=u"/home/wosskltest/git/ttt/chakracore/out/debug/hello.js", parseOnly=false, parseAttributes=JsParseScriptAttributeNone, isSourceModule=false, result=0x0000000000000000) + 487 at Jsrt.cpp:3050frame Intl: Add Intl.DateTimeFormat.timeZone #19: 0x00007ffff47acdfe libChakraCore.so
::JsRun(JsValueRef, JsSourceContext, JsValueRef, JsParseScriptAttributes, JsValueRef *) [inlined] CompileRun(scriptVal=0x00007ffff02e4000, sourceContext=0, sourceUrl=0x00007ffff0388f20, parseAttributes=JsParseScriptAttributeNone, result=0x0000000000000000, parseOnly=false) + 179 at Jsrt.cpp:4355 frame #20: 0x00007ffff47acd4b libChakraCore.so
::JsRun(scriptVal=0x00007ffff02e4000, sourceContext=0, sourceUrl=0x00007ffff0388f20, parseAttributes=JsParseScriptAttributeNone, result=0x0000000000000000) + 379 at Jsrt.cpp:4377frame String.prototype.toLowerCase and String.prorotype.toUpperCase built-ins should support unicode #21: 0x000055555555f4ae ch
ChakraRTInterface::JsRun(script=0x00007ffff02e4000, sourceContext=0, sourceUrl=0x00007ffff0388f20, parseAttributes=JsParseScriptAttributeNone, result=0x0000000000000000) + 62 at ChakraRtInterface.h:395 frame #22: 0x000055555555d0ea ch
RunScript(fileName="hello.js", fileContents="console.log("hello");\n", fileContentsFinalizeCallback=(chWScriptJsrt::FinalizeFree(void*) at WScriptJsrt.cpp:164), bufferValue=0x0000000000000000, fullPath="/home/wosskltest/git/ttt/chakracore/out/debug/hello.js")(void*), void*, char*) + 1978 at ch.cpp:450 frame #23: 0x000055555555e41e ch
ExecuteTest(fileName="hello.js") + 3150 at ch.cpp:744frame Exponentiation operator should throw early syntax error for unary negation without parens #24: 0x000055555555e4ec ch
ExecuteTestWithMemoryCheck(fileName="hello.js") + 28 at ch.cpp:794 frame #25: 0x000055555555edc2 ch
main(argc=2, c_argv=0x00007fffffffe4e8) + 2162 at ch.cpp:1084frame Generate fast path for both LdSuper and LdSuperCtor #26: 0x00007ffff6d6b830 libc.so.6
__libc_start_main(main=(ch
main at ch.cpp:895), argc=2, argv=0x00007fffffffe4e8, init=, fini=, rtld_fini=, stack_end=0x00007fffffffe4d8) + 240 at libc-start.c:291frame Object destructuring issue: Initializer on shorthand should not throw syntax error #27: 0x000055555555bd09 ch
_start + 41 (lldb) f 2 frame #2: 0x00007ffff4b14469 libChakraCore.so
InterpreterThunkEmitter::NewThunkBlock(this=0x00005555558ba3a8) + 569 at InterpreterThunkEmitter.cpp:372369 auto block = this->thunkBlocks.PrependNode(allocator, buffer, count);
370 #if PDATA_ENABLED
371 void* pdataTable;
-> 372 PDataManager::RegisterPdata((PRUNTIME_FUNCTION)pdataStart, (ULONG_PTR)buffer, (ULONG_PTR)epilogEnd, &pdataTable);
373 block->SetPdata(pdataTable);
374 #else
375 Unused(block);
We have found root cause of the issue and will submit pull request shortly.
The text was updated successfully, but these errors were encountered: