I compared the code of TP5 with the code of default qtwebkit in PhantomJS and did not find any difference. So I think PhantomJS is making use of the latest version of QtWebKit.
On Fri, Feb 17, 2017 at 4:04 PM, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > 17.02.2017, 12:19, "Atul Sowani" <sow...@gmail.com>: > > I built the debug-mode binary and verified on x86_64 that I am seeing > exactly the same crashes (due to enabled asserts) as seen on ppc64le. > > That's what I've expected. > > > > > On ppc64le, on the other hand, with release-mode binary, webpage is > loaded without issues. Only difference in behavior is seen in winding down > of heap maintainer (and timer) code - which crashes on ppc64le. > > Have you reported details of this remaining crash already? > > Anyway, you need to upgrade QtWebKit first. Fixing WebKit from 2013 on > platform that haven't existed at that time has very little practical value > (and also confuses readers of this list most of whom work with trunk). If > you have troubles with building QtWebKit TP5 you can ask on webkit-qt list, > if there are issues with PhantomJS ask on their list. Or you can reach us > on IRC. > > > > > On Wed, Feb 15, 2017 at 2:18 PM, Konstantin Tokarev <annu...@yandex.ru> > wrote: > >> 15.02.2017, 11:40, "Atul Sowani" <sow...@gmail.com>: > >>> Hi, > >>> > >>> I am wondering about the behavioural difference of the same code on > two different platforms, under same conditions. For example, consider > following code in css/CSSCalculationValue.cpp (under class > CSSCalcBinaryOperation): > >>> > >>> static PassRefPtr<CSSCalcBinaryOperation> > >>> create(PassRefPtr<CSSCalcExpressionNode> > leftSide, PassRefPtr<CSSCalcExpressionNode> rightSide, CalcOperator op) > >>> { > >>> ASSERT(leftSide->category() != CalcOther && > rightSide->category() != CalcOther); > >>> CalculationCategory newCategory = determineCategory(*leftSide, > *rightSide, op); > >>> if (newCategory == CalcOther) > >>> return 0; > >>> return adoptRef(new CSSCalcBinaryOperation(leftSide, > rightSide, op, newCategory)); > >>> } > >>> > >>> The values in question are as follows: > >>> calling CSSCalcBinaryOperation::create from > parseAdditiveValueExpression > >>> operatorCharacter 2 = - > >>> lhs = 1 rhs = 1 > >>> in CSSCalcBinaryOperation::create > >>> leftSide category = 5 > >>> rightSide category = 1 > >>> > >>> Now exactly same values cause ASSERT on ppc64le, causing a crash > whereas it just passes smoothly on x86_64. > >> > >> It can be that you are using release build on x86_64, where asserts are > disabled > >> > >>> The C/C++ compiler is identical on both the platforms: > >>> > >>> on x86_64: > >>> # g++ -v > >>> Using built-in specs. > >>> COLLECT_GCC=g++ > >>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper > >>> Target: x86_64-linux-gnu > >>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu > 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs > --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-5 --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --with-default-libstdcxx-abi=new --enable-gnu-unique-object > --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre > --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 > --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 > --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib > --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu > --host=x86_64-linux-gnu --target=x86_64-linux-gnu > >>> Thread model: posix > >>> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) > >>> > >>> on ppc64le: > >>> # g++ -v > >>> Using built-in specs. > >>> COLLECT_GCC=g++ > >>> COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/5/lto-wrapper > >>> Target: powerpc64le-linux-gnu > >>> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/IBM > 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs > --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-5 --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --with-default-libstdcxx-abi=new --enable-gnu-unique-object > --disable-libquadmath --enable-plugin --with-system-zlib > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el/jre > --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-ppc64el > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-ppc64el > --with-arch-directory=ppc64le --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --enable-objc-gc --enable-secureplt --with-cpu=power8 > --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch > --disable-werror --with-long-double-128 --enable-checking=release > --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu > --target=powerpc64le-linux-gnu > >>> Thread model: posix > >>> gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) > >>> > >>> On Mon, Feb 13, 2017 at 4:26 PM, Atul Sowani <sow...@gmail.com> wrote: > >>>> @Konstantin Thanks for the update and it is definitely relieving to > know that those were known issues and have been fixed in later version of > QtWebKit. I will work with PhantomJS maintainers to get the QtWebKit > version upgraded in the latest PhantomJS version. > >>>> > >>>> Thanks! > >>>> > >>>> On Mon, Feb 13, 2017 at 3:41 PM, Konstantin Tokarev < > annu...@yandex.ru> wrote: > >>>> > >>>>> 13.02.2017, 11:52, "Atul Sowani" <sow...@gmail.com>: > >>>>>> I am using Qt 5.5.1. > >>>>> > >>>>> It ships with obsolete WebKit version based on trunk from 2013. > Indeed it is known to have assertion failures related to calc like those > you've posted, which were fixed since that times. > >>>>> > >>>>> Please upgrade to QtWebKit TP5 [1]. It is much closer to trunk, and > will be a hard requirement for Phantom JS 2.5 > >>>>> > >>>>> [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 > >>>>> > >>>>>> > >>>>>> On Thu, Feb 9, 2017 at 10:15 PM, Simon Fraser < > simon.fra...@apple.com> wrote: > >>>>>>> What WebKit revision are your sources based on? It's quite likely > the this bug has been fixed. > >>>>>>> > >>>>>>> Simon > >>>>>>> > >>>>>>>> On Feb 9, 2017, at 4:09 AM, Atul Sowani <sow...@gmail.com> wrote: > >>>>>>>> > >>>>>>>> Finally I zeroed in on 3 "calc" candidates from the stylesheet > which are causing the CSS parser to fail: > >>>>>>>> > >>>>>>>> height:calc(100vh - 200px) > >>>>>>>> height:calc(100vh - 230px) > >>>>>>>> max-height:calc(100vh - 200px) > >>>>>>>> > >>>>>>>> I think it is the very first one and the remaining two never get > processed. > >>>>>>>> > >>>>>>>> I put in some debug statements in the code and the corresponding > output for this is: > >>>>>>>> > >>>>>>>> ATUL: value->id = 0 propId = 1080 > >>>>>>>> ATUL: in CSSPropertyHeight > >>>>>>>> ATUL: in CSSPropertyWebkitLogicalHeight > >>>>>>>> ATUL: in CSSCalcValue::create > >>>>>>>> ATUL: in parseValueExpression, calling > parseAdditiveValueExpression > >>>>>>>> ATUL: calling CSSCalcBinaryOperation::create from > parseAdditiveValueExpression > >>>>>>>> ATUL: operatorCharacter = - > >>>>>>>> ATUL: lhs = 1 rhs = 1 > >>>>>>>> ATUL: leftSide category = ATUL: m_category = 5 > >>>>>>>> 5 > >>>>>>>> ATUL: rightSide category = ATUL: m_category = 1 > >>>>>>>> 1 > >>>>>>>> ATUL: m_category = 5 > >>>>>>>> ASSERTION FAILED: leftSide->category() != CalcOther && > rightSide->category() != CalcOther > >>>>>>>> css/CSSCalculationValue.cpp(293) : static > WTF::PassRefPtr<WebCore::CSSCalcBinaryOperation> WebCore:: > CSSCalcBinaryOperation::create(WTF::PassRefPtr<WebCore::CSSCalcExpressionNode>, > WTF::PassRefPtr<WebCore::CSSCalcExpressionNode>, WebCore::CalcOperator) > >>>>>>>> 1 0x12e8a80c bin/phantomjs() [0x12e8a80c] > >>>>>>>> < stack trace removed > > >>>>>>>> > >>>>>>>> So the question is, is the calc expression valid one? > >>>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Atul. > >>>>>>>> > >>>>>>>> On Thu, Feb 9, 2017 at 2:17 PM, Atul Sowani <sow...@gmail.com> > wrote: > >>>>>>>>> @Konstantin thanks for the suggestions. I disabled CSS JIT on > x85 but there was no negative impact on the results on x86. So I guess the > issue is a genuine ppc64le problem. I have picked up the starting points > mentioned in this thread earlier and debugging the issue. I have also > isolated the issue to a single CSS file which is causing the problem. Now I > am trying to isolate the exact entry in the CSS file which is causing the > trouble. > >>>>>>>>> > >>>>>>>>> Thanks! > >>>>>>>>> Atul. > >>>>>>>>> > >>>>>>>>> On Tue, Feb 7, 2017 at 3:53 PM, Konstantin Tokarev < > annu...@yandex.ru> wrote: > >>>>>>>>> > >>>>>>>>>> 07.02.2017, 12:55, "Atul Sowani" <sow...@gmail.com>: > >>>>>>>>>>> Thanks Geoffrey, Alex, Yoav for the debugging pointer. I am > debugging the issue further using this information and will most likely > need some more help in immediate future as well. > >>>>>>>>>>> > >>>>>>>>>>> Unfortunately, I don't have a stand-alone test case which can > be tested with qtwebkit. I am trying to load a page using PhantomJS and > it's crashing. The typical URLs which cause it to crash are > http://engadget.com and http://cnn.com - both of these load without any > issue on x86 platform though, so the issue seems to be specific to ppc64le. > >>>>>>>>>> > >>>>>>>>>> A few suggestions: > >>>>>>>>>> > >>>>>>>>>> 1. I suppose you are building with disabled JIT, as WebKit does > not implement JIT for any PPC variant in official tree. This may introduce > subtle differences in behavior, for example I once encountered layout test > that was failing only when CSS JIT was disabled. You can try building > without JIT on x86_64 and compare. > >>>>>>>>>> > >>>>>>>>>> 2. It might be miscompilation, as your platform may not be as > thoroughly tested as more mainstream ones. You can try to build with -O0, > -O1, -O2 (default is -O3). Alternatively, try building with different > compiler (at least GCC and Clang support ppc64le and are fine for WebKit, > xlC may not work though), or try different version of your compiler. > >>>>>>>>>> > >>>>>>>>>> 3. Note that webkit-qt list is more appropriate for issues > specific for QtWebKit. Make sure you are using latest release (technology > preview 5 at the moment [1]) > >>>>>>>>>> > >>>>>>>>>> [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> Atul. > >>>>>>>>>>> > >>>>>>>>>>> On Mon, Feb 6, 2017 at 5:56 PM, Yoav Weiss <y...@yoav.ws> > wrote: > >>>>>>>>>>>> Hi Atul, > >>>>>>>>>>>> > >>>>>>>>>>>> I second Alex's suggestion (perhaps followed by > HTMLLinkElement::process() and other places in that file that refer to > `hrefAttr`). > >>>>>>>>>>>> If you have a test case online, I could try to take a look > and maybe provide more guidance. > >>>>>>>>>>>> > >>>>>>>>>>>> Cheers :) > >>>>>>>>>>>> Yoav > >>>>>>>>>>>> > >>>>>>>>>>>> On Fri, Feb 3, 2017 at 9:19 PM Alex Christensen < > achristen...@apple.com> wrote: > >>>>>>>>>>>>> I would start looking at HTMLLinkElement::parseAttribute. > >>>>>>>>>>>>> LinkHeader.cpp contains parsers for link headers, which are > related. Yoav knows more about those. Those parsers ought to be united > more. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Feb 3, 2017, at 1:17 AM, Atul Sowani <sow...@gmail.com> > wrote: > >>>>>>>>>>>>>> At present I am focusing on CSSParser::findURI() > particularly and CSSParser::realLex() other related functionality in > CSSParser.cpp - hope I am on right track. ;-) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Please let me know if I should be looking at some other > functionality as well to resolve this issue. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks! > >>>>>>>>>>>>>> Atul. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani < > sow...@gmail.com> wrote: > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I came across an issue in qtwebkit CSS parser while > working on a PhantomJS crash. The issue seems to be with parsing of <link > rel="..." href="..."> type elements in an HTML page. What I observed is > that the parser is trying to interpret the value for href given inside > double-quotes. The value contains a "-" (e.g. " > http://some.domain.com/some-page-etc-etc"). The "-" sign is being > interpreted as minus and then things go wrong. In another case I found that > "\g" embedded in the value (e.g. "http://some.domain.com/some- > page/global/something") is also creating issues. In essence, the parser > is trying to interpret the value, which I believe, it should not. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am willing to dive further into it to debug and fix the > issue, but looking at the complexity and size of WebCore, I think I would > benefit a lot to expedite a fix, if I could get some tips about which code > area/functionality I should specifically focus in the WebCore. Looking > forward to some help in this regard. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> Atul. > >>>>>>>>>>>>>> _______________________________________________ > >>>>>>>>>>>>>> webkit-dev mailing list > >>>>>>>>>>>>>> webkit-dev@lists.webkit.org > >>>>>>>>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev > >>>>>>>>>>> , > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> webkit-dev mailing list > >>>>>>>>>>> webkit-dev@lists.webkit.org > >>>>>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Regards, > >>>>>>>>>> Konstantin > >>>>>>>> _______________________________________________ > >>>>>>>> webkit-dev mailing list > >>>>>>>> webkit-dev@lists.webkit.org > >>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev > >>>>>> , > >>>>>> > >>>>>> _______________________________________________ > >>>>>> webkit-dev mailing list > >>>>>> webkit-dev@lists.webkit.org > >>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev > >>>>> > >>>>> -- > >>>>> Regards, > >>>>> Konstantin > >>> , > >>> > >>> _______________________________________________ > >>> webkit-dev mailing list > >>> webkit-dev@lists.webkit.org > >>> https://lists.webkit.org/mailman/listinfo/webkit-dev > >> > >> -- > >> Regards, > >> Konstantin > > , > > > > _______________________________________________ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > -- > Regards, > Konstantin >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev