Re: [Libunwind-devel] Enabling test suite on Ubuntu 12.10

[Arun Sharma]

On Mon, Jul 30, 2012 at 4:12 AM, James Page <address@hidden> wrote:

> Thanks for the guidance; I'm currently running with the following
> patches to ensure the test suite executes:
>
> Index: libunwind/tests/test-ptrace.c
> ===================================================================
> - --- libunwind.orig/tests/test-ptrace.c  2012-07-30 10:05:35.271168000
> +0100
> +++ libunwind/tests/test-ptrace.c   2012-07-30 11:39:37.309158623 +0100
> @@ -182,6 +182,11 @@
>
>        /* automated test case */
>        argv = args;
> +
> +      /* Unless the args array is 'walked' the child
> +         process is unable to access it and dies with a segfault */
> +      fprintf(stderr, "Automated test (%s,%s,%s,%s)\n",
> +              args[0],args[1],args[2],args[3]);
>      }
>    else if (argc > 1)
>      while (argv[optind][0] == '-')
>
> I'm not entirely sure I understand why the above works; I actually
> added this to see why the test was failing - at which point it started
> passing again.

Could you paste the output of:

./test-ptrace  -v /bin/ls /usr >out 2>&1

That'd tell us where things are going wrong. With the latest git, the
failure comes from stacks like:

00007f8879c08955 __pthread_initialize_minimal+0xb5 (sp=00007fff60d07600)
        proc=00007f8879c088a0-00007f8879c08c3f
        handler=0 lsda=0
00007f8879c072b9 _init+0x9                        (sp=00007fff60d076e0)
        proc=00007f8879c072b9-00007f8879c072ba
        handler=0 lsda=0
00007fff60d09548 +0x9                             (sp=00007fff60d076f0)
        proc=00007fff60d09548-00007fff60d09549
        handler=0 lsda=0
485353007273752f +0x9                             (sp=00007fff60d07700)
        proc=485353007273752f-4853530072737530
        handler=0 lsda=0
=====FAILURE: unw_step() returned -8 for ip=0 (start ip=7f8879c11db5)
unwind failed with ret=-8

I suspect this is hand written asm in glibc with missing unwind info.
Looks like it was discussed almost a decade ago:

http://sources.redhat.com/ml/libc-hacker/2003-11/msg00115.html

The test by default tries to stop the target program (/bin/ls /usr in
this case) at each system call and tries to unwind the stack. You can
also run with the -i flag to stop at each instruction to make sure
that every instruction in the target could be unwound from. But that'd
be very slow.

These errors were masked in earlier versions of libunwind because we
stopped unwinding when ip==0. I changed that when someone asked for
support for unwinding from a signal handler where ip==0.

>
> Index: libunwind/tests/Gtest-nocalloc.c
> ===================================================================
> - --- libunwind.orig/tests/Gtest-nocalloc.c   2012-07-30
> 10:05:35.271168000 +0100
> +++ libunwind/tests/Gtest-nocalloc.c    2012-07-30 10:17:34.794107721
> +0100
> @@ -123,6 +123,8 @@
>      if (pthread_key_create (&key, NULL))
>        panic ("FAILURE: unable to create key %d\n", i);
>    }
> +  do_backtrace();
> +  num_mallocs = num_callocs = 0;
>    foo1 ();
>    num_errors = num_mallocs + num_callocs;
>    if (num_errors > 0)
>
> Picked from the gperftools ML.

I'll pick this change up. The test was meant as a reminder for
libunwind users to call backtrace() just after thread creation, so
libunwind doesn't do any further calls to malloc and friends from that
thread.

>
> I've described the above two patches above as workarounds as neither
> actually addresses the underlying problem AFAIK.
>
> I've also disabled the *-dyn1 tests and cherry picked a fix to resolve
> the setjmp test failure from the libunwind git repo.
>
> Does this sound reasonable?

Very much so.

 -Arun