<div dir="ltr"><div>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.</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 2:18 PM, Konstantin Tokarev <span dir="ltr">&lt;<a href="mailto:annulen@yandex.ru" target="_blank">annulen@yandex.ru</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> </div><div> </div><div>15.02.2017, 11:40, &quot;Atul Sowani&quot; &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt;:</div><span><blockquote type="cite"><div><div>Hi,</div><div> </div><div>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):</div><div> </div><div>    static PassRefPtr&lt;<wbr>CSSCalcBinaryOperation&gt; create(PassRefPtr&lt;<wbr>CSSCalcExpressionNode&gt; leftSide, PassRefPtr&lt;<wbr>CSSCalcExpressionNode&gt; rightSide, CalcOperator op)<br>    {<br>        ASSERT(leftSide-&gt;category() != CalcOther &amp;&amp; rightSide-&gt;category() != CalcOther);</div><div>        CalculationCategory newCategory = determineCategory(*leftSide, *rightSide, op);</div><div>        if (newCategory == CalcOther)<br>            return 0;</div><div>        return adoptRef(new CSSCalcBinaryOperation(<wbr>leftSide, rightSide, op, newCategory));<br>    }</div><div> </div><div>The values in question are as follows:</div><div>calling CSSCalcBinaryOperation::create from parseAdditiveValueExpression<br>operatorCharacter 2 = -<br>lhs = 1 rhs = 1<br>in CSSCalcBinaryOperation::create<br>leftSide category = 5<br>rightSide category = 1<br> </div><div>Now exactly same values cause ASSERT on ppc64le, causing a crash whereas it just passes smoothly on x86_64.</div></div></blockquote><div> </div></span><div>It can be that you are using release build on x86_64, where asserts are disabled</div><div class="HOEnZb"><div class="h5"><div> </div><blockquote type="cite"><div><div>The C/C++ compiler is identical on both the platforms:</div><div> </div><div>on x86_64:</div><div># g++ -v<br>Using built-in specs.<br>COLLECT_GCC=g++<br>COLLECT_LTO_WRAPPER=/usr/lib/<wbr>gcc/x86_64-linux-gnu/5/lto-<wbr>wrapper<br>Target: x86_64-linux-gnu<br>Configured with: ../src/configure -v --with-pkgversion=&#39;Ubuntu 5.4.0-6ubuntu1~16.04.4&#39; --with-bugurl=<a href="http://file:///usr/share/doc/gcc-5/README.Bugs" target="_blank">file:///usr/<wbr>share/doc/gcc-5/README.Bugs</a> --enable-languages=c,ada,c++,<wbr>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=<wbr>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/<wbr>java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/<wbr>jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/<wbr>jvm-exports/java-1.5.0-gcj-5-<wbr>amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/<wbr>java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,<wbr>mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu<br>Thread model: posix<br>gcc version 5.4.<span>0 20160609</span> (Ubuntu 5.4.0-6ubuntu1~16.04.4)</div><div> </div><div>on ppc64le:</div><div># g++ -v<br>Using built-in specs.<br>COLLECT_GCC=g++<br>COLLECT_LTO_WRAPPER=/usr/lib/<wbr>gcc/powerpc64le-linux-gnu/5/<wbr>lto-wrapper<br>Target: powerpc64le-linux-gnu<br>Configured with: ../src/configure -v --with-pkgversion=&#39;Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4&#39; --with-bugurl=<a href="http://file:///usr/share/doc/gcc-5/README.Bugs" target="_blank">file:///usr/<wbr>share/doc/gcc-5/README.Bugs</a> --enable-languages=c,ada,c++,<wbr>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=<wbr>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/<wbr>java-1.5.0-gcj-5-ppc64el/jre --enable-java-home --with-jvm-root-dir=/usr/lib/<wbr>jvm/java-1.5.0-gcj-5-ppc64el --with-jvm-jar-dir=/usr/lib/<wbr>jvm-exports/java-1.5.0-gcj-5-<wbr>ppc64el --with-arch-directory=ppc64le --with-ecj-jar=/usr/share/<wbr>java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --with-cpu=power8 --enable-targets=powerpcle-<wbr>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<br>Thread model: posix<br>gcc version 5.4.<span>0 20160609</span> (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4)</div><div> </div></div><div> <div>On Mon, Feb 13, 2017 at 4:26 PM, Atul Sowani <span>&lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt;</span> wrote:<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><div>@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.</div><div> </div><div>Thanks!</div></div><div><div><div> <div>On Mon, Feb 13, 2017 at 3:41 PM, Konstantin Tokarev <span>&lt;<a href="mailto:annulen@yandex.ru" target="_blank">annulen@yandex.ru</a>&gt;</span> wrote:<br><br> <blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">13.02.2017, 11:52, &quot;Atul Sowani&quot; &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt;:<br><span>&gt; I am using Qt 5.5.1.</span><br><br>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&#39;ve posted, which were fixed since that times.<br><br>Please upgrade to QtWebKit TP5 [1]. It is much closer to trunk, and will be a hard requirement for Phantom JS 2.5<br><br>[1] <a href="https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5" target="_blank">https://github.com/annulen/<wbr>webkit/releases/tag/qtwebkit-<wbr>tp5</a><div><div><br>&gt;<br>&gt; On Thu, Feb 9, 2017 at 10:15 PM, Simon Fraser &lt;<a href="mailto:simon.fraser@apple.com" target="_blank">simon.fraser@apple.com</a>&gt; wrote:<br>&gt;&gt; What WebKit revision are your sources based on? It&#39;s quite likely the this bug has been fixed.<br>&gt;&gt;<br>&gt;&gt; Simon<br>&gt;&gt;<br>&gt;&gt;&gt; On Feb 9, 2017, at 4:09 AM, Atul Sowani &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Finally I zeroed in on 3 &quot;calc&quot; candidates from the stylesheet which are causing the CSS parser to fail:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; height:calc(100vh - 200px)<br>&gt;&gt;&gt; height:calc(100vh - 230px)<br>&gt;&gt;&gt; max-height:calc(100vh - 200px)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I think it is the very first one and the remaining two never get processed.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I put in some debug statements in the code and the corresponding output for this is:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ATUL: value-&gt;id = 0 propId = 1080<br>&gt;&gt;&gt; ATUL: in CSSPropertyHeight<br>&gt;&gt;&gt; ATUL: in CSSPropertyWebkitLogicalHeight<br>&gt;&gt;&gt; ATUL: in CSSCalcValue::create<br>&gt;&gt;&gt; ATUL: in parseValueExpression, calling parseAdditiveValueExpression<br>&gt;&gt;&gt; ATUL: calling CSSCalcBinaryOperation::create from parseAdditiveValueExpression<br>&gt;&gt;&gt; ATUL: operatorCharacter = -<br>&gt;&gt;&gt; ATUL: lhs = 1 rhs = 1<br>&gt;&gt;&gt; ATUL: leftSide category = ATUL: m_category = 5<br>&gt;&gt;&gt; 5<br>&gt;&gt;&gt; ATUL: rightSide category = ATUL: m_category = 1<br>&gt;&gt;&gt; 1<br>&gt;&gt;&gt; ATUL: m_category = 5<br>&gt;&gt;&gt; ASSERTION FAILED: leftSide-&gt;category() != CalcOther &amp;&amp; rightSide-&gt;category() != CalcOther<br>&gt;&gt;&gt; css/CSSCalculationValue.cpp(<wbr>293) : static WTF::PassRefPtr&lt;WebCore::<wbr>CSSCalcBinaryOperation&gt; WebCore::<wbr>CSSCalcBinaryOperation::<wbr>create(WTF::PassRefPtr&lt;<wbr>WebCore::<wbr>CSSCalcExpressionNode&gt;, WTF::PassRefPtr&lt;WebCore::<wbr>CSSCalcExpressionNode&gt;, WebCore::CalcOperator)<br>&gt;&gt;&gt; 1   0x12e8a80c bin/phantomjs() [0x12e8a80c]<br>&gt;&gt;&gt; &lt; stack trace removed &gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; So the question is, is the calc expression valid one?<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Best regards,<br>&gt;&gt;&gt; Atul.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Thu, Feb 9, 2017 at 2:17 PM, Atul Sowani &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; @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.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; Thanks!<br>&gt;&gt;&gt;&gt; Atul.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; On Tue, Feb 7, 2017 at 3:53 PM, Konstantin Tokarev &lt;<a href="mailto:annulen@yandex.ru" target="_blank">annulen@yandex.ru</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; 07.02.2017, 12:55, &quot;Atul Sowani&quot; &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt;:<br>&gt;&gt;&gt;&gt;&gt;&gt; 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.<br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt; Unfortunately, I don&#39;t have a stand-alone test case which can be tested with qtwebkit. I am trying to load a page using PhantomJS and it&#39;s crashing. The typical URLs which cause it to crash are <a href="http://engadget.com/" target="_blank">http://engadget.com</a> and <a href="http://cnn.com/" target="_blank">http://cnn.com</a> - both of these load without any issue on x86 platform though, so the issue seems to be specific to ppc64le.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; A few suggestions:<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; 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.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; 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.<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; 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])<br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; [1] <a href="https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5" target="_blank">https://github.com/annulen/<wbr>webkit/releases/tag/qtwebkit-<wbr>tp5</a><br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt;&gt;&gt;&gt; Atul.<br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt; On Mon, Feb 6, 2017 at 5:56 PM, Yoav Weiss &lt;<a href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Atul,<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; I second Alex&#39;s suggestion (perhaps followed by HTMLLinkElement::process() and other places in that file that refer to `hrefAttr`).<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; If you have a test case online, I could try to take a look and maybe provide more guidance.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Cheers :)<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Yoav<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Fri, Feb 3, 2017 at 9:19 PM Alex Christensen &lt;<a href="mailto:achristensen@apple.com" target="_blank">achristensen@apple.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I would start looking at HTMLLinkElement::<wbr>parseAttribute.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; LinkHeader.cpp contains parsers for link headers, which are related.  Yoav knows more about those.  Those parsers ought to be united more.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Feb 3, 2017, at 1:17 AM, Atul Sowani &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; At present I am focusing on CSSParser::findURI() particularly and CSSParser::realLex() other related functionality in CSSParser.cpp - hope I am on right track. ;-)<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Please let me know if I should be looking at some other functionality as well to resolve this issue.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Thanks!<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Atul.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Fri, Feb 3, 2017 at 2:33 PM, Atul Sowani &lt;<a href="mailto:sowani@gmail.com" target="_blank">sowani@gmail.com</a>&gt; wrote:<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi,<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; I came across an issue in qtwebkit CSS parser while working on a PhantomJS crash. The issue seems to be with parsing of &lt;link rel=&quot;...&quot; href=&quot;...&quot;&gt; 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 &quot;-&quot; (e.g. &quot;<a href="http://some.domain.com/some-page-etc-etc" target="_blank">http://some.domain.com/some-<wbr>page-etc-etc</a>&quot;). The &quot;-&quot; sign is being interpreted as minus and then things go wrong. In another case I found that &quot;\g&quot; embedded in the value (e.g. &quot;<a href="http://some.domain.com/some-page/global/something" target="_blank">http://some.domain.com/some-<wbr>page/global/something</a>&quot;) is also creating issues. In essence, the parser is trying to interpret the value, which I believe, it should not.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; 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.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Atul.<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; webkit-dev mailing list<br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a><br>&gt;&gt;&gt;&gt;&gt;&gt; ,<br>&gt;&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>&gt;&gt;&gt;&gt;&gt;&gt; webkit-dev mailing list<br>&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a><br>&gt;&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; --<br>&gt;&gt;&gt;&gt;&gt; Regards,<br>&gt;&gt;&gt;&gt;&gt; Konstantin<br>&gt;&gt;&gt; ______________________________<wbr>_________________<br>&gt;&gt;&gt; webkit-dev mailing list<br>&gt;&gt;&gt; <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>&gt;&gt;&gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a><br>&gt; ,<br>&gt;<br>&gt; ______________________________<wbr>_________________<br>&gt; webkit-dev mailing list<br>&gt; <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br>&gt; <a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a><br><br><br>-- <br>Regards,<br>Konstantin</div></div></blockquote></div></div></div></div></blockquote></div></div>,<p>______________________________<wbr>_________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a></p></blockquote><div> </div><div> </div><div>-- <br>Regards,</div><div>Konstantin</div><div> </div></div></div></blockquote></div><br></div>