[webkit-dev] CSS Parse error in <link rel> element.
Atul Sowani
sowani at gmail.com
Wed Feb 15 00:39:48 PST 2017
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 <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-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 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170215/04894f36/attachment.html>
More information about the webkit-dev
mailing list