** 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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1951470 Title: webkit javascript segmentation fault To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1951470/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
