On Wed, Jul 02, 2014 at 06:11:24AM -0000, Martin Pitt wrote:
> The address signature isn't built during retracing, but directly on the
> affected machine when Apport post-processes the initial crash file. It's
> used for client-side detection of duplicates and for uploading to
> whoopsie, so it would be entirely useless to only generated it in the
> data center during retracing (then we don't need it at all, we can just
> use the symbolic stack trace). There is nothing else than os.uname()
> that we can use at this point -- add_os_info() does the same but is
> called *at the same time* (during initial processing by apport), so
> replacing it with report['Architecture'] would behave exactly the same.
> 
> To ensure that I understand how you run into this -- are you trying to
> generate an SAS for crashes which previously had a broken one due to the
> gdb bug? In this case we could replace os.uname() with
> report['Architecture'] to make things easier for you. But this shouldn't
> matter on a "normal" crash/process/upload/retrace cycle, right?

In my testing the SAS can still broken with the fixed version of gdb
because you can end up with a Stacktrace, from the system experiencing
the crash, like the following:

Stacktrace:
 #0 0x4081ed22 in poll () from /lib/arm-linux-gnueabihf/libc.so.6
 No symbol table info available.
 #1 0x4067c4e6 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
 No symbol table info available.
 Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

With the Stacktrace above no SAS is created. However, after retracing it
with the fixed version of gdb we receive a much more informative
Stacktrace.

Stacktrace:
 #0 0x4081ed22 in poll () at ../sysdeps/unix/syscall-template.S:81
 No locals.
 #1 0x4067c4e6 in g_main_context_poll (priority=2147483647, n_fds=1,
fds=0x41400c68, timeout=-1, context=0xd00d0) at
/build/buildd/glib2.0-2.40.0/./glib/gmain.c:4028
         poll_func = 0x406862a5 <g_poll>
 #2 g_main_context_iterate (context=context@entry=0xd00d0,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at
/build/buildd/glib2.0-2.40.0/./glib/gmain.c:3729
         max_priority = 2147483647
         timeout = -1
         some_ready = <optimized out>
         nfds = 1
         allocated_nfds = <optimized out>
         fds = 0x41400c68
 #3 0x4067c588 in g_main_context_iteration
(context=context@entry=0xd00d0, may_block=may_block@entry=1) at
/build/buildd/glib2.0-2.40.0/./glib/gmain.c:3795
         retval = <optimized out>
 #4 0x410c1cd0 in dconf_gdbus_worker_thread (user_data=0xd00d0) at
dconf-gdbus-thread.c:82
         context = 0xd00d0
 #5 0x40695eea in g_thread_proxy (data=0x9db80) at
/build/buildd/glib2.0-2.40.0/./glib/gthread.c:764
         thread = 0x9db80
 #6 0x4077efbc in start_thread (arg=0x413ff2d0) at pthread_create.c:314
         pd = 0x413ff2d0
         unwind_buf = {cancel_jmp_buf = {{jmp_buf = {1094710504,
1094709968, 1, 1094708424, 1094708752, 1081684380, 1094710532,
-1090523248, 220780268, 207672765, 0 <repeats 54 times>}, mask_was_saved
= 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup =
0x0, canceltype = 0}}}
         not_first_call = 0
         pagesize_m1 = <optimized out>
         sp = <optimized out>
         freesize = <optimized out>
         __PRETTY_FUNCTION__ = "start_thread"
 #7 0x40827b3c in ?? () at
../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from
/srv/daisy.staging.ubuntu.com/production/cache/Ubuntu
14.04/cache-DhmXbj/sandbox/lib/arm-linux-gnueabihf/libc.so.6
 No locals.
 Backtrace stopped: previous frame identical to this frame (corrupt
stack?)

This retraced version of the Stacktrace is then used to create a SAS
which is different than what the original SAS would have been (were one
created) if the architecture of the retracing system is not the same as
the system experiencing the crash. So yes it does matter during the
normal process as all the Error Tracker retracers are x86_64.

--
Brian Murray

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1336565

Title:
  apport-retrace generates a different StacktraceAddressSignature
  depending on retracing architecture

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to