Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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 
wrote:

>
>
> 17.02.2017, 12:19, "Atul Sowani" :
> > 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 
> wrote:
> >> 15.02.2017, 11:40, "Atul Sowani" :
> >>> 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 
> >>> create(PassRefPtr
> leftSide, PassRefPtr 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 

Re: [webkit-dev] CSS Parse error in element.

[Konstantin Tokarev]

17.02.2017, 12:19, "Atul Sowani" :
> 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  wrote:
>> 15.02.2017, 11:40, "Atul Sowani" :
>>> 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 
>>> create(PassRefPtr leftSide, 
>>> PassRefPtr 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 
>>> 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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.

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.

On Wed, Feb 15, 2017 at 2:18 PM, Konstantin Tokarev 
wrote:

>
>
> 15.02.2017, 11:40, "Atul Sowani" :
>
> 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 
> create(PassRefPtr
> leftSide, PassRefPtr 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  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
> 

Re: [webkit-dev] CSS Parse error in element.

[Konstantin Tokarev]

  15.02.2017, 11:40, "Atul Sowani" :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 create(PassRefPtr leftSide, PassRefPtr 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 parseAdditiveValueExpressionoperatorCharacter 2 = -lhs = 1 rhs = 1in CSSCalcBinaryOperation::createleftSide category = 5rightSide 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++ -vUsing built-in specs.COLLECT_GCC=g++COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapperTarget: x86_64-linux-gnuConfigured 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-gnuThread model: posixgcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) on ppc64le:# g++ -vUsing built-in specs.COLLECT_GCC=g++COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/5/lto-wrapperTarget: powerpc64le-linux-gnuConfigured 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-gnuThread model: posixgcc 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  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  wrote: 13.02.2017, 11:52, "Atul Sowani" :> 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  wrote:>> What WebKit revision 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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
create(PassRefPtr leftSide,
PassRefPtr 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  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 
> wrote:
>
>>
>>
>> 13.02.2017, 11:52, "Atul Sowani" :
>> > 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 
>> wrote:
>> >> What WebKit revision are your 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

@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 
wrote:

>
>
> 13.02.2017, 11:52, "Atul Sowani" :
> > 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 
> 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  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::create(WTF::PassRefPtr,
> WTF::PassRefPtr, 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  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 
> wrote:
> 
> > 07.02.2017, 12:55, "Atul Sowani" :
> >> 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  wrote:
> >>> Hi Atul,
> >>>
> >>> I second 

Re: [webkit-dev] CSS Parse error in element.

[Konstantin Tokarev]

13.02.2017, 11:52, "Atul Sowani" :
> 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  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  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::create(WTF::PassRefPtr,
>>>  WTF::PassRefPtr, 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  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  
 wrote:

> 07.02.2017, 12:55, "Atul Sowani" :
>> 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  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 
>>> 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

I have been debugging on the CSS Parser issue and what I observed is
similar to issue described at
http://stackoverflow.com/questions/27256849/it-is-possible-to-use-vh-minus-pixels-in-a-css-calc

For example, the CSS parser is crashing while processing following:
height:calc(100vh - 200px)

I modified it as
height:calc(~"100vh - 200px")

This seems to be working. So my question is, whether CSS parser is supposed
to handle the faulty case or the CSS source should be fixed always?

Thanks,
Atul.

On Mon, Feb 13, 2017 at 2:21 PM, Atul Sowani  wrote:

> I am using Qt 5.5.1.
>
> On Thu, Feb 9, 2017 at 10:15 PM, Simon Fraser 
> 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  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::create(WTF::PassRefPtr,
>> WTF::PassRefPtr, 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  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 
>>> wrote:
>>>


 07.02.2017, 12:55, "Atul Sowani" :
 > 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  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 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

I am using Qt 5.5.1.

On Thu, Feb 9, 2017 at 10:15 PM, Simon Fraser 
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  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::create(WTF::PassRefPtr,
> WTF::PassRefPtr, 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  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 
>> wrote:
>>
>>>
>>>
>>> 07.02.2017, 12:55, "Atul Sowani" :
>>> > 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  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  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.
>>> 
>>> 

Re: [webkit-dev] CSS Parse error in element.

[Simon Fraser]

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  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::create(WTF::PassRefPtr,
>  WTF::PassRefPtr, 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  > 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  > wrote:
> 
> 
> 07.02.2017, 12:55, "Atul Sowani" >:
> > 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  > > 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  >> > 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   > 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 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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::create(WTF::PassRefPtr,
WTF::PassRefPtr, 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  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 
> wrote:
>
>>
>>
>> 07.02.2017, 12:55, "Atul Sowani" :
>> > 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  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  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 
>> 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 > 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. "
>> 

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

@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 
wrote:

>
>
> 07.02.2017, 12:55, "Atul Sowani" :
> > 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  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 
> 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  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  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  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

Re: [webkit-dev] CSS Parse error in element.

[Konstantin Tokarev]

07.02.2017, 12:55, "Atul Sowani" :
> 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  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  
>> 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  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  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  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

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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.

Thanks,
Atul.

On Mon, Feb 6, 2017 at 5:56 PM, Yoav Weiss  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 
> 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  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  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 > 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

Re: [webkit-dev] CSS Parse error in element.

[Yoav Weiss]

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 
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  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  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 
> 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

Re: [webkit-dev] CSS Parse error in element.

[Alex Christensen]

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  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  > 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  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

Re: [webkit-dev] CSS Parse error in element.

[Geoffrey Garen]

+Alex

> On Feb 3, 2017, at 1:17 AM, Atul Sowani  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  > 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  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

Re: [webkit-dev] CSS Parse error in element.

[Atul Sowani]

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  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 
> 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] CSS Parse error in element.

[Atul Sowani]

Hi,

I came across an issue in qtwebkit CSS parser while working on a PhantomJS
crash. The issue seems to be with parsing of 
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