** Description changed: + SRU Justification: + + [Impact] + + * WebKit Javascript engine is causing a segmentation fault on big + endian (s390x) systems. + + * This happens for example when transferring an html to a pdf file + using wkhtmltopdf. + + * The fix is relatively simple with changing loadisFromInstruction to loadpFromInstruction + in macro getProperty(slow), which solves this unpleasant situation. + + * The JIT ocde is 32bit (even on 64bit systems), + hence is crucial to make sure the lower part of a 64bit value is taken on big endian systems. + + [Test Plan] + + * Testing is very straight forward by following these steps: + + * install the following packages (incl. their dependencies): + $ sudo apt install libqt5webkit5 wkhtmltopdf + + * create an html file like this: + $ vi index.html + $ cat index.html + <!doctype html> + <html lang="de"> + <head> + </head> + + <body> + <script src="min.js"></script> + </body> + </html> + + * create a JavaScript file like this: + $ vi min.js + $ cat min.js + var i = Math.max + + * call wkhtmltopdf to process the local files: + $ wkhtmltopdf --enable-local-file-access index.html test.pdf + + * if it's broken one gets this output: + Loading page (1/2) + Segmentation fault (core dumped) ] 50% + and no pdf file was generated: + $ ls *.pdf + ls: cannot access '*.pdf': No such file or directory + + * in case it's fixed one gets this output: + Loading page (1/2) + Printing pages (2/2) + Done + and a pdf file was generated and in placed in the current directory (with more than 0 bytes size): + $ ls -l ./*.pdf + -rw-rw-r-- 1 ubuntu ubuntu 1339 Nov 24 11:48 ./test.pdf + + [Where problems could occur] + + * While this issue only affects big endian systems (like s390x), + a bad fix may have an impact on little endian systems, too + for example in case the wrong function got used in the macro. + + * But loadpFromInstruction is known to work for LE and BE systems; + + * and on top cross-architecture builds were done: + https://launchpad.net/~fheimes/+archive/ubuntu/lp1951470 + + * and tested on s390x (if the fix works) and on non-s390x (regression + testing). + + * The changes are otherwise very limited, just: + macro getProperty(slow) + - loadisFromInstruction(6, t1) + + loadpFromInstruction(6, t1) + hence I think there is not much more to say. + + [Other Info] + + * The maintainer of the Debian packages (Dmitry Shachnev) + is going to add this to the Debian package, too. + + * This issue affects Ubuntu jammy, impish, hirsute and focal - SRUs are + ongoing. + + * The issue does not occur with the very latest upstream version anymore, + and was fixed in a similar way as part of a commit + that fixes numerous other CLoop issues on top: + "Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change)." + commit 3fdde71c7d95d758a61fcbc4c58168616794c102 + + __________ + == Comment: #0 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 09:29:44 == ---Problem Description--- Segmentation fault from WebKit Javascript engine - - Contact Information = andreas.kreb...@de.ibm.com - + + Contact Information = andreas.kreb...@de.ibm.com + ---uname output--- Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 s390x s390x s390x GNU/Linux - - Machine Type = IBM Z - + + Machine Type = IBM Z + ---Debugger--- A debugger is not configured - + ---Steps to Reproduce--- - index.html: + index.html: <!doctype html> <html lang="de"> - <head> - </head> + <head> + </head> - <body> - <script src="min.js"></script> - </body> + <body> + <script src="min.js"></script> + </body> </html> min.js: var i = Math.max wkhtmltopdf index.html test.pdf QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Loading page (1/2) Segmentation fault (core dumped) ] 17% - - Userspace tool common name: wkhtmltopdf - - The userspace tool has the following bit modes: 64 + + Userspace tool common name: wkhtmltopdf + + The userspace tool has the following bit modes: 64 Userspace rpm: libqt5webkit5 - Userspace tool obtained from project website: na - + Userspace tool obtained from project website: na + *Additional Instructions for andreas.kreb...@de.ibm.com: -Attach ltrace and strace of userspace application. == Comment: #1 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 09:44:04 == In CodeBlock.cpp the code preparing the operands of op_get_from_scope writes the property offset as pointer size (hence 64 bit) value: 2141: instructions[i + 6].u.pointer = reinterpret_cast<void*>(op.operand); while the same slot is accessed later by the jitted code as 32 bit integer: macro getProperty(slow) - loadisFromInstruction(6, t1) + loadisFromInstruction(6, t1) This fails on big endian targets since the integer access takes the higher part of the 64 bit value. Changing: macro getProperty(slow) - loadisFromInstruction(6, t1) + loadisFromInstruction(6, t1) to macro getProperty(slow) - loadpFromInstruction(6, t1) + loadpFromInstruction(6, t1) in llint/LowLevelInterpreter64.asm fixes the problem for me. - - I could not reproduce the problem on Ubuntu 20.10. In upstream webkit the problem got fixed as a side effect of a larger change but in the end quite similar to the change I'm proposing. The value resides somewhere else now but it is accessed as 64 bit value in getProperty: + I could not reproduce the problem on Ubuntu 20.10. In upstream webkit + the problem got fixed as a side effect of a larger change but in the end + quite similar to the change I'm proposing. The value resides somewhere + else now but it is accessed as 64 bit value in getProperty: macro getProperty() - loadp OpGetFromScope::Metadata::m_operand[t5], t1 - + loadp OpGetFromScope::Metadata::m_operand[t5], t1 If you have the jsc binary from the webkit package available the problem can be reproduced with just 'jsc -e "i=Math.min"' == Comment: #2 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 09:49:55 ==
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qtwebkit-opensource-src in Ubuntu. https://bugs.launchpad.net/bugs/1951470 Title: webkit javascript segmentation fault Status in Ubuntu on IBM z Systems: In Progress Status in qtwebkit-opensource-src package in Ubuntu: In Progress Status in qtwebkit-opensource-src source package in Focal: New Status in qtwebkit-opensource-src source package in Hirsute: New Status in qtwebkit-opensource-src source package in Impish: New Status in qtwebkit-opensource-src source package in Jammy: In Progress Bug description: SRU Justification: [Impact] * WebKit Javascript engine is causing a segmentation fault on big endian (s390x) systems. * This happens for example when transferring an html to a pdf file using wkhtmltopdf. * The fix is relatively simple with changing loadisFromInstruction to loadpFromInstruction in macro getProperty(slow), which solves this unpleasant situation. * The JIT ocde is 32bit (even on 64bit systems), hence is crucial to make sure the lower part of a 64bit value is taken on big endian systems. [Test Plan] * Testing is very straight forward by following these steps: * install the following packages (incl. their dependencies): $ sudo apt install libqt5webkit5 wkhtmltopdf * create an html file like this: $ vi index.html $ cat index.html <!doctype html> <html lang="de"> <head> </head> <body> <script src="min.js"></script> </body> </html> * create a JavaScript file like this: $ vi min.js $ cat min.js var i = Math.max * call wkhtmltopdf to process the local files: $ wkhtmltopdf --enable-local-file-access index.html test.pdf * if it's broken one gets this output: Loading page (1/2) Segmentation fault (core dumped) ] 50% and no pdf file was generated: $ ls *.pdf ls: cannot access '*.pdf': No such file or directory * in case it's fixed one gets this output: Loading page (1/2) Printing pages (2/2) Done and a pdf file was generated and in placed in the current directory (with more than 0 bytes size): $ ls -l ./*.pdf -rw-rw-r-- 1 ubuntu ubuntu 1339 Nov 24 11:48 ./test.pdf [Where problems could occur] * While this issue only affects big endian systems (like s390x), a bad fix may have an impact on little endian systems, too for example in case the wrong function got used in the macro. * But loadpFromInstruction is known to work for LE and BE systems; * and on top cross-architecture builds were done: https://launchpad.net/~fheimes/+archive/ubuntu/lp1951470 * and tested on s390x (if the fix works) and on non-s390x (regression testing). * The changes are otherwise very limited, just: macro getProperty(slow) - loadisFromInstruction(6, t1) + loadpFromInstruction(6, t1) hence I think there is not much more to say. [Other Info] * The maintainer of the Debian packages (Dmitry Shachnev) is going to add this to the Debian package, too. * This issue affects Ubuntu jammy, impish, hirsute and focal - SRUs are ongoing. * The issue does not occur with the very latest upstream version anymore, and was fixed in a similar way as part of a commit that fixes numerous other CLoop issues on top: "Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change)." commit 3fdde71c7d95d758a61fcbc4c58168616794c102 __________ == Comment: #0 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 09:29:44 == ---Problem Description--- Segmentation fault from WebKit Javascript engine Contact Information = andreas.kreb...@de.ibm.com ---uname output--- Linux 193438490afd 5.8.15-301.fc33.s390x #1 SMP Thu Oct 15 15:55:57 UTC 2020 s390x s390x s390x GNU/Linux Machine Type = IBM Z ---Debugger--- A debugger is not configured ---Steps to Reproduce--- index.html: <!doctype html> <html lang="de"> <head> </head> <body> <script src="min.js"></script> </body> </html> min.js: var i = Math.max wkhtmltopdf index.html test.pdf QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' Loading page (1/2) Segmentation fault (core dumped) ] 17% Userspace tool common name: wkhtmltopdf The userspace tool has the following bit modes: 64 Userspace rpm: libqt5webkit5 Userspace tool obtained from project website: na *Additional Instructions for andreas.kreb...@de.ibm.com: -Attach ltrace and strace of userspace application. == Comment: #1 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 09:44:04 == In CodeBlock.cpp the code preparing the operands of op_get_from_scope writes the property offset as pointer size (hence 64 bit) value: 2141: instructions[i + 6].u.pointer = reinterpret_cast<void*>(op.operand); while the same slot is accessed later by the jitted code as 32 bit integer: macro getProperty(slow) loadisFromInstruction(6, t1) This fails on big endian targets since the integer access takes the higher part of the 64 bit value. Changing: macro getProperty(slow) loadisFromInstruction(6, t1) to macro getProperty(slow) loadpFromInstruction(6, t1) in llint/LowLevelInterpreter64.asm fixes the problem for me. I could not reproduce the problem on Ubuntu 20.10. In upstream webkit the problem got fixed as a side effect of a larger change but in the end quite similar to the change I'm proposing. The value resides somewhere else now but it is accessed as 64 bit value in getProperty: macro getProperty() loadp OpGetFromScope::Metadata::m_operand[t5], t1 If you have the jsc binary from the webkit package available the problem can be reproduced with just 'jsc -e "i=Math.min"' == Comment: #2 - Andreas Krebbel <andreas.kreb...@de.ibm.com> - 2021-11-15 09:49:55 == To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1951470/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
