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. 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-p >> age/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