------- Comment From andreas.kreb...@de.ibm.com 2021-11-22 02:30 EDT------- (In reply to comment #10) > This does not look like an Ubuntu system. Linux kernel has wrong version: > "Linux 193438490afd 5.8.15-301.fc33.s390x". Are you sure you are testing it > on Ubuntu image?
I just mechanically copied the uname -a output there forgetting that I was working in a container. Hence the output is bogus, please ignore. But as mentioned already the issue is not kernel related anyway. ------- Comment From andreas.kreb...@de.ibm.com 2021-11-22 02:37 EDT------- (In reply to comment #13) ... > @Andreas Is your proposed fix known to be save for other platform (LE), too? Yes, the fix should be safe for LE platforms as well. Before that change it just accidentally worked on LE. But this would need to be tested of course. > And can you point me to the upstream issue where this got fixed? It looks like it got fixed as part of a commit which fixes numerous other CLoop issues: commit 3fdde71c7d95d758a61fcbc4c58168616794c102 Author: Mark Lam <mark....@apple.com> Date: Mon Jan 14 21:34:47 2019 +0000 Fix all CLoop JSC test failures (including some LLInt bugs due to recent bytecode format change). https://bugs.webkit.org/show_bug.cgi?id=193402 <rdar://problem/46012309> Reviewed by Keith Miller. There you can find a similar change as in my proposed patch. However, it is based on a commit which changed how these data are stored. So it might not be obvious to backport it. On the other hand it looks like it contains more fixes which we might want to have as well. llintOpWithMetadata(op_get_from_scope, OpGetFromScope, macro (size, get, dispatch, metadata, return) macro getProperty() - loadis OpGetFromScope::Metadata::operand[t5], t3 + loadp OpGetFromScope::Metadata::operand[t5], t3 loadPropertyAtVariableOffset(t3, t0, t1, t2) valueProfile(OpGetFromScope, t5, t1, t2) return(t1, t2) ** Bug watch added: bugs.webkit.org/ #193402 https://bugs.webkit.org/show_bug.cgi?id=193402 -- 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: Confirmed Status in qtwebkit-opensource-src package in Ubuntu: Confirmed Bug description: == 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
