successfully verified on impish:

ubuntu@s1lp11:~$ lsb_release -cs
impish
ubuntu@s1lp11:~$ sudo apt-cache policy libqt5webkit5
libqt5webkit5:
  Installed: (none)
  Candidate: 5.212.0~alpha4-12ubuntu0.21.10.1
  Version table:
     5.212.0~alpha4-12ubuntu0.21.10.1 500
        500 http://us.ports.ubuntu.com/ubuntu-ports impish-proposed/universe 
s390x Packages
     5.212.0~alpha4-12 500
        500 http://ports.ubuntu.com/ubuntu-ports impish/universe s390x Packages
ubuntu@s1lp11:~$ sudo apt install libqt5webkit5 wkhtmltopdf
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  libqt5webkit5 wkhtmltopdf
0 upgraded, 2 newly installed, 0 to remove and 13 not upgraded.
Need to get 10.7 MB of archives.
After this operation, 44.1 MB of additional disk space will be used.
Get:1 http://us.ports.ubuntu.com/ubuntu-ports impish-proposed/universe s390x 
libqt5webkit5 s390x 5.212.0~alpha4-12ubuntu0.21.10.1 [10.5 MB]
Get:2 http://ports.ubuntu.com/ubuntu-ports impish/universe s390x wkhtmltopdf 
s390x 0.12.6-1 [168 kB]
Fetched 10.7 MB in 1s (20.7 MB/s)    
Selecting previously unselected package libqt5webkit5:s390x.
(Reading database ... 98404 files and directories currently installed.)
Preparing to unpack 
.../libqt5webkit5_5.212.0~alpha4-12ubuntu0.21.10.1_s390x.deb ...
Unpacking libqt5webkit5:s390x (5.212.0~alpha4-12ubuntu0.21.10.1) ...
Selecting previously unselected package wkhtmltopdf.
Preparing to unpack .../wkhtmltopdf_0.12.6-1_s390x.deb ...
Unpacking wkhtmltopdf (0.12.6-1) ...
Setting up libqt5webkit5:s390x (5.212.0~alpha4-12ubuntu0.21.10.1) ...
Setting up wkhtmltopdf (0.12.6-1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.34-0ubuntu3) ...
Scanning processes...                                                           
         
Scanning processor microcode...                                                 
         
Scanning linux images...                                                        
         

Failed to check for processor microcode upgrades.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.
ubuntu@s1lp11:~$ sudo apt-cache policy libqt5webkit5
libqt5webkit5:
  Installed: 5.212.0~alpha4-12ubuntu0.21.10.1
  Candidate: 5.212.0~alpha4-12ubuntu0.21.10.1
  Version table:
 *** 5.212.0~alpha4-12ubuntu0.21.10.1 500
        500 http://us.ports.ubuntu.com/ubuntu-ports impish-proposed/universe 
s390x Packages
        100 /var/lib/dpkg/status
     5.212.0~alpha4-12 500
        500 http://ports.ubuntu.com/ubuntu-ports impish/universe s390x Packages
ubuntu@s1lp11:~$ wkhtmltopdf --enable-local-file-access index.html test.pdf
Loading page (1/2)
Printing pages (2/2)                                               
Done                                                           
ubuntu@s1lp11:~$ ls -l ./test.pdf 
-rw-rw-r-- 1 ubuntu ubuntu 1339 Nov 30 20:30 ./test.pdf
ubuntu@s1lp11:~$ 

** Tags removed: verification-needed-impish
** Tags added: verification-done-impish

-- 
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:
  Fix Committed
Status in qtwebkit-opensource-src package in Ubuntu:
  Fix Released
Status in qtwebkit-opensource-src source package in Focal:
  Fix Committed
Status in qtwebkit-opensource-src source package in Hirsute:
  Fix Committed
Status in qtwebkit-opensource-src source package in Impish:
  Fix Committed
Status in qtwebkit-opensource-src source package in Jammy:
  Fix Released

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

Reply via email to