I hit this crash viewing: https://stackoverflow.com/questions/736513/how-do-i-parse-a-url-into-hostname-and-path-in-javascript It was seemingly random. I don't know how to reproduce it. This is using 2.23.1 (r239394). (gdb) bt full #0 JSC::speculationFromCell (cell=0xe960) at ../Source/JavaScriptCore/runtime/JSCellInlines.h:203 string = <optimized out> impl = <optimized out> #1 0x00007f71130e2f96 in JSC::ValueProfileBase<1u>::computeUpdatedPrediction (this=<optimized out>) at ../Source/JavaScriptCore/runtime/JSCJSValueInlines.h:392 value = <optimized out> i = 0 #2 JSC::CodeBlock::<lambda(JSC::ValueProfile&)>::operator() (__closure=<optimized out>, __closure=<optimized out>, profile=...) at ../Source/JavaScriptCore/bytecode/CodeBlock.cpp:2587 numSamples = <optimized out> numberOfSamplesInProfiles = <optimized out> locker = <optimized out> numberOfLiveNonArgumentValueProfiles = <optimized out> __closure = <optimized out> __closure = <optimized out> profile = <optimized out> locker = <optimized out> numberOfSamplesInProfiles = <optimized out> numberOfLiveNonArgumentValueProfiles = <optimized out> numSamples = <optimized out> numberOfSamplesInProfiles = <optimized out> locker = <optimized out> numberOfLiveNonArgumentValueProfiles = <optimized out> numberOfSamplesInProfiles = <optimized out> locker = <optimized out> numberOfLiveNonArgumentValueProfiles = <optimized out> numSamples = <optimized out> #3 JSC::CodeBlock::<lambda(auto:25&)>::operator()<JSC::OpGetFromScope::Metadata> ( this=<optimized out>, metadata=...) at ../Source/JavaScriptCore/bytecode/CodeBlockInlines.h:44 func = <optimized out> func = <optimized out> #4 JSC::MetadataTable::forEach<JSC::OpGetFromScope, JSC::CodeBlock::forEachValueProfile(const Functor&) [with Functor = JSC::CodeBlock::updateAllPredictionsAndCountLiveness(unsigned int&, unsigned int&)::<lambda(JSC::ValueProfile&)>]::<lambda(auto:25&)> > (func=..., this=<optimized out>) at ../Source/JavaScriptCore/bytecode/MetadataTable.h:61 metadata = <optimized out> end = 0x7f57c3022726 metadata = <optimized out> end = <optimized out> #5 JSC::CodeBlock::forEachValueProfile<JSC::CodeBlock::updateAllPredictionsAndCountLiveness(unsigned int&, unsigned int&)::<lambda(JSC::ValueProfile&)> > (func=..., this=0x7f709c62f300) at ../Source/JavaScriptCore/bytecode/CodeBlockInlines.h:44 No locals. #6 JSC::CodeBlock::updateAllPredictionsAndCountLiveness (this=this@entry=0x7f709c62f300, numberOfLiveNonArgumentValueProfiles=@0x7ffe91191860: 17, numberOfSamplesInProfiles=@0x7ffe91191864: 23) at ../Source/JavaScriptCore/bytecode/CodeBlock.cpp:2576 locker = {<JSC::ConcurrentJSLockerBase> = {<WTF::AbstractLocker> = {<No data fields>}, m_locker = {<WTF::AbstractLocker> = {<No data fields>}, m_lockable = 0x7f709c62f310}}, <No data fields>} #7 0x00007f71130e3675 in JSC::CodeBlock::updateAllValueProfilePredictions (this=this@entry=0x7f709c62f300) at ../Source/JavaScriptCore/bytecode/CodeBlock.cpp:2604 ignoredValue1 = 17 ignoredValue2 = 23 #8 0x00007f71130e3c2d in JSC::CodeBlock::updateAllPredictions (this=this@entry=0x7f709c62f300) at ../Source/JavaScriptCore/bytecode/CodeBlock.cpp:2622 No locals. #9 0x00007f7113648814 in JSC::operationOptimize (exec=0x7ffe91191b90, bytecodeIndex=<optimized out>) at ../Source/JavaScriptCore/jit/JITOperations.cpp:1421 vm = <error reading variable> tracer = <optimized out> deferGC = {m_heap = @0x7f70fc100010} codeBlock = 0x7f709c62f300 debugger = <optimized out> worklist = <optimized out> worklistState = <optimized out> optimizedCodeBlock = <optimized out> #10 0x00007f70b82aa24f in ?? () No symbol table info available. (Plus 55 more frames of "No symbol table info available.") (gdb) info registers rax 0xffff000000000002 -281474976710654 rbx 0x7f57c30224be 140014910579902 rcx 0x179 377 rdx 0x0 0 rsi 0x7ffe91191860 140731332761696 rdi 0xe960 59744 rbp 0x7f57c3022726 0x7f57c3022726 rsp 0x7ffe911917d8 0x7ffe911917d8 r8 0x3f6 1014 r9 0xffffffff 4294967295 r10 0x6 6 r11 0xf895892f 4170549551 r12 0x1 1 r13 0x7f709c62f300 140121636795136 r14 0x34d 845 r15 0xffff000000000002 -281474976710654 rip 0x7f711311f144 0x7f711311f144 <JSC::speculationFromCell(JSC::JSCell*)+4> eflags 0x10246 [ PF ZF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) disassemble Dump of assembler code for function JSC::speculationFromCell(JSC::JSCell*): 0x00007f711311f140 <+0>: endbr64 => 0x00007f711311f144 <+4>: cmpb $0x1,0x5(%rdi) 0x00007f711311f148 <+8>: je 0x7f711311f190 <JSC::speculationFromCell(JSC::JSCell*)+80> 0x00007f711311f14a <+10>: test $0x8,%dil 0x00007f711311f14e <+14>: jne 0x7f711311f180 <JSC::speculationFromCell(JSC::JSCell*)+64> 0x00007f711311f150 <+16>: mov %rdi,%rax 0x00007f711311f153 <+19>: and $0xffffffffffffc000,%rax 0x00007f711311f159 <+25>: mov 0x3ed8(%rax),%rdx 0x00007f711311f160 <+32>: mov (%rdi),%eax 0x00007f711311f162 <+34>: mov 0xe0(%rdx),%rdx 0x00007f711311f169 <+41>: and $0x7fffffff,%eax 0x00007f711311f16e <+46>: mov (%rdx,%rax,8),%rdi 0x00007f711311f172 <+50>: jmpq 0x7f7112ee1790 <_ZN3JSC24speculationFromStructureEPNS_9StructureE@plt> 0x00007f711311f177 <+55>: nopw 0x0(%rax,%rax,1) 0x00007f711311f180 <+64>: mov -0x10(%rdi),%rdx 0x00007f711311f184 <+68>: jmp 0x7f711311f160 <JSC::speculationFromCell(JSC::JSCell*)+32> 0x00007f711311f186 <+70>: nopw %cs:0x0(%rax,%rax,1) 0x00007f711311f190 <+80>: mov 0x10(%rdi),%rax 0x00007f711311f194 <+84>: test %rax,%rax 0x00007f711311f197 <+87>: je 0x7f711311f1b8 <JSC::speculationFromCell(JSC::JSCell*)+120> 0x00007f711311f199 <+89>: mov 0x10(%rax),%eax 0x00007f711311f19c <+92>: and $0x10,%eax 0x00007f711311f19f <+95>: cmp $0x1,%eax 0x00007f711311f1a2 <+98>: sbb %rax,%rax 0x00007f711311f1a5 <+101>: and $0x1000000,%eax 0x00007f711311f1aa <+106>: add $0x1000000,%rax 0x00007f711311f1b0 <+112>: retq 0x00007f711311f1b1 <+113>: nopl 0x0(%rax) 0x00007f711311f1b8 <+120>: mov $0x2000000,%eax 0x00007f711311f1bd <+125>: retq End of assembler dump. Similar crashes: bug #131506, bug #160027.
(In reply to Michael Catanzaro from comment #0) > It was seemingly random. I don't know how to reproduce it. This is using > 2.23.1 (r239394). Sorry, wrong revision. It's r238442.
Seems likely to be a duplicate of bug 192050, can you check with a newer version?
No, because it's not reproducible, but the timeline matches up so let's assume it's a duplicate unless proven otherwise. *** This bug has been marked as a duplicate of bug 192050 ***