[webkit-dev] CSS Parse error in <link rel> element.

Atul Sowani sowani at gmail.com
Tue Feb 21 03:51:03 PST 2017 

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 <annulen at yandex.ru>
wrote:

>
>
> 17.02.2017, 12:19, "Atul Sowani" <sowani at 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 <annulen at yandex.ru>
> wrote:
> >> 15.02.2017, 11:40, "Atul Sowani" <sowani at 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 <sowani at 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 <
> annulen at yandex.ru> wrote:
> >>>>
> >>>>> 13.02.2017, 11:52, "Atul Sowani" <sowani at 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.fraser at 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 <sowani at 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 <sowani at 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 <
> annulen at yandex.ru> wrote:
> >>>>>>>>>
> >>>>>>>>>> 07.02.2017, 12:55, "Atul Sowani" <sowani at 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 <yoav at 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 <
> achristensen at 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 <sowani at 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 <
> sowani at 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 at lists.webkit.org
> >>>>>>>>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >>>>>>>>>>> ,
> >>>>>>>>>>>
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> webkit-dev mailing list
> >>>>>>>>>>> webkit-dev at lists.webkit.org
> >>>>>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Regards,
> >>>>>>>>>> Konstantin
> >>>>>>>> _______________________________________________
> >>>>>>>> webkit-dev mailing list
> >>>>>>>> webkit-dev at lists.webkit.org
> >>>>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >>>>>> ,
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> webkit-dev mailing list
> >>>>>> webkit-dev at lists.webkit.org
> >>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >>>>>
> >>>>> --
> >>>>> Regards,
> >>>>> Konstantin
> >>> ,
> >>>
> >>> _______________________________________________
> >>> webkit-dev mailing list
> >>> webkit-dev at lists.webkit.org
> >>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >>
> >> --
> >> Regards,
> >> Konstantin
> > ,
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> --
> Regards,
> Konstantin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170221/d31dd256/attachment.html>

More information about the webkit-dev mailing list