WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
170945
RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians
https://bugs.webkit.org/show_bug.cgi?id=170945
Summary
RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians
Tomas Popela
Reported
2017-04-18 07:33:46 PDT
We need to static cast the operand value to the PutByIdFlags as we actually do for UnlinkedInstructions.
Attachments
Patch
(1.50 KB, patch)
2017-04-18 07:42 PDT
,
Tomas Popela
no flags
Details
Formatted Diff
Diff
Patch
(1.39 KB, patch)
2017-05-31 07:40 PDT
,
Tomas Popela
mark.lam
: review+
buildbot
: commit-queue-
Details
Formatted Diff
Diff
Archive of layout-test-results from ews121 for ios-simulator-wk2
(33.44 MB, application/zip)
2017-05-31 11:22 PDT
,
Build Bot
no flags
Details
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Tomas Popela
Comment 1
2017-04-18 07:42:23 PDT
Created
attachment 307383
[details]
Patch
Tomas Popela
Comment 2
2017-05-22 05:04:54 PDT
ping reviewers..
Mark Lam
Comment 3
2017-05-22 09:29:14 PDT
Comment on
attachment 307383
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=307383&action=review
> Source/JavaScriptCore/bytecode/BytecodeDumper.cpp:65 > - return instruction.u.putByIdFlags; > + return static_cast<PutByIdFlags>(instruction.u.operand);
Why is this needed? instruction.u.putByIdFlags is set using the Instruction(PutByIdFlags flags) constructor which does u.putByIdFlags = flags;. The endianness should always be correct. Can you clarify what the problem is and how this fixes it?
Mark Lam
Comment 4
2017-05-22 09:30:55 PDT
Comment on
attachment 307383
[details]
Patch r- because it is not clear what the issue and how this patch fixes it.
Tomas Popela
Comment 5
2017-05-23 01:57:01 PDT
(In reply to Mark Lam from
comment #3
)
> Comment on
attachment 307383
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=307383&action=review
> > > Source/JavaScriptCore/bytecode/BytecodeDumper.cpp:65 > > - return instruction.u.putByIdFlags; > > + return static_cast<PutByIdFlags>(instruction.u.operand); > > Why is this needed? instruction.u.putByIdFlags is set using the > Instruction(PutByIdFlags flags) constructor which does u.putByIdFlags = > flags;. The endianness should always be correct. Can you clarify what the > problem is and how this fixes it?
As I said in the subject without this JSC crashes: WebKitBuild/Debug/bin/jsc --useJIT=false --dumpGeneratedBytecodes=true --dumpBytecodeLivenessResults=true --validateBytecode=true --verboseCompilation=true ~/make-functions.js results in: <global>#DJgDW6:[0x1001d3880a0->0x1001d33b120, NoneGlobal, 606]: 606 m_instructions; 4848 bytes; 1 parameter(s); 12 callee register(s); 2 variable(s); scope at loc0 [ 0] enter [ 1] get_scope loc0 [ 3] mov loc1, loc0 [ 6] check_traps [ 7] new_func loc2, loc0, f0 [ 11] resolve_scope loc3, loc0, output_param(@id0), <GlobalVar>, 1, 0x1001d2a80a0 [ 18] mov loc4, loc3 [ 21] put_to_scope loc4, output_param(@id0), loc2, 2049<ThrowIfNotFound|GlobalVar|NotInitialization>, <structure>, 1100001529960 [ 28] new_func loc2, loc0, f1 [ 32] put_to_scope loc4, output_function(@id1), loc2, 2049<ThrowIfNotFound|GlobalVar|NotInitialization>, <structure>, 1100001529968 [ 39] mov loc2, Undefined(const0) [ 42] resolve_scope loc3, loc0, funcs(@id2), <UnresolvedProperty>, 0, (nil) [ 49] new_object loc4, 5 [ 53] put_by_id loc4, id(@id3), String (atomic) (identifier): readline-readline, ID: 4(const1), SHOULD NEVER BE REACHED ../../Source/JavaScriptCore/runtime/InferredType.cpp(129) : static JSC::InferredType::Kind JSC::InferredType::kindForFlags(JSC::PutByIdFlags) 1 0x3fffae6f18b0 WTFCrash 2 0x3fffae34e210 JSC::InferredType::kindForFlags(JSC::PutByIdFlags) 3 0x3fffade1441c WTF::printInternal(WTF::PrintStream&, JSC::PutByIdFlags) 4 0x3fffadd738f8 void WTF::PrintStream::printImpl<JSC::PutByIdFlags>(JSC::PutByIdFlags const&) 5 0x3fffadd71e38 void WTF::PrintStream::printImpl<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&) 6 0x3fffadd6fc54 void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&)::{lambda(WTF::PrintStream&)#1}::operator()(WTF::PrintStream&) const 7 0x3fffadd71ebc void WTF::PrintStream::atomically<void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&)::{lambda(WTF::PrintStream&)#1}>(void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&)::{lambda(WTF::PrintStream& )#1} const&) 8 0x3fffadd6fcbc void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&) 9 0x3fffadd63528 JSC::BytecodeDumper<JSC::CodeBlock>::printPutByIdCacheStatus(WTF::PrintStream&, int, WTF::HashMap<JSC::CodeOrigin, JSC::StructureStubInfo*, JSC::CodeOriginApproximateHash, WTF::HashTraits<JSC::CodeOrigin>, WTF::HashTraits<JSC::StructureStubInfo*> > const&) 10 0x3fffadd666c8 JSC::BytecodeDumper<JSC::CodeBlock>::dumpBytecode(WTF::PrintStream&, JSC::Instruction const*, JSC::Instruction const*&, WTF::HashMap<JSC::CodeOrigin, JSC::StructureStubInfo*, JSC::CodeOriginApproximateHash, WTF::HashTraits<JSC::CodeOrigin>, WTF::HashTraits<JSC::StructureStubInfo*> > const&, WTF::Has hMap<int, void*, WTF::IntHash<unsigned int>, WTF::HashTraits<int>, WTF::HashTraits<void*> > const&) 11 0x3fffadd61e34 JSC::BytecodeDumper<JSC::CodeBlock>::dumpBlock(JSC::CodeBlock*, WTF::RefCountedArray<JSC::Instruction>&, WTF::PrintStream&, WTF::HashMap<JSC::CodeOrigin, JSC::StructureStubInfo*, JSC::CodeOriginApproximateHash, WTF::HashTraits<JSC::CodeOrigin>, WTF::HashTraits<JSC::StructureStubInfo*> > const&, WTF: :HashMap<int, void*, WTF::IntHash<unsigned int>, WTF::HashTraits<int>, WTF::HashTraits<void*> > const&) 12 0x3fffadda8d08 JSC::CodeBlock::dumpBytecode(WTF::PrintStream&) 13 0x3fffadda8c4c JSC::CodeBlock::dumpBytecode() 14 0x3fffaddacc88 JSC::CodeBlock::finishCreation(JSC::VM&, JSC::ScriptExecutable*, JSC::UnlinkedCodeBlock*, JSC::JSScope*) 15 0x3fffae57a64c JSC::ProgramCodeBlock::create(JSC::VM*, JSC::ProgramExecutable*, JSC::UnlinkedProgramCodeBlock*, JSC::JSScope*, WTF::RefPtr<JSC::SourceProvider>&&, unsigned int) 16 0x3fffae57894c JSC::ScriptExecutable::newCodeBlockFor(JSC::CodeSpecializationKind, JSC::JSFunction*, JSC::JSScope*, JSC::JSObject*&) 17 0x3fffae579528 JSC::ScriptExecutable::prepareForExecutionImpl(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC::CodeSpecializationKind, JSC::CodeBlock*&) 18 0x3fffae0947f4 JSC::JSObject* JSC::ScriptExecutable::prepareForExecution<JSC::ProgramExecutable>(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC::CodeSpecializationKind, JSC::CodeBlock*&) 19 0x3fffae08aa54 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*) 20 0x3fffae302930 JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) 21 0x1005df50 22 0x1005f440 23 0x10061ef0 24 0x1005f528 jscmain(int, char**) 25 0x1005c800 main 26 0x3fffaa9e4b88 27 0x3fffaa9e4db8 __libc_start_main Segmentation fault (core dumped)
Mark Lam
Comment 6
2017-05-23 07:23:08 PDT
Comment on
attachment 307383
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=307383&action=review
>>> Source/JavaScriptCore/bytecode/BytecodeDumper.cpp:65 >>> + return static_cast<PutByIdFlags>(instruction.u.operand); >> >> Why is this needed? instruction.u.putByIdFlags is set using the Instruction(PutByIdFlags flags) constructor which does u.putByIdFlags = flags;. The endianness should always be correct. Can you clarify what the problem is and how this fixes it? > > As I said in the subject without this JSC crashes: > > WebKitBuild/Debug/bin/jsc --useJIT=false --dumpGeneratedBytecodes=true --dumpBytecodeLivenessResults=true --validateBytecode=true --verboseCompilation=true ~/make-functions.js > > results in: > > <global>#DJgDW6:[0x1001d3880a0->0x1001d33b120, NoneGlobal, 606]: 606 m_instructions; 4848 bytes; 1 parameter(s); 12 callee register(s); 2 variable(s); scope at loc0 > [ 0] enter > [ 1] get_scope loc0 > [ 3] mov loc1, loc0 > [ 6] check_traps > [ 7] new_func loc2, loc0, f0 > [ 11] resolve_scope loc3, loc0, output_param(@id0), <GlobalVar>, 1, 0x1001d2a80a0 > [ 18] mov loc4, loc3 > [ 21] put_to_scope loc4, output_param(@id0), loc2, 2049<ThrowIfNotFound|GlobalVar|NotInitialization>, <structure>, 1100001529960 > [ 28] new_func loc2, loc0, f1 > [ 32] put_to_scope loc4, output_function(@id1), loc2, 2049<ThrowIfNotFound|GlobalVar|NotInitialization>, <structure>, 1100001529968 > [ 39] mov loc2, Undefined(const0) > [ 42] resolve_scope loc3, loc0, funcs(@id2), <UnresolvedProperty>, 0, (nil) > [ 49] new_object loc4, 5 > [ 53] put_by_id loc4, id(@id3), String (atomic) (identifier): readline-readline, ID: 4(const1), SHOULD NEVER BE REACHED > ../../Source/JavaScriptCore/runtime/InferredType.cpp(129) : static JSC::InferredType::Kind JSC::InferredType::kindForFlags(JSC::PutByIdFlags) > 1 0x3fffae6f18b0 WTFCrash > 2 0x3fffae34e210 JSC::InferredType::kindForFlags(JSC::PutByIdFlags) > 3 0x3fffade1441c WTF::printInternal(WTF::PrintStream&, JSC::PutByIdFlags) > 4 0x3fffadd738f8 void WTF::PrintStream::printImpl<JSC::PutByIdFlags>(JSC::PutByIdFlags const&) > 5 0x3fffadd71e38 void WTF::PrintStream::printImpl<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&) > 6 0x3fffadd6fc54 void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&)::{lambda(WTF::PrintStream&)#1}::operator()(WTF::PrintStream&) const > 7 0x3fffadd71ebc void WTF::PrintStream::atomically<void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&)::{lambda(WTF::PrintStream&)#1}>(void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&)::{lambda(WTF::PrintStream& > )#1} const&) > 8 0x3fffadd6fcbc void WTF::PrintStream::print<char [3], JSC::PutByIdFlags>(char const (&) [3], JSC::PutByIdFlags const&) > 9 0x3fffadd63528 JSC::BytecodeDumper<JSC::CodeBlock>::printPutByIdCacheStatus(WTF::PrintStream&, int, WTF::HashMap<JSC::CodeOrigin, JSC::StructureStubInfo*, JSC::CodeOriginApproximateHash, WTF::HashTraits<JSC::CodeOrigin>, WTF::HashTraits<JSC::StructureStubInfo*> > const&) > 10 0x3fffadd666c8 JSC::BytecodeDumper<JSC::CodeBlock>::dumpBytecode(WTF::PrintStream&, JSC::Instruction const*, JSC::Instruction const*&, WTF::HashMap<JSC::CodeOrigin, JSC::StructureStubInfo*, JSC::CodeOriginApproximateHash, WTF::HashTraits<JSC::CodeOrigin>, WTF::HashTraits<JSC::StructureStubInfo*> > const&, WTF::Has > hMap<int, void*, WTF::IntHash<unsigned int>, WTF::HashTraits<int>, WTF::HashTraits<void*> > const&) > 11 0x3fffadd61e34 JSC::BytecodeDumper<JSC::CodeBlock>::dumpBlock(JSC::CodeBlock*, WTF::RefCountedArray<JSC::Instruction>&, WTF::PrintStream&, WTF::HashMap<JSC::CodeOrigin, JSC::StructureStubInfo*, JSC::CodeOriginApproximateHash, WTF::HashTraits<JSC::CodeOrigin>, WTF::HashTraits<JSC::StructureStubInfo*> > const&, WTF: > :HashMap<int, void*, WTF::IntHash<unsigned int>, WTF::HashTraits<int>, WTF::HashTraits<void*> > const&) > 12 0x3fffadda8d08 JSC::CodeBlock::dumpBytecode(WTF::PrintStream&) > 13 0x3fffadda8c4c JSC::CodeBlock::dumpBytecode() > 14 0x3fffaddacc88 JSC::CodeBlock::finishCreation(JSC::VM&, JSC::ScriptExecutable*, JSC::UnlinkedCodeBlock*, JSC::JSScope*) > 15 0x3fffae57a64c JSC::ProgramCodeBlock::create(JSC::VM*, JSC::ProgramExecutable*, JSC::UnlinkedProgramCodeBlock*, JSC::JSScope*, WTF::RefPtr<JSC::SourceProvider>&&, unsigned int) > 16 0x3fffae57894c JSC::ScriptExecutable::newCodeBlockFor(JSC::CodeSpecializationKind, JSC::JSFunction*, JSC::JSScope*, JSC::JSObject*&) > 17 0x3fffae579528 JSC::ScriptExecutable::prepareForExecutionImpl(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC::CodeSpecializationKind, JSC::CodeBlock*&) > 18 0x3fffae0947f4 JSC::JSObject* JSC::ScriptExecutable::prepareForExecution<JSC::ProgramExecutable>(JSC::VM&, JSC::JSFunction*, JSC::JSScope*, JSC::CodeSpecializationKind, JSC::CodeBlock*&) > 19 0x3fffae08aa54 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::ExecState*, JSC::JSObject*) > 20 0x3fffae302930 JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&) > 21 0x1005df50 > 22 0x1005f440 > 23 0x10061ef0 > 24 0x1005f528 jscmain(int, char**) > 25 0x1005c800 main > 26 0x3fffaa9e4b88 > 27 0x3fffaa9e4db8 __libc_start_main > Segmentation fault (core dumped)
Tomas, the original code was returning instruction.u.putByIdFlags which is of type PutByIdFlags. Therefore, it should not need a cast because it is already of type PutByIdFlags. From my casual grepping of the code, this field should always be assigned via the instruction.u.putByIdFlags field (which should put the bits in the order you want). Hence, the bits in it should already be in the correct order/ endianness. To clarify, I'm not disputing that you saw a crash. My concern is that I think your fix is wrong. The fact that reason you saw the wrong endian bits here implies that this value was not set using the instruction.u.putByIdFlags field somewhere else. That is the real bug that should be fixed. Otherwise, you are only band-aiding one symptom of the issue, and the bug may still exists (the stored bits are still of the wrong endianness) and may come back to bite you in a less detectable place. Does this make sense?
Tomas Popela
Comment 7
2017-05-23 08:37:28 PDT
(In reply to Mark Lam from
comment #6
)
> Comment on attach> Tomas, the original code was returning instruction.u.putByIdFlags which is > of type PutByIdFlags. Therefore, it should not need a cast because it is > already of type PutByIdFlags. From my casual grepping of the code, this > field should always be assigned via the instruction.u.putByIdFlags field > (which should put the bits in the order you want). Hence, the bits in it > should already be in the correct order/ endianness. To clarify, I'm not > disputing that you saw a crash. My concern is that I think your fix is > wrong. The fact that reason you saw the wrong endian bits here implies that > this value was not set using the instruction.u.putByIdFlags field somewhere > else.
I don't know if it could be the cause, but the flag is initially set to the UnlinkedInstruction's operand in
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp?rev=217275#L2760
then it is copied to the Instruction's operand in
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/bytecode/CodeBlock.cpp?rev=217275#L534
. I suppose it should be set with u.putByIdFlags, but the code is general to just copy the operands from the UnlinkedInstruction to the Instruction.
> That is the real bug that should be fixed. Otherwise, you are only > band-aiding one symptom of the issue, and the bug may still exists (the > stored bits are still of the wrong endianness) and may come back to bite you > in a less detectable place. > > Does this make sense?
Yes, it does make sense.
Tomas Popela
Comment 8
2017-05-23 08:41:34 PDT
And it indeed looks like: (gdb) p instructions[i+j].u $24 = {opcode = 0x100000000, operand = 1, unsignedValue = 1, structure = {m_cell = 0x100000000}, structureID = 1, symbolTable = {m_cell = 0x100000000}, structureChain = {m_cell = 0x100000000}, jsCell = {m_cell = 0x100000000}, variablePointer = 0x100000000, specialPointer = JSC::Special::ApplyFunction, getterFunc = 0x100000000, callLinkInfo = 0x100000000, uid = 0x100000000, profile = 0x100000000, arrayProfile = 0x100000000, arrayAllocationProfile = 0x100000000, objectAllocationProfile = 0x100000000, watchpointSet = 0x100000000, pointer = 0x100000000, predicatePointer = 0x100000000, toThisStatus = JSC::ToThisConflicted, location = 0x100000000, basicBlockLocation = 0x100000000, putByIdFlags = 4294967296} (gdb) p instructions[i+j].u.putByIdFlags $25 = 4294967296 (gdb) p/t instructions[i+j].u.putByIdFlags $26 = 100000000000000000000000000000000 the original value was PutByIdIsDirect = 0x1 (in
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp?rev=217275#L2760
) then it was 1..
Mark Lam
Comment 9
2017-05-23 09:54:07 PDT
(In reply to Tomas Popela from
comment #8
)
> And it indeed looks like: > > (gdb) p instructions[i+j].u > $24 = {opcode = 0x100000000, operand = 1, unsignedValue = 1, structure = > {m_cell = 0x100000000}, structureID = 1, symbolTable = {m_cell = > 0x100000000}, > structureChain = {m_cell = 0x100000000}, jsCell = {m_cell = 0x100000000}, > variablePointer = 0x100000000, specialPointer = JSC::Special::ApplyFunction, > getterFunc = 0x100000000, callLinkInfo = 0x100000000, uid = 0x100000000, > profile = 0x100000000, arrayProfile = 0x100000000, > arrayAllocationProfile = 0x100000000, objectAllocationProfile = > 0x100000000, watchpointSet = 0x100000000, pointer = 0x100000000, > predicatePointer = 0x100000000, toThisStatus = JSC::ToThisConflicted, > location = 0x100000000, basicBlockLocation = 0x100000000, putByIdFlags = > 4294967296} > (gdb) p instructions[i+j].u.putByIdFlags > $25 = 4294967296 > (gdb) p/t instructions[i+j].u.putByIdFlags > $26 = 100000000000000000000000000000000 > > the original value was PutByIdIsDirect = 0x1 (in >
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/
> bytecompiler/BytecodeGenerator.cpp?rev=217275#L2760 ) then it was 1..
You need to do some debugging to see who put the wrong value in there.
Tomas Popela
Comment 10
2017-05-23 11:28:03 PDT
(In reply to Mark Lam from
comment #9
)
> You need to do some debugging to see who put the wrong value in there.
As I wrote previously that value is assigned here:
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/bytecode/CodeBlock.cpp?rev=217275#L534
Mark Lam
Comment 11
2017-05-23 11:38:44 PDT
(In reply to Tomas Popela from
comment #10
)
> (In reply to Mark Lam from
comment #9
) > > You need to do some debugging to see who put the wrong value in there. > > As I wrote previously that value is assigned here: >
https://trac.webkit.org/browser/webkit/trunk/Source/JavaScriptCore/bytecode/
> CodeBlock.cpp?rev=217275#L534
Please investigate further. In CodeBlock.cpp:534, it's doing: instructions[i + j].u.operand = pc[j].u.operand; If the original unlinked operand was initialized properly, then this would been a copy of the value 4294967296, which when read using pc[i].u.putByIdFlags would yield 1. The only thing that you've shown so far is that the bug happened upstream. You need to debug this further and find out why the unlinked version of the operand has the wrong value.
Tomas Popela
Comment 12
2017-05-24 00:21:34 PDT
(In reply to Mark Lam from
comment #11
)
> If the original unlinked operand was initialized properly, then this would > been a copy of the value 4294967296, which when read using > pc[i].u.putByIdFlags would yield 1.
Sorry I'm probably missing something here. But how can you copy a value of 4294967296 if operand in the UnlinkedInstruction is int32_t?
Mark Lam
Comment 13
2017-05-24 11:46:11 PDT
(In reply to Tomas Popela from
comment #12
)
> (In reply to Mark Lam from
comment #11
) > > If the original unlinked operand was initialized properly, then this would > > been a copy of the value 4294967296, which when read using > > pc[i].u.putByIdFlags would yield 1. > > Sorry I'm probably missing something here. But how can you copy a value of > 4294967296 if operand in the UnlinkedInstruction is int32_t?
I see. I missed the part where 4294967296 is 1 bit above 32-bits. Anyway, I still stand by my statement that the issue lies upstream and your patch is still the wrong thing to do for the solution. The question you should ask is: why a PutByIdFlags value that is encodable in an UnlinkedInstruction (of size 32-bit) would get encoded as a 64-bit value in the resultant bytecode Instruction operand? Hint: check how PutByIdFlags is defined.
Tomas Popela
Comment 14
2017-05-31 07:32:49 PDT
(In reply to Mark Lam from
comment #13
)
> Hint: check how PutByIdFlags is defined.
Ah, yeah, thank you for the hint Mark! :)
Tomas Popela
Comment 15
2017-05-31 07:40:36 PDT
Created
attachment 311587
[details]
Patch
Build Bot
Comment 16
2017-05-31 11:22:08 PDT
Comment on
attachment 311587
[details]
Patch
Attachment 311587
[details]
did not pass ios-sim-ews (ios-simulator-wk2): Output:
http://webkit-queues.webkit.org/results/3849040
New failing tests: webrtc/peer-connection-audio-mute.html
Build Bot
Comment 17
2017-05-31 11:22:11 PDT
Created
attachment 311613
[details]
Archive of layout-test-results from ews121 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.5
Mark Lam
Comment 18
2017-05-31 11:47:01 PDT
Comment on
attachment 311587
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=311587&action=review
r=me with suggestion.
> Source/JavaScriptCore/ChangeLog:10 > + Define the PutByIdFlags type as int32_t as its value is clobbered on > + 64-bit big endian arches when saved through UnlinkedInstruction's > + operand that is defined as int32_t.
I would say something like: "Re-define PutByIdFlags as a int32_t enum explicitly because it is stored as an int32_t value in UnlinkedInstruction. This prevents a bug on 64-bit big endian architectures where the word order is inverted (when we convert the UnlinkedInstruction into a CodeBlock Instruction), resulting in the PutByIdFlags value not being stored in the 32-bit word that the rest of the code expects it to be in."
Tomas Popela
Comment 19
2017-06-01 01:22:26 PDT
Committed
r217650
: <
http://trac.webkit.org/changeset/217650
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug