← Back to team overview

touch-packages team mailing list archive

[Bug 1352591] Re: apport-retrace does not update libraries in a sandbox

 

There is also not a check to see whether or not the path in
InterpreterPath or ExecutablePath is current. From sandboxutils.py:

   # package hooks might reassign Package:, check that we have the originally
    # crashing binary
    for path in ('InterpreterPath', 'ExecutablePath'):
        if path in report and not os.path.exists(sandbox_dir + report[path]):

So we only check for the existence not whether or not it is recent.
Subsequently, a retrace with a old executable can fail like so.

Reading symbols from /tmp/apport-utopic//usr/lib/arm-linux-gnueabihf/indicator-network/indicator-network-service...Reading symbols from /tmp/ap
port-utopic/usr/lib/debug/.build-id/5a/851287dfe6af740803822fa635ea6fa5fa5f19.debug...done.
done.
warning: core file may not match specified executable file.

** Summary changed:

- apport-retrace does not update libraries in a sandbox
+ apport-retrace does not update libraries or executable in a sandbox

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1352591

Title:
  apport-retrace does not update libraries or executable in a sandbox

Status in Apport crash detection/reporting:
  New
Status in “apport” package in Ubuntu:
  New

Bug description:
  I was trying to retrace a crash that failed with the retracers in the
  Ubuntu Error Tracker.  I'm using gdb-multiarch from the following PPA
  (https://launchpad.net/~daisy-pluckers/+archive/ubuntu/daisy-seeds)
  and apport from bzr revision number 2818. The command follows:

  PYTHONPATH=$PYTHONPATH:/srv/daisy.staging.ubuntu.com/prod
  uction/apport python /srv/daisy.staging.ubuntu.com/production/apport/bin/apport-retrace ~/4d9d6984-1883-11e4-84c3-fa163e22e467.crash -S /srv/da
  isy.staging.ubuntu.com/production/daisy/retracer/config --sandbox-dir /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu\ 14.10/cache-DhmXbj/sandbox -C /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu\ 14.10/cache-DhmXbj/cache -v -g

  With that bt full would return:

  Thread 1 (LWP 2270):
  #0  __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:44
  No locals.
  #1  0xb6a3805e in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
          _a1 = 0
          _a3tmp = 6
          _a1tmp = 0
          _a3 = 6
          _nametmp = 268
          _a2tmp = 2270
          _a2 = 2270
          _name = 268
          _sys_result = <optimized out>
          pd = 0xb680e000
          pid = 0
          selftid = 2270
  #2  0xb6a38d4e in __GI_abort () at abort.c:89
          save_stage = 2
          act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {1, 3064945215, 3064945144, 3064575611, 
                3064342309, 3069180536, 3061899264, 3069180712, 3061899264, 3065241600, 729240, 0, 1, 3199521020, 0, 3069123061, 3069180712, 
                1, 5, 0, 3199521440, 3064036264, 1, 3064946200, 1, 10212828, 3199521044, 3069005824, 3199521440, 3069141488, 10212360, 
                3061900488}}, sa_flags = 2, sa_restorer = 0x0}
          sigs = {__val = {32, 0 <repeats 31 times>}}
  #3  0xb6b892c4 in ?? ()
     from /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu 14.10/cache-DhmXbj/sandbox-corrupt/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
  No symbol table info available.
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)

  However, using apport-retrace without the sandbox-dir command creates
  a more complete backtrace like in http://paste.ubuntu.com/7929061/.

  I've tracked this down to the following from needed_runtime_packages
  in apport/sandboxutils.py:

      # grab as much as we can
      for l in libs:
          if os.path.exists(sandbox + l):
              continue

  There is no check to see if the sandbox version of the library is
  current or not, subsequently the library may be out of date which was
  causing the retrace to fail.

  I've verified this by checking the ctime of the file before and after
  commenting out the "if os.path.exists()" check.

  ls -lch /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu\ 14.10/cache-DhmXbj/sandbox-old/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
  lrwxrwxrwx 1 root root 19 Jul 11 02:19 /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu 14.10/cache-DhmXbj/sandbox-old/usr/lib/arm-linux-gnueabihf/libstdc++.so.6 -> libstdc++.so.6.0.20

  ls -lch /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu\ 14.10/cache-DhmXbj/sandbox-corrupt/usr/lib/arm-linux-gnueabihf/libstdc++.so.6
  lrwxrwxrwx 1 root root 19 Aug  4 22:27 /srv/daisy.staging.ubuntu.com/production/cache/Ubuntu 14.10/cache-DhmXbj/sandbox-old/usr/lib/arm-linux-gnueabihf/libstdc++.so.6 -> libstdc++.so.6.0.20

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1352591/+subscriptions