Certificates and websockets #2
Comments
|
Solved in Metrological/buildroot@f25205b |
zdobersek
pushed a commit
that referenced
this issue
Oct 8, 2015
https://bugs.webkit.org/show_bug.cgi?id=149654 Reviewed by Geoffrey Garen. Source/JavaScriptCore: I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432). Concurrent GC require barriers to be executed during certain heap operations. We already have a generational GC. Generational GCs also need barriers, and we already have those. The generational GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get reset. If the sticky mark bit is set in between two collections, then we know that the object is in old space. This is sufficient to determine when to put things into remembered sets. Additionally, the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on a remembered set. This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes to the heap that change the object graph to do different things depending on an object's marking state, which is usually referred to as its color. White means that the object has never been seen by the collector. All white objects are presumed dead at the flip. Grey objects are those that are known to the collector but have not been scanned. Black objects are those that have been scanned, and will not be scanned again. White is exactly just "not being marked", and both grey and black mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the current "Marked" and "MarkedAndRemembered" states that we have for generational GC. "MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black". I want to make a concurrent GC that unifies the generational and concurrent barriers into a single fast path check. Even better if the two barriers are entirely identical. You can do this using Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC "rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack, setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit. This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and generational, and we want to basically keep our current barriers unchanged. The only things missing are just some small changes to allow the concurrent GC to know precisely when an object is black, and to know during object visiting if we are visiting the object for the first time during a collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering (generational GC). So, this patch does the following: - Changes the terminology used for the gcData header byte in JSCell. This changes the name of this to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a lot like the old GCData did. It has the following members, with the following correspondence to the old GCData: OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack as soon as the object starts to be scanned. Previously, an object might be MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked objects during a post-processing step at the end of GC. This patch gets rid of that post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that our definition of "black" is not that the object is done being scanned, but that it is either being scanned right now or it has already been scanned. This is like a combination of Siebert's anthracite and black states [3]. NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated. It's impossible for an object to return to this state. OldGrey: the object is on the mark stack and will be scanned at some point in the future. This also means that this isn't the first time in this cycle that the object has been grey. In an eden collection, an old object that has been remembered is thought of as being OldGrey, even if this is the first time during this eden collection that it is grey. That's because an eden collection must behave "as if" the grey->black transition for old objects magically happened at the start of GC. Remembered objects are like old objects that underwent a concurrent barrier re-greying just after the magical old object grey->black transition at the start of GC. This state is almost exactly like MarkedAndRemembered, except that an object now transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously we transitioned from MarkedAndRemembered to Marked at the bitter end of GC. NewGray: the object is on the mark stack and will be scanned at some point in the future. This state has no clear relative in the old state system. It means that the object became grey due to ordinary marking. Previously, ordinary marking would make the object Marked. - Removal of the post-processing phase that "clears" the remembered set by moving all remembered objects to the Marked state. This now happens magically during visiting, as described above. - SlotVisitor now remembers the state that the object did have just before visiting. While visiting that object, it's possible to query what the state was. This is used for copy space decisions and for extra memory usage accounting. We don't want to put the backing store on the copy worklist, and we don't want to count extra memory usage, if the object was OldGrey at the start of visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since that state wouldn't get cleared until after all marking finished. This change also simplifies some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods no longer ask the cell for its state - instead they use the saved pre-visiting state. - Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if an object was "marked" and if an object was "remembered". We had helpers for adjusting these states, and those helpers would assert that they were being used the right way. This is not very useful for concurrent GC, since now the set of possible state transitions is much larger. Also, the previous use of the word "marked" was pretty bad - for example in Heap, "marked" refers to the primary mark bit (that gets cleared at the flip), while in JSCell, "marked" refers to the sticky mark bit (that does not get cleared, ever). This change gets rid of a lot of those helpers and inlines their logic. This actually makes the code easier and more fun to read, since you can now look at the marking and barrier code and see how that code uses the four CellStates. For example, it's fun to see that the barrier gets fired for o.f=v exactly when o is OldBlack and v is NewWhite. This change shouldn't have any effect on performance or GC behavior. It does put our code in a weird state where we now have states and comments referencing a concurrent GC that doesn't exist yet. Finally, some thoughts about the concurrent GC barrier and its implications for performance. This barrier exhibits very poor guarantees about collector progress, but maximizes throughput by just reusing the existing barrier code we already emit and optimize. I believe that even our epoch-based barrier insertion DFG phase is correct for the concurrent interpretation of our existing barrier. But, the barrier can regress the progress that the collector has made for two reasons: Incremental update: you don't want to use this barrier with a black stack, since that would mean that heap loads of white objects will have to explicitly re-grey the stack. The way you implement this kind of collector is that collector termination will rescan the stack. Termination is reached only if the at-termination re-scan greys no objects. This means that the collector is a fixpoint. Luckily, our collector is already a fixpoint because of opaque roots and structure transitions. Marking ain't monotonic: normally, once an object is black, it stays that way. In this collector, black objects may become grey again. I don't have personal experience with such concurrent GCs, but I suspect that this will basically be fine. Concurrent collections finish pretty quickly, and the mutator usually touches only a subset of the heap. Only that subset of the heap that the mutator is touching could be re-greyed. Probably, the GC will have to be hybrid incremental and concurrent, and towards the end of GC when we do the termination stack re-scan, we can ensure that the collector does some minimal amount of marking. If the minimal amount of marking done by the collector is large enough, we can ensure that we reach termination before the mutator can regress progress. The barrier cannot un-terminate the collector; if the collector reaches termination and the barrier re-greys an object then it's actually doing a generational remembering rather than a concurrent re-greying. That's sort of the cute thing about the barrier - it is exactly a re-greying barrier during GC and it is exactly a remembering barrier in between GCs. [1] http://www.cs.utexas.edu/ftp/garbage/submit/readable/ppirinen11.ps [2] http://dl.acm.org/citation.cfm?id=361005 [3] http://www.aicas.com/papers/ISMM132-siebert.pdf * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: * JavaScriptCore.xcodeproj/project.pbxproj: * bytecode/CodeBlock.cpp: (JSC::CodeBlock::visitChildren): * ftl/FTLAbstractHeapRepository.cpp: (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository): * ftl/FTLAbstractHeapRepository.h: * ftl/FTLLowerDFGToLLVM.cpp: (JSC::FTL::DFG::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid): (JSC::FTL::DFG::LowerDFGToLLVM::loadCellState): (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier): (JSC::FTL::DFG::LowerDFGToLLVM::loadMarkByte): Deleted. * heap/CellState.h: Added. * heap/CodeBlockSet.cpp: (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks): * heap/CopiedBlock.h: * heap/CopiedBlockInlines.h: (JSC::CopiedBlock::reportLiveBytes): (JSC::CopiedBlock::shouldReportLiveBytes): Deleted. * heap/GCLogging.cpp: (JSC::LoggingFunctor::reviveCells): * heap/Heap.cpp: (JSC::Heap::markRoots): (JSC::Heap::visitWeakHandles): (JSC::Heap::updateObjectCounts): (JSC::Heap::addToRememberedSet): (JSC::Heap::clearRememberedSet): Deleted. * heap/Heap.h: * heap/HeapInlines.h: (JSC::Heap::isLive): (JSC::Heap::isMarked): (JSC::Heap::writeBarrier): (JSC::Heap::reportExtraMemoryAllocated): (JSC::Heap::reportExtraMemoryVisited): (JSC::Heap::isRemembered): Deleted. * heap/SlotVisitor.cpp: (JSC::SlotVisitor::append): (JSC::SlotVisitor::visitChildren): (JSC::SlotVisitor::donateKnownParallel): (JSC::SlotVisitor::drain): (JSC::visitChildren): Deleted. * heap/SlotVisitor.h: (JSC::SlotVisitor::childCount): (JSC::SlotVisitor::incrementChildCount): (JSC::SlotVisitor::dataBeforeVisitingCurrentObject): * heap/SlotVisitorInlines.h: (JSC::SlotVisitor::internalAppend): (JSC::SlotVisitor::copyLater): (JSC::SlotVisitor::reportExtraMemoryVisited): (JSC::SlotVisitor::heap): * jit/AssemblyHelpers.h: (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/JSCell.h: (JSC::JSCell::cellState): (JSC::JSCell::setCellState): (JSC::JSCell::structureIDOffset): (JSC::JSCell::indexingTypeOffset): (JSC::JSCell::cellStateOffset): (JSC::JSCell::setMarked): Deleted. (JSC::JSCell::setRemembered): Deleted. (JSC::JSCell::isMarked): Deleted. (JSC::JSCell::isRemembered): Deleted. (JSC::JSCell::gcDataOffset): Deleted. * runtime/JSCellInlines.h: (JSC::JSCell::JSCell): * runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): * runtime/JSObject.cpp: (JSC::JSObject::copyBackingStore): * runtime/JSString.cpp: (JSC::JSString::visitChildren): * runtime/StructureIDBlob.h: (JSC::StructureIDBlob::StructureIDBlob): (JSC::StructureIDBlob::operator=): * runtime/WeakMapData.cpp: (JSC::WeakMapData::visitChildren): (JSC::WeakMapData::set): * tests/stress/basic-eden-gc-test.js: Added. Hilariously, an earlier version of this patch that didn't have the NewGrey/OldGrey distinction would only crash super-big tests that GCd twice but it didn't crash any small focused test. All it took to show the need for the NewGrey/OldGrey distinction was this super simple test. Source/WebCore: No new tests because no new behavior. * bindings/scripts/CodeGeneratorJS.pm: (GenerateImplementation): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@190569 268f45cc-cd09-0410-ab3c-d52691b4dbfc
vertexodessa
pushed a commit
to vertexodessa/WebKitForWayland
that referenced
this issue
Jul 15, 2016
https://bugs.webkit.org/show_bug.cgi?id=156603 <rdar://problem/25736205> Patch by Benjamin Poulain <bpoulain@apple.com> on 2016-04-17 Reviewed by Saam Barati and Filip Pizlo. This patch extends B3's ReduceDoubleToFloat phase to work accross Upsilon-Phis. This is important to optimize loops and some crazy cases. In its simplest form, we can have conversion propagated from something like this: Double @1 = Phi() Float @2 = DoubleToFloat(@1) When that happens, we just need to propagate that the result only need float precision accross all values coming to this Phi. There are more complicated cases when the value produced is effectively Float but the user of the value does not do DoubleToFloat. Typically, we have something like: WebPlatformForEmbedded#1 @1 = ConstDouble(1) @2 = Upsilon(@1, ^5) WebPlatformForEmbedded#2 @3 = FloatToDouble(@x) @4 = Upsilon(@3, ^5) WebPlatformForEmbedded#3 @5 = Phi() @6 = Add(@5, @somethingFloat) @7 = DoubleToFloat(@6) Here with a Phi-Upsilon that is a Double but can be represented as Float without loss of precision. It is valuable to convert such Phis to float if and only if the value is used as float. Otherwise, you may be just adding useless conversions (for example, two double constants that flow into a double Add should not turn into two float constant flowing into a FloatToDouble then Add). ReduceDoubleToFloat do two analysis passes to gather the necessary meta information. Then we have a simplify() phase to actually reduce operation. Finally, the cleanup() pass put the graph into a valid state again. The two analysis passes work by disproving that something is float. -findCandidates() accumulates anything used as Double. -findPhisContainingFloat() accumulates phis that would lose precision by converting the input to float. With this change, Unity3D improves by ~1.5%, box2d-f32 improves by ~2.8% (on Haswell). * b3/B3ReduceDoubleToFloat.cpp: (JSC::B3::reduceDoubleToFloat): * b3/testb3.cpp: (JSC::B3::testCompareTwoFloatToDouble): (JSC::B3::testCompareOneFloatToDouble): (JSC::B3::testCompareFloatToDoubleThroughPhi): (JSC::B3::testDoubleToFloatThroughPhi): (JSC::B3::testDoubleProducerPhiToFloatConversion): (JSC::B3::testDoubleProducerPhiToFloatConversionWithDoubleConsumer): (JSC::B3::testDoubleProducerPhiWithNonFloatConst): (JSC::B3::testStoreDoubleConstantAsFloat): (JSC::B3::run): * tests/stress/double-compare-to-float.js: Added. (canSimplifyToFloat): (canSimplifyToFloatWithConstant): (cannotSimplifyA): (cannotSimplifyB): * tests/stress/double-to-float.js: Added. (upsilonReferencingItsPhi): (upsilonReferencingItsPhiAllFloat): (upsilonReferencingItsPhiWithoutConversion): (conversionPropagages): (chainedUpsilonBothConvert): (chainedUpsilonFirstConvert): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@199648 268f45cc-cd09-0410-ab3c-d52691b4dbfc
vertexodessa
pushed a commit
to vertexodessa/WebKitForWayland
that referenced
this issue
Jul 15, 2016
…tan CMake Debug build broken <https://webkit.org/b/158743> Unreviewed build fix. * DumpRenderTree/PlatformMac.cmake: Fix silly typo. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@202065 268f45cc-cd09-0410-ab3c-d52691b4dbfc
zdobersek
pushed a commit
that referenced
this issue
Mar 7, 2017
https://bugs.webkit.org/show_bug.cgi?id=168629 Reviewed by Filip Pizlo. This will make dumping FTL disassembly dump Air intermixed with the assembly generated by each Air Inst. This is similar to how dumpDFGDisassembly dumps the generated assembly for each Node. Here is what the output will look like: Generated FTL JIT code for foo#CUaFiQ:[0x10b76c960->0x10b76c2d0->0x10b7b6da0, FTLFunctionCall, 40 (NeverInline)], instruction count = 40: BB#0: ; frequency = 1.000000 0x469004e02e00: push %rbp 0x469004e02e01: mov %rsp, %rbp 0x469004e02e04: add $0xffffffffffffffd0, %rsp Move $0x10b76c960, %rax, $4487301472(@16) 0x469004e02e08: mov $0x10b76c960, %rax Move %rax, 16(%rbp), @19 0x469004e02e12: mov %rax, 0x10(%rbp) Patch &Patchpoint2, %rbp, %rax, @20 0x469004e02e16: lea -0x50(%rbp), %rax 0x469004e02e1a: mov $0x1084081e0, %r11 0x469004e02e24: cmp %rax, (%r11) 0x469004e02e27: ja 0x469004e02e9a Move 56(%rbp), %rdx, @23 0x469004e02e2d: mov 0x38(%rbp), %rdx Move $0xffff000000000002, %rax, $-281474976710654(@15) 0x469004e02e31: mov $0xffff000000000002, %rax Patch &BranchTest64(3,SameAsRep)1, NonZero, %rdx, %rax, %rdx, @26 0x469004e02e3b: test %rdx, %rax 0x469004e02e3e: jnz 0x469004e02f08 Move 48(%rbp), %rax, @29 0x469004e02e44: mov 0x30(%rbp), %rax Move %rax, %rcx, @31 0x469004e02e48: mov %rax, %rcx Xor64 $6, %rcx, @31 0x469004e02e4b: xor $0x6, %rcx Patch &BranchTest64(3,SameAsRep)1, NonZero, %rcx, $-2, %rax, @35 0x469004e02e4f: test $0xfffffffffffffffe, %rcx 0x469004e02e56: jnz 0x469004e02f12 Patch &Branch32(3,SameAsRep)0, NotEqual, (%rdx), $266, %rdx, @45 0x469004e02e5c: cmp $0x10a, (%rdx) 0x469004e02e62: jnz 0x469004e02f1c BranchTest32 NonZero, %rax, $1, @49 0x469004e02e68: test $0x1, %al 0x469004e02e6a: jnz 0x469004e02e91 Successors: #3, #1 BB#1: ; frequency = 1.000000 Predecessors: #0 Move $0, %rcx, @65 0x469004e02e70: xor %rcx, %rcx Jump @66 Successors: #2 BB#2: ; frequency = 1.000000 Predecessors: #1, #3 Move 24(%rdx), %rax, @58 0x469004e02e73: mov 0x18(%rdx), %rax Patch &BranchAdd32(4,ForceLateUseUnlessRecoverable)3, Overflow, %rcx, %rax, %rcx, %rcx, %rax, @60 0x469004e02e77: add %eax, %ecx 0x469004e02e79: jo 0x469004e02f26 Move $0xffff000000000000, %rax, $-281474976710656(@14) 0x469004e02e7f: mov $0xffff000000000000, %rax Add64 %rcx, %rax, %rax, @62 0x469004e02e89: add %rcx, %rax Ret64 %rax, @63 0x469004e02e8c: mov %rbp, %rsp 0x469004e02e8f: pop %rbp 0x469004e02e90: ret BB#3: ; frequency = 1.000000 Predecessors: #0 Move 16(%rdx), %rcx, @52 0x469004e02e91: mov 0x10(%rdx), %rcx Jump @55 0x469004e02e95: jmp 0x469004e02e73 Successors: #2 * CMakeLists.txt: * JavaScriptCore.xcodeproj/project.pbxproj: * b3/air/AirCode.h: (JSC::B3::Air::Code::setDisassembler): (JSC::B3::Air::Code::disassembler): * b3/air/AirDisassembler.cpp: Added. (JSC::B3::Air::Disassembler::startEntrypoint): (JSC::B3::Air::Disassembler::endEntrypoint): (JSC::B3::Air::Disassembler::startLatePath): (JSC::B3::Air::Disassembler::endLatePath): (JSC::B3::Air::Disassembler::startBlock): (JSC::B3::Air::Disassembler::addInst): (JSC::B3::Air::Disassembler::dump): * b3/air/AirDisassembler.h: Added. * b3/air/AirGenerate.cpp: (JSC::B3::Air::generate): * ftl/FTLCompile.cpp: (JSC::FTL::compile): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@212775 268f45cc-cd09-0410-ab3c-d52691b4dbfc
zdobersek
pushed a commit
that referenced
this issue
May 22, 2017
…cs should not be required to perform font loading correctly. https://bugs.webkit.org/show_bug.cgi?id=168487 Reviewed by Antti Koivisto. Source/WebCore: There are three ways a Web author can chain multiple font files together: 1. Multiple entries in the "src" descriptor in an @font-face rule 2. Multiple @font-face rules with the same "font-family" descriptor 3. Multiple entries in the "font-family" property on an element Before r212513, the code which iterated across #2 and #3 above could have triggered each item in the chain to download. r212513 tried to solve this by using LastResort as the interstitial font used during downloads, because LastResort supports every character and therefore solves #3 above. However, this change had a few problems: 1. Previously, our code would try to avoid using the interstitial font for layout or rendering whenever possible (because one of the chains above may have named a local font which would be better to use). In order to use the benefits of LastResort, I had to remove this avoidance logic and make WebKit try to use the interstitial font as often as possible. However, due to the large metrics of LastResort, this means that offsetWidth queries during font loading would be wildly inaccurate, causing Google Docs to break. 2. It also means that canvas drawing during font loading would actually draw LastResort, causing Bing maps to break. 3. LastResort is platform-specific, so only platforms which have it would actually be able to load fonts correctly. Instead, we should keep the older logic about avoiding using the interstitial font so that loading has a better experience for the user. We solve the unnecessary download problem by giving our loading code a downloading policy enum, which has two values: allow downloads or forbid downloads. Whenever our loading code returns the interstitial font, we continue our search, but we change the policy to forbid downloads. There is one piece of subtlety, though: It is more common for web authors to put good fallbacks in the "font-family" property than in the "src" descriptor inside @font-face. This means that we shouldn't exhaustively search through the @font-face src list first. Instead, we should look through the src list until we hit a non-local font, and then immediately start looking through the other other chains. Tests: fast/text/font-download-font-face-src-list.html fast/text/font-download-font-family-property.html fast/text/font-download-remote-fallback-all.html fast/text/font-interstitial-invisible-width-while-loading.html fast/text/font-weight-download-3.html fast/text/web-font-load-fallback-during-loading-2.html fast/text/web-font-load-invisible-during-loading.html * css/CSSFontFace.cpp: (WebCore::CSSFontFace::fontLoadEventOccurred): Implement support for the font download policy. (WebCore::CSSFontFace::setStatus): After 3 seconds of loading, we will start drawing the fallback font. However, for testing, we have an internal setting to make this switch happen immediately. This patch now requires that this internal switch happen synchronously. (WebCore::CSSFontFace::pump): Implement support for the font download policy. (WebCore::CSSFontFace::load): Ditto. (WebCore::CSSFontFace::font): Ditto. * css/CSSFontFace.h: Ditto. * css/CSSFontSelector.cpp: (WebCore::CSSFontSelector::beginLoadingFontSoon): Implement support for synchronous font download timeouts. * css/CSSSegmentedFontFace.cpp: (WebCore::CSSSegmentedFontFace::fontRanges): Implement support for the font download policy. * platform/graphics/Font.cpp: Add new flag which represents if the interstitial font was created after the 3 second timeout or before. Previously, we would distinguish between these two cases by knowing that one font was LastResort and the other font was a fallback. Now that we're using fallback fonts on both sides of the 3 second timeout, we now no longer know which one should be invisible. This new enum solves this problem. (WebCore::Font::Font): (WebCore::Font::verticalRightOrientationFont): (WebCore::Font::uprightOrientationFont): * platform/graphics/Font.h: Ditto. (WebCore::Font::create): (WebCore::Font::origin): (WebCore::Font::visibility): * platform/graphics/FontCache.h: * platform/graphics/FontCascade.cpp: We try to fall back to a local() font during downloads, but there might not be one that we can use. Therefore, we can't use the presence of the interstitial font to detect if we should paint invisibly. Instead, we can move this logic into the font-specific part of painting, and consult with the specific font to know if it was created from a timed-out @font-face rule or not. (WebCore::FontCascade::drawText): (WebCore::shouldDrawIfLoading): (WebCore::FontCascade::drawGlyphBuffer): (WebCore::FontCascade::drawEmphasisMarks): * platform/graphics/FontCascade.h: * platform/graphics/FontCascadeFonts.cpp: (WebCore::FontCascadeFonts::glyphDataForVariant): Implement the logic described above where we switch the policy if we encounter the intestitial font. (WebCore::FontCascadeFonts::glyphDataForNormalVariant): Ditto. (WebCore::glyphPageFromFontRanges): Ditto. * platform/graphics/FontRanges.cpp: Implement support for the font download policy. (WebCore::FontRanges::Range::font): (WebCore::FontRanges::glyphDataForCharacter): (WebCore::FontRanges::fontForCharacter): (WebCore::FontRanges::fontForFirstRange): * platform/graphics/FontRanges.h: * platform/graphics/FontSelector.h: * platform/graphics/freetype/FontCacheFreeType.cpp: (WebCore::FontCache::lastResortFallbackFontForEveryCharacter): Deleted. * platform/graphics/mac/FontCacheMac.mm: (WebCore::FontCache::lastResortFallbackFontForEveryCharacter): Deleted. * platform/graphics/win/FontCacheWin.cpp: (WebCore::FontCache::lastResortFallbackFontForEveryCharacter): Deleted. LayoutTests: * fast/text/font-download-font-face-src-list-expected.txt: Added. * fast/text/font-download-font-face-src-list.html: Copied from LayoutTests/fast/text/font-weight-download-2.html. * fast/text/font-download-font-family-property-expected.txt: Added. * fast/text/font-download-font-family-property.html: Copied from LayoutTests/fast/text/font-weight-download-2.html. * fast/text/font-download-remote-fallback-all-expected.txt: Added. * fast/text/font-download-remote-fallback-all.html: Copied from LayoutTests/fast/text/font-weight-download-2.html. * fast/text/font-interstitial-invisible-width-while-loading-expected.txt: Added. * fast/text/font-interstitial-invisible-width-while-loading.html: Added. * fast/text/font-weight-download-2.html: * fast/text/font-weight-download-3-expected.txt: Added. * fast/text/font-weight-download-3.html: Copied from LayoutTests/fast/text/font-weight-download-2.html. * fast/text/web-font-load-fallback-during-loading-2-expected.html: Added. * fast/text/web-font-load-fallback-during-loading-2.html: Added. * fast/text/web-font-load-fallback-during-loading-expected.html: * fast/text/web-font-load-fallback-during-loading.html: * fast/text/web-font-load-invisible-during-loading-expected.txt: Added. * fast/text/web-font-load-invisible-during-loading.html: Added. * http/tests/webfont/fallback-font-while-loading-expected.txt: * http/tests/webfont/fallback-font-while-loading.html: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@216944 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Closed
BunioFH
pushed a commit
to zbigniew-holdys/WPEWebKit
that referenced
this issue
Jul 21, 2017
zdobersek
pushed a commit
that referenced
this issue
Sep 13, 2017
* WebCoreSupport/WebPlatformStrategies.cpp: (WebPlatformStrategies::cookieRequestHeaderFieldValue): Correct return type and arguments to match new API. * WebCoreSupport/WebPlatformStrategies.h: Update signatures. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@221289 268f45cc-cd09-0410-ab3c-d52691b4dbfc
|
I'm still encountering this error :( |
charlie-ht
pushed a commit
that referenced
this issue
Jan 10, 2019
…EM_MALLOC on unfamiliar architectures https://bugs.webkit.org/show_bug.cgi?id=186722 Reviewed by Žan Doberšek. Time for part #2! This change was defeated for GTK and WPE by the code that makes the options public. We have three options: (a) duplicate the architecture check currently in WebKitFeatures.cmake in both OptionsGTK.cmake and OptionsWPE.cmake, (b) rely on the result of that check in OptionsGTK.cmake and OptionsWPE.cmake by using ENABLE_JIT_DEFAULT and USE_SYSTEM_MALLOC_DEFAULT, a fragile encapsulation violation, or (c) just make the options private. They have been public up until now because they needed to be turned off on unsupported architectures. But now they are off by default and enabled only for particular whitelisted architectures, so they shouldn't be needed anymore. Note we have to hide ENABLE_SAMPLING_PROFILER as well, since it needs to match the value of ENABLE_JIT. Again, this is handled properly in WebKitFeatures.cmake, and defeated here in OptionsGTK.cmake. (This is not a problem for WPE.) * Source/cmake/OptionsGTK.cmake: * Source/cmake/OptionsWPE.cmake: git-svn-id: http://svn.webkit.org/repository/webkit/releases/WebKitGTK/webkit-2.22@239001 268f45cc-cd09-0410-ab3c-d52691b4dbfc
dwrobel
added a commit
to dwrobel/WPEWebKit
that referenced
this issue
Apr 10, 2019
strlen() is invoked on strings located in UserAgentStyleSheetsData.cpp, however strings in those tables doesn't not contain valid C string with '\0' character in the end. GDB callstack excerpt: (complete is available at WebPlatformForEmbedded#592) (gdb) bt #0 0x00007fb2aae415d0 in __sanitizer::Die() () at ../../../../libsanitizer/sanitizer_common/sanitizer_termination.cc:49 WebPlatformForEmbedded#1 0x00007fb2aae23ce5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() (this=<optimized out>, __in_chrg=<optimized out>) at ../../../../libsanitizer/asan/asan_report.cc:181 WebPlatformForEmbedded#2 0x00007fb2aae23ce5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) (pc=<optimized out>, bp=bp@entry=140729000272496, sp=sp@entry=140729000270360, addr=addr@entry=140405332238509, is_write=is_write@entry=false, access_size=access_size@entry=27118, exp=0, fatal=false) at ../../../../libsanitizer/asan/asan_report.cc:397 WebPlatformForEmbedded#3 0x00007fb2aadd62ac in __interceptor_strlen(char const*) (s=<optimized out>) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301 WebPlatformForEmbedded#4 0x00007fb2a95309ba in WTF::StringImpl::createFromLiteral(char const*) (characters=0x7fb2a9f376c0 <WebCore::mediaControlsBaseUserAgentStyleSheet> "audio { width: 200px; height: 25px; } body:-webkit-full-page-media { background-color: rgb(38, 38, 38); } video:-webkit-full-page-media { margin: auto; position: absolute; top: 0; right: 0; bottom: 0;"...) at ../Source/WTF/wtf/text/StringImpl.cpp:158 WebPlatformForEmbedded#5 0x00007fb2a957ff4c in WTF::String::String(WTF::ASCIILiteral) (this=0x7ffe061225d0, characters=...) at ../Source/WTF/wtf/text/WTFString.h:734 WebPlatformForEmbedded#6 0x00007fb2a4b25f21 in WebCore::RenderThemeWPE::mediaControlsStyleSheet() (this=<optimized out>) at ../Source/WTF/wtf/text/WTFString.h:733 (gdb) fr 4 158 return createFromLiteral(characters, strlen(characters)); (gdb) l 153 return adoptRef(*new StringImpl(reinterpret_cast<const LChar*>(characters), length, ConstructWithoutCopying)); 154 } 155 156 Ref<StringImpl> StringImpl::createFromLiteral(const char* characters) 157 { 158 return createFromLiteral(characters, strlen(characters)); 159 } Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
dwrobel
added a commit
to dwrobel/WPEWebKit
that referenced
this issue
Apr 10, 2019
strlen() is invoked on strings located in UserAgentStyleSheetsData.cpp, however strings in those tables doesn't not contain valid C string with '\0' character in the end. GDB callstack excerpt: (complete is available at WebPlatformForEmbedded#592) (gdb) bt #0 0x00007fb2aae415d0 in __sanitizer::Die() () at ../../../../libsanitizer/sanitizer_common/sanitizer_termination.cc:49 WebPlatformForEmbedded#1 0x00007fb2aae23ce5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() (this=<optimized out>, __in_chrg=<optimized out>) at ../../../../libsanitizer/asan/asan_report.cc:181 WebPlatformForEmbedded#2 0x00007fb2aae23ce5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) (pc=<optimized out>, bp=bp@entry=140729000272496, sp=sp@entry=140729000270360, addr=addr@entry=140405332238509, is_write=is_write@entry=false, access_size=access_size@entry=27118, exp=0, fatal=false) at ../../../../libsanitizer/asan/asan_report.cc:397 WebPlatformForEmbedded#3 0x00007fb2aadd62ac in __interceptor_strlen(char const*) (s=<optimized out>) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301 WebPlatformForEmbedded#4 0x00007fb2a95309ba in WTF::StringImpl::createFromLiteral(char const*) (characters=0x7fb2a9f376c0 <WebCore::mediaControlsBaseUserAgentStyleSheet> "audio { width: 200px; height: 25px; } body:-webkit-full-page-media { background-color: rgb(38, 38, 38); } video:-webkit-full-page-media { margin: auto; position: absolute; top: 0; right: 0; bottom: 0;"...) at ../Source/WTF/wtf/text/StringImpl.cpp:158 WebPlatformForEmbedded#5 0x00007fb2a957ff4c in WTF::String::String(WTF::ASCIILiteral) (this=0x7ffe061225d0, characters=...) at ../Source/WTF/wtf/text/WTFString.h:734 WebPlatformForEmbedded#6 0x00007fb2a4b25f21 in WebCore::RenderThemeWPE::mediaControlsStyleSheet() (this=<optimized out>) at ../Source/WTF/wtf/text/WTFString.h:733 (gdb) fr 4 158 return createFromLiteral(characters, strlen(characters)); (gdb) l 153 return adoptRef(*new StringImpl(reinterpret_cast<const LChar*>(characters), length, ConstructWithoutCopying)); 154 } 155 156 Ref<StringImpl> StringImpl::createFromLiteral(const char* characters) 157 { 158 return createFromLiteral(characters, strlen(characters)); 159 } Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
dwrobel
added a commit
to dwrobel/WPEWebKit
that referenced
this issue
Apr 23, 2019
strlen() is invoked on strings located in UserAgentStyleSheetsData.cpp, however strings in those tables doesn't not contain valid C string with '\0' character in the end. GDB callstack excerpt: (complete is available at WebPlatformForEmbedded#592) (gdb) bt #0 0x00007fb2aae415d0 in __sanitizer::Die() () at ../../../../libsanitizer/sanitizer_common/sanitizer_termination.cc:49 WebPlatformForEmbedded#1 0x00007fb2aae23ce5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() (this=<optimized out>, __in_chrg=<optimized out>) at ../../../../libsanitizer/asan/asan_report.cc:181 WebPlatformForEmbedded#2 0x00007fb2aae23ce5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) (pc=<optimized out>, bp=bp@entry=140729000272496, sp=sp@entry=140729000270360, addr=addr@entry=140405332238509, is_write=is_write@entry=false, access_size=access_size@entry=27118, exp=0, fatal=false) at ../../../../libsanitizer/asan/asan_report.cc:397 WebPlatformForEmbedded#3 0x00007fb2aadd62ac in __interceptor_strlen(char const*) (s=<optimized out>) at ../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301 WebPlatformForEmbedded#4 0x00007fb2a95309ba in WTF::StringImpl::createFromLiteral(char const*) (characters=0x7fb2a9f376c0 <WebCore::mediaControlsBaseUserAgentStyleSheet> "audio { width: 200px; height: 25px; } body:-webkit-full-page-media { background-color: rgb(38, 38, 38); } video:-webkit-full-page-media { margin: auto; position: absolute; top: 0; right: 0; bottom: 0;"...) at ../Source/WTF/wtf/text/StringImpl.cpp:158 WebPlatformForEmbedded#5 0x00007fb2a957ff4c in WTF::String::String(WTF::ASCIILiteral) (this=0x7ffe061225d0, characters=...) at ../Source/WTF/wtf/text/WTFString.h:734 WebPlatformForEmbedded#6 0x00007fb2a4b25f21 in WebCore::RenderThemeWPE::mediaControlsStyleSheet() (this=<optimized out>) at ../Source/WTF/wtf/text/WTFString.h:733 (gdb) fr 4 158 return createFromLiteral(characters, strlen(characters)); (gdb) l 153 return adoptRef(*new StringImpl(reinterpret_cast<const LChar*>(characters), length, ConstructWithoutCopying)); 154 } 155 156 Ref<StringImpl> StringImpl::createFromLiteral(const char* characters) 157 { 158 return createFromLiteral(characters, strlen(characters)); 159 } Signed-off-by: Damian Wrobel <dwrobel@ertelnet.rybnik.pl>
This was referenced Mar 30, 2021
dwrobel
pushed a commit
to dwrobel/WPEWebKit
that referenced
this issue
Oct 11, 2021
…mcast-upstream Lgi comcast upstream
magomez
pushed a commit
that referenced
this issue
Jun 19, 2024
…/setrequestheader-case-insensitive.htm is a constant failure (attempt #2) https://bugs.webkit.org/show_bug.cgi?id=273498 rdar://127299045 Reviewed by Anne van Kesteren and Sam Sneddon. Second attempt. This change modifies the test such that it now only compares the relevant header substrings, instead of matching the entire header content. * LayoutTests/imported/w3c/web-platform-tests/xhr/setrequestheader-case-insensitive-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/xhr/setrequestheader-case-insensitive.htm: Canonical link: https://commits.webkit.org/278282@main
magomez
pushed a commit
that referenced
this issue
Jun 19, 2024
…n site-isolation rdar://127515199 https://bugs.webkit.org/show_bug.cgi?id=273715 Unreviewed test gardening. * LayoutTests/platform/mac-site-isolation/TestExpectations: Canonical link: https://commits.webkit.org/278367@main
magomez
pushed a commit
that referenced
this issue
Jun 19, 2024
…volume scrubber on a video player https://bugs.webkit.org/show_bug.cgi?id=275469 <rdar://129080145> Reviewed by Antti Koivisto. 1. In EventHandler::mouseDragged we dispatch the "mouse move" event 2. JS triggers some mutation which makes the tree dirty 3. later in EventHandler::handleMouseMoveEvent() we call EventHandler::handleMouseDraggedEvent() (tree is dirty) which, through a few layers of functions calls VisiblePosition::canonicalPosition() 4. VisiblePosition::canonicalPosition() needs a clean tree so it calls Document::updateLayout() which is turn destroys some renderers (see #2) 5. In-between EventHandler::handleMouseDraggedEvent() and VisiblePosition::canonicalPosition(), we CheckPtr a renderer which gets destroyed at #4. The fix (what we normally do with cases like this) is to make sure we clean the tree before entering VisiblePosition. * Source/WebCore/page/EventHandler.cpp: (WebCore::EventHandler::handleMouseDraggedEvent): Canonical link: https://commits.webkit.org/280013@main
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently wpe fetches any and all content over https just fine regardless of certificates. But when it comes to websocket connections the behavior is reversed, and the connection fails, even if the server has a valid certificate, because no root certs are included.
This is from the wpe console when trying to open a secure (wss://) websocket:
The text was updated successfully, but these errors were encountered: