ltrace is throwing segfault while running any of the userspace command

Bug #1547152 reported by bugproxy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ltrace (Ubuntu)
Fix Released
High
Mathieu Trudel-Lapierre
Trusty
Incomplete
Low
Mathieu Trudel-Lapierre
Wily
Won't Fix
Low
Mathieu Trudel-Lapierre

Bug Description

[Impact]
ppc64el users of ltrace.

[Test cases]
- ltrace `which ls`
- ltrace /bin/ls /usr
- ltrace ps
- ltrace make (building ltrace itself, for instance)

[Regression potential]
While the changes should fix some of the more common uses of ltrace, the added/modified methods and options may break for some specific calls on ppc64el, or on other architectures (powerpc, arm) which are affected by the changes.

ARM was already failing with the available version of ltrace; this would not change the behavior on ARM.

---

== Comment: #0 - Praveen K. Pandey <email address hidden> - 2016-01-25 01:18:25 ==
Hi ,

   I Installed Ubuntu16.04 In PowerNV and try to run ltrace ls or ltrace ps it will fail with segfault .

Reproducible Step :

1- Install Ubuntu16.04 in PowerNV or as KVM or as PowerVM
2- Install ltrace package
3- Try to run ltrace with any userspace utility like "ltrace ps"

Actual Result :

Throw Seg fault

Expected :

LOG

root@lep8d:~# uname -a
Linux lep8d 4.3.0-7-generic #18-Ubuntu SMP Tue Jan 19 15:47:35 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux
root@lep8d:~#

root@lep8d:~# ltrace ps
__printf_chk(1, 0x3fffe4d40028, 0x3fffe4d40038, 0x3fffe4d400e0 <unfinished ...>
qsort(0x10017850, 0, 0, 0x3fffe4d400e0) = <void>
__gmon_start__(0x3fffe4d4f8df, 47, 0, 0x3fff81c51d68) = 0
ferror(0x6) = 230428656
__libc_start_main(0x10017e10, 0x10017df8, 0x3fff81d68f48, 0x3fff81d68f38) = 0x3fff81c1ccb0
readproctab3(0x10017e10, 24, 0x7000000000000000, 0x6c00000000000000) = 0x1000dbc1040
uptime(0x3fffe4d3faf0, 0, 152, 103) = 0x3fffe4d3faf0
__fpending(0x3fffe4d3faf8, 0, 152, 103) = 0
strrchr("\037 !"#$%&'()*+,-./0123456789:;<=>"..., '\360') = nil
escape_command(0x10030f50, 0x3fffe4d3f968, 0, 8) = 0
setlocale(LC_NUMERIC, "hijklmnopqrstuvwxyz{|}~\177\200\201\202\203\204\205\206\207"...) = nil
select(1, 0x40087468, 0x3fffe4d3fa00, 0) = 1
__xstat(268534584, "\017", 0x13) = 0
strncmp("", "unknown", 7) = -455870136
sigfillset(~<1,3,7-8,12,15,18,20,23-24,28,31,36,39,43,47-48,52,55-63>) = 230428768
getpagesize() = 6
meminfo(0, 0x100182d0, 0, 0) = 0
getpagesize( <unfinished ...>
__stack_chk_fail(0, 0x100182d0, 0, 0 <no return ...>
--- SIGSEGV (Segmentation fault) ---
strncpy(0, "Signa", 5) = 0x10017da8
dlerror() = "SEGV"
strcmp("\206 \255\373", "\001\002\003\004\005\006\a\b\t\n\v\f\r\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037 "...Signal 11 (SEGV) caught by ps (procps-ng version 3.3.10).
) = 58
readtask(0, 0, 0x10017de8, 66ps:display.c:66: please report this bug
) = 0
__snprintf_chk(11, 0, 0x3fff81c5175b, 0) = 0x10003e90
time(0x10003e90) = 30039
fork() = 0
unexpected breakpoint at 0x3fff81b339a4
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
root@lep8d:~#

== Comment: #7 - Thierry Fauck <email address hidden> - 2016-02-17 14:11:52 ==
The problem is related to procps-ng 3.3.10
Upgrade to procps-ng 3.3.11 solves the issue
Going to Mirror and ask Canonical to advise.

== Comment: #9 - Thierry Fauck <email address hidden> - 2016-02-17 14:13:10 ==
This bugs is linked to procps-ng 3.3.10 known as having some issues. Is upgrade to 3.3.11 an option ?

bugproxy (bugproxy)
tags: added: architecture-ppc64le bugnameltc-135982 severity-high targetmilestone-inin1604
Changed in ubuntu:
assignee: nobody → Taco Screen team (taco-screen-team)
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1547152/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Revision history for this message
Steve Langasek (vorlon) wrote :

Thierry, how is this a procps issue? Praveen reported that 'ltrace ls' also segfaults, and ls is not part of procps. This looks more like a duplicate of bug #1398143 (which has been stalled because there has been no new upstream release of ltrace, leaving it unclear that picking any particular upstream commit will give us something that will work on all architectures).

If there are issues with procps 3.3.10 that warrant an upgrade to 3.3.11, could you please describe what those are?

affects: ubuntu → procps (Ubuntu)
Changed in procps (Ubuntu):
status: New → Incomplete
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-02-29 07:53 EDT-------
Missed that info - forget about my last analysis then. Investigating. Thanks

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-02-29 18:40 EDT-------
I am really confused with current status - I took the version as related in LP##1398143, added the Ubuntu specific patches from the current ltrace source and
- ltrace ps
- ltrace ls
do work properly
make check is however broken mainly because of missing include files ... so I need to fix that first.

On current dev tree I found a commit which creates a loop: commit 6db31e662a7461c23b76c1de7a488e284d2e8613
but without that commit I get a lot of ltrace: trace.c:234: arch_type_alignof: Assertion `info->type != info->type' failed.
Aborted (core dumped)

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-03-03 11:18 EDT-------
With current procps 3.11 I get a clean output for ltrace ps ending with:
readproc(0x1000d321b10, 0x10030788, 0, 2261) = 0x10030788
__snprintf_chk(0x3fff8d2b0090, 240, 1, -1) = 5
strlen("20693") = 5
fwrite("20693", 5, 1, 0x3fff8d7917b8) = 1
dev_to_tty(0x3fff8d2b0090, 240, 0x8802, 0x50d5) = 5
strlen("pts/2") = 5
fwrite(" pts/2", 6, 1, 0x3fff8d7917b8) = 1
__snprintf_chk(0x3fff8d2b0090, 240, 1, -1) = 8
strlen("00:00:00") = 8
fwrite(" 00:00:00", 12, 1, 0x3fff8d7917b8) = 1
escape_command(0x3fff8d2b0090, 0x10030788, 0x20000, 0x3fffe167ff44) = 6
strlen("ltrace") = 6
fwrite(" ltrace\n0", 8, 1, 0x3fff8d7917b820693 pts/2 00:00:00 ltrace
) = 1
readproc(0x1000d321b10, 0x10030788, 0, 0x72746c20) = 0x10030788
__snprintf_chk(0x3fff8d2b0090, 240, 1, -1) = 5
strlen("20694") = 5
fwrite("20694", 5, 1, 0x3fff8d7917b8) = 1
dev_to_tty(0x3fff8d2b0090, 240, 0x8802, 0x50d6) = 5
strlen("pts/2") = 5
fwrite(" pts/2", 6, 1, 0x3fff8d7917b8) = 1
__snprintf_chk(0x3fff8d2b0090, 240, 1, -1) = 8
strlen("00:00:00") = 8
fwrite(" 00:00:00", 12, 1, 0x3fff8d7917b8) = 1
escape_command(0x3fff8d2b0090, 0x10030788, 0x20000, 0x3fffe167ff44) = 2
strlen("ps") = 2
fwrite(" ps\n00:00", 4, 1, 0x3fff8d7917b820694 pts/2 00:00:00 ps
) = 1
readproc(0x1000d321b10, 0x10030788, 0, 0xa737020) = 0
closeproc(0x1000d321b10, 0x10030788, 0x8000, 1) = 0x3fff8d790cd8
__fpending(0x3fff8d7917b8, 0, 1, 0) = 0
ferror(0x3fff8d7917b8) = 0
fclose(0x3fff8d7917b8) = 0
__fpending(0x3fff8d7916d8, 0, 0, 0) = 0
ferror(0x3fff8d7916d8) = 0
fclose(0x3fff8d7916d8) = 0
+++ exited (status 0) +++

and the behaviour of ltrace ls changed as it is not any more looping but taking a sigsegv

Agree this is not satisfactory

Revision history for this message
bugproxy (bugproxy) wrote : patch to fix ltrace ps,ls and make check

------- Comment (attachment only) From <email address hidden> 2016-03-09 08:39 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-03-09 08:40 EDT-------
Added patch to fix user space command issues as well as missing #include in test subdirs.

------- Comment From <email address hidden> 2016-03-09 08:48 EDT-------
*** Bug 136651 has been marked as a duplicate of this bug. ***

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-03-09 08:51 EDT-------
*** Bug 126342 has been marked as a duplicate of this bug. ***

Revision history for this message
bugproxy (bugproxy) wrote : patch to fix ltrace ps,ls and make check

------- Comment (attachment only) From <email address hidden> 2016-03-09 08:39 EDT-------

Revision history for this message
Steve Langasek (vorlon) wrote : Re: [Bug 1547152] patch to fix ltrace ps,ls and make check

Hi Thierry,

On Wed, Mar 09, 2016 at 02:02:16PM -0000, bugproxy wrote:
> ------- Comment (attachment only) From <email address hidden> 2016-03-09 08:39 EDT-------

> ** Attachment added: "patch to fix ltrace ps,ls and make check"
> https://bugs.launchpad.net/bugs/1547152/+attachment/4593785/+files/ltrace-LP1547152.diff

This looks promising; this is the first time I've seen a self-contained
patch that would fix ltrace for ppc64el without a new upstream release.
Does IBM believe this patch fixes
<https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/1367308>, or are
there still other patches required for ltrace to be fully functional?

Revision history for this message
Steve Langasek (vorlon) wrote :

Applying this patch to the ltrace package in xenial, I can confirm that 'ltrace ps' and 'ltrace ls' work. I still see aborts from ltrace when running some other commands (e.g., trying to run debuild under ltrace):

ltrace: breakpoints.c:194: breakpoint_turn_off: Assertion `bp->enabled >= 0' failed.

So I don't think we want to mark bug #1367308 as fixed with this patch.

Revision history for this message
Thierry FAUCK (thierry-j) wrote :

Steve,

The patch I produced is in fact a patch to the basic code I produced for ppc64el support. It is then included in the current dev. tree. Unfortunately the common code has been rewritten a lot with later commits to include new features (liked dwarf support) and that created some code changes in the ppc64el section but the essence is the same... more cleaning than anything.

However I haven't debugged the dwarf support for ppc64el so I do believe there is no need to update for now.
Current tests reported including:
- make check from source
- ltrace ps
- ltrace ls
- ltrace sleep 1
have been tested

To answer your question about commit, status is more commit eea4ad2cce289753aaa35b4e0258a76d8f8f367c with some later fixes, so it doesn't reach commit 5565cbbd8b363fae085ac3bb9fb37773325bbd1c - For example it doesn't include cosmetic commit 5565cbbd8b363fae085ac3bb9fb37773325bbd1c but functionality is there.
Hope it answers your questions.

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-03-09 16:20 EDT-------
Thanks for the idea of debuild
../ltrace.bin make debian/rules all
fails with
...
fputs(0x10034f048d0, 0x3fffab1217b8, 1, 0make: Nothing to be done for 'debian/rules'.
) = 1
fflush(0x3fffab1217b8, 0x3fffab160000, 45, 0xfffffffffbad2a84) = 0
strstr(0x10034ee2061, 0x100360f8, 33, 0) = 0
strstr(0x10034ee2061, 0x10036100, 2, 0x100360f8) = 0
sysconf(30, 0x10034f04f80, 0, 0) = 0x10000
sysconf(30, 0x10034f04f80, 2, 0x632d) = 0x10000
fflush(0x3fffab1217b8, 0x100389d8, 0xff0000ff00, -1) = 0
pipe(0x3fffcac049e8, 0, 0, -1) = 0
close(4, 0, 0, -1) = 0
sigprocmask(0, 0x10054928, 0, 0) = 0
fork(0, 0x10054928, 0, 8) = 0x7ca4
sigemptyset(0x3fffcac04b48, 0, 0, 0) = 0
sigprocmask(2, 0x3fffcac04b48, 0, 0) = 0
wait(0x3fffcac04ad8, 0x3fffcac04b48, 0, 8ltrace.bin: breakpoints.c:194: breakpoint_turn_off: Assertion `bp->enabled >= 0' failed.
Aborted (core dumped)

investigating

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-03-22 10:23 EDT-------
Would you mind checking that patch:
diff -urN ltrace-0.7.3/sysdeps/linux-gnu/ppc/plt.c ltrace-0.7.3.new/sysdeps/linux-gnu/ppc/plt.c
--- ltrace-0.7.3/sysdeps/linux-gnu/ppc/plt.c 2016-03-22 10:18:14.713800825 -0400
+++ ltrace-0.7.3.new/sysdeps/linux-gnu/ppc/plt.c 2016-03-22 10:14:59.565267626 -0400
@@ -782,7 +782,7 @@
/* In UNRESOLVED state, the RESOLVED_VALUE in fact contains
* the PLT entry value. */
if (value == libsym->arch.resolved_value)
- return CBS_CONT;
+ return CBS_STOP;
debug(DEBUG_PROCESS, "pid=%d PLT got resolved to value %#"PRIx64,
proc->pid, value);

This patch allows the following commands to pass:
* make check
=== Summary ===

# of expected passes 219

* ltrace ps, ltrace ls ---> +++ exited (status 0) +++

* ltrace make

make[1]: Leaving directory '/home/ubuntu/WORK/ltrace-0.7.3.new'
--- SIGCHLD (Child exited) ---
chdir("/home/ubuntu/WORK/ltrace-0.7.3.n"...) = 0
exit(0 <no return ...>
+++ exited (status 0) +++

------- Comment From <email address hidden> 2016-03-22 10:26 EDT-------
Changing state for patch testing

Revision history for this message
bugproxy (bugproxy) wrote : patch allowing loop or breakpoint disabling failure

------- Comment (attachment only) From <email address hidden> 2016-03-22 10:25 EDT-------

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla
Download full text (6.6 KiB)

------- Comment From <email address hidden> 2016-04-05 01:28 EDT-------
Hi try to verify the patch on ltrace source (yeterday build) seems me works fine but i am able to apply "patch allowing loop or breakpoint disabling failure" only first patch got hung while applying .

Log:

root@ubuntu:~/ltrace-0.7.3# ltrace ps
__libc_start_main(1, 0x3ffff4a5e508, 0x3ffff4a5e518, 0x3ffff4a5e5a0 <unfinished ...>
__cxa_atexit(0x10017850, 0, 0, 0x3ffff4a5e5a0) = 0
strrchr("ps", '/') = nil
setlocale(LC_ALL, "") = "en_US.UTF-8"
bindtextdomain("procps-ng", "/usr/share/locale") = "/usr/share/locale"
textdomain("procps-ng") = "procps-ng"
memset(0x3ffff4a5dfd0, '\0', 152) = 0x3ffff4a5dfd0
sigfillset(~<31-32>) = 0
sigaction(SIGSYS, { 0x10003e90, ~<31-32>, 0xffffffff, 0xffffffffffffffff }, nil) = 0
look_up_our_self(0x10030f50, 0x3ffff4a5de48, 0, 8) = 0
ioctl(1, 1074295912, 0x3ffff4a5dee0) = 0
isatty(1) = 1
getenv("COLUMNS") = nil
__strncpy_chk(0x3ffff4a5de28, 0x100181c8, 7, 16) = 0x3ffff4a5de28
__strdup(0x3ffff4a5de28, 0x100181c8, 7, 0x6e6b6e75) = 0x1002dff1060
strcasecmp("unknown", "os390") = 6
geteuid() = 0
getpagesize() = 65536
uptime(0, 0, 0, 0) = 0x7a33c
dcgettext(0, 0x10018380, 5, 0x1002dff1080) = 0x10018380
strcmp("ucmd", "pid") = 5
malloc(48) = 0x1002dff17b0
get_pid_digits(0x1002dff1ce0, 110, 119, 124) = 5
strlen("PID") = 3
mmap(0, 0x40000, 3, 34) = 0x3fff94800000
mprotect(0x3fff94830000, 0x10000, 0, 34) = 0
time(0) = 1459833894
meminfo(0x57034c26, 0x57034c26, 0, 34) = 0x3fff951143a0
openproc(96, 0, 0, 0) = 0x1002dff1d40
readproc(0x1002dff1d40, 0x100307f0, 0, 0x3fff95090160) = 0x100307f0
strcpy(0x3fff94800090, "PID") = 0x3fff94800090
fwrite(" PID", 5, 1, 0x3fff950917c8) = 1
PID TTY TIME CMD
__snprintf_chk(0x3fff94800090, 240, 1, -1) = 4
dev_to_tty(0x3fff94800090, 240, 0xe500, 1511) = 4
escape_command(0x3fff94800090, 0x100307f0, 0x20000, 0x3ffff4a5de04) = 5
1511 hvc0 00:00:00 login
1643 hvc0 00:00:00 bash
12917 hvc0 00:00:00 ltrace
12918 hvc0 00:00:00 ps
closeproc(0x1002dff1d40, 0x100307f0, 0x8000, 1) = 0x3fff95090ce0
__fpending(0x3fff950917c8, 0, 1, 0) = 0
ferror(0x3fff950917c8) = 0
fclose(0x3fff950917c8) = 0
+++ exited (status 0) +++

root@ubuntu:~/ltrace-0.7.3# ltrace ls
__libc_start_main(1, 0x3ffff3c37178, 0x3ffff3c37188, 0x3ffff3c37210 <unfinished ...>
strrchr("ls", '/') = nil
setlocale(LC_ALL, "") = "en_US.UTF-8"
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") ...

Read more...

Steve Langasek (vorlon)
affects: procps (Ubuntu) → ltrace (Ubuntu)
Changed in ltrace (Ubuntu):
assignee: Taco Screen team (taco-screen-team) → Mathieu Trudel-Lapierre (cyphermox)
Steve Langasek (vorlon)
Changed in ltrace (Ubuntu):
importance: Undecided → High
status: Incomplete → Triaged
Changed in ltrace (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ltrace - 0.7.3-5.1ubuntu4

---------------
ltrace (0.7.3-5.1ubuntu4) xenial; urgency=medium

  * debian/patches/LP1547152.diff: removed.
  * Backport more ppc64el fixes to fix tracing on PPC64; backporting the
    required bits and pieces from the rest of ltrace (LP: #1547152, #1398143)
    - add_irelative_tracing_b420a226.patch: add support for IRELATIVE tracing.
    - find_irelative_b061bae3.patch: split the function
      linux_elf_find_irelative_name out of linux_elf_add_plt_entry_irelative
    - keep_plt_reloc_in_vector_673ff510.patch: keep PLT relocs in a vector.
    - add_elf_each_symbol_7a29f9e7.patch: add elf_each_symbol function for
      iteration.
    - add_elf_can_read_next_5c37171a.patch: add the elf_can_read_next method.
    - add_elf_read_next_u_439ab5bf.patch: add methods for doing stream-like
      reads for various types.
    - add_elf_read_u8_3c636fb7.patch: add read for u8.
    - elf_read_uleb128_184779e4.patch: add elf_read_*_uleb128.
    - elf_load_dynamic_entry_4f2f66e6.patch: add function load_dynamic_entry.
    - arm_attr_decoding_df7d2311.patch: implement ARM attribute decoding,
      this can determine when hardfp is used in the process.
    - arm_fetch_backend_97a25160.patch: add fetch backend for float and double
      return values on ARM.
    - arm_backend_fixes_1383e5bd.patch: misc ARM backend fixes.
    - arm_bpc_62fc7747.patch: implement Base Procedure Call Standard.
    - arm_vfp_params_1c8596d4.patch: implement VFP parameter passing for ARM.
    - arm_vararg_without_vfp_88a0fe50.patch: we need to handle varargs in ARM
      without VFP.
    - arm_plt_rel_9e33f5ac.patch: unbreak ARM wrt the previous patch, relplt
      got removed from struct rtelf; so fix this to still work.
    - dont_ltelf_destroy_if_init_fails_0ba3c5ee.patch: don't call
      ltelf_destroy if ltelf_init fails (ie. for ENOENT).
    - ppc64el.diff: backported eea4ad2c to replace the patch that was already
      there, as it includes support for irelative and wchar.
    - jmp_irel.patch: backport 73b85aad: support tracing P_PPC64_JMP_IREL.
    - ppc64le-fixes.patch: more misc backports for ppc64 fixes, patch from
      Fedora packaging git.
      + [35a9677d] fix bugs in fetch backend of powerpc64le
      + [a46c07fc] Fix coding style in PowerPC's arch.h
      + [44789e1e] PowerPC: convert ELFv2 conditionals from preprocessor to
        plain conditions.
    - ppc64-fork.patch: backport 35742523: Fix tracing across fork on PPC64.
    - on_install_breakpoint_56134ff5.patch: ensure we do have the on_install
      breakpoint needed for the unprelink patch.
    - ppc64-unprelink.patch: backport a0093ca4: Don't crash untraced calls via
      PLT in prelinked PPC64 binaries.
    - ppc-bias.patch: backport three commits for bias and unresolved breakports
      in PPC:
      + [bf821009] Fix address biasing in PPC backend
      + [d80c5371] Fix cloning of PPC_PLT_NEED_UNRESOLVE breakpoints
      + [d8f1287b] Nits

 -- Mathieu Trudel-Lapierre <email address hidden> Wed, 06 Apr 2016 18:58:54 -0400

Changed in ltrace (Ubuntu):
status: In Progress → Fix Released
Revision history for this message
bugproxy (bugproxy) wrote :
Download full text (6.7 KiB)

------- Comment From <email address hidden> 2016-04-12 03:30 EDT-------
Hi Verified on today's build seem me working fine

root@system:~# ltrace ps
__libc_start_main(1, 0x3fffe2d3c9e8, 0x3fffe2d3c9f8, 0x3fffe2d3ca98 <unfinished ...>
__cxa_atexit(0x10017850, 0, 0, 0x3fffe2d3ca98) = 0
strrchr("ps", '/') = nil
setlocale(LC_ALL, "") = "en_US.UTF-8"
bindtextdomain("procps-ng", "/usr/share/locale") = "/usr/share/locale"
textdomain("procps-ng") = "procps-ng"
memset(0x3fffe2d3c4b0, '\0', 152) = 0x3fffe2d3c4b0
sigfillset(~<31-32>) = 0
sigaction(SIGSYS, { 0x10003e90, ~<31-32>, 0xffffffff, 0xffffffffffffffff }, nil) = 0
sigaction(SIGPWR, { 0x10003e90, ~<31-32>, 0xffffffff, 0xffffffffffffffff }, nil) = 0
look_up_our_self(0x10030f50, 0x3fffe2d3c328, 0, 8) = 0
ioctl(1, 1074295912, 0x3fffe2d3c3c0) = 0
isatty(1) = 1
getenv("COLUMNS") = nil
getenv("LINES") = nil
__strncpy_chk(0x3fffe2d3c308, 0x100181c8, 7, 16) = 0x3fffe2d3c308
__strdup(0x3fffe2d3c308, 0x100181c8, 7, 0x6e6b6e75) = 0x1001e8a1060
strcasecmp("unknown", "os390") = 6
strcasecmp("unknown", "svr4") = 2
geteuid() = 0
getpagesize() = 65536
uptime(0, 0, 0, 0) = 0x16c32
dcgettext(0, 0x10018380, 5, 0x1001e8a1080) = 0x10018380
strcmp("ucmd", "pid") = 5
strcmp("ucmd", "stime") = 2
malloc(48) = 0x1001e8a17b0
__strdup(0x1001db28, 48...

Read more...

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Great, thanks!

description: updated
Changed in ltrace (Ubuntu Trusty):
status: New → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
importance: Undecided → High
Changed in ltrace (Ubuntu Wily):
importance: Undecided → High
Changed in ltrace (Ubuntu Trusty):
importance: High → Low
Changed in ltrace (Ubuntu Wily):
importance: High → Low
assignee: nobody → Mathieu Trudel-Lapierre (cyphermox)
Revision history for this message
Martin Pitt (pitti) wrote :

This is very intrusive, possibly destabilizing other architectures, and wily has most of its life already behind, so I'm setting wontfix for wily.

Changed in ltrace (Ubuntu Wily):
status: New → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

The trusty SRU backports a lot of new functions (which is fine), but also has a lot of arm_* patches. This bug and bug 1398143 speak about ppc64el, so why are these patches necessary?

Since there are also patches that apply to all architectures, please extend the test case to show the expected results of the ltrace calls -- e. g. should they be identical between the released and proposed versions on x86? Would any difference be a regression? If there are expected differences, please elaborate. Thanks!

Martin Pitt (pitti)
Changed in ltrace (Ubuntu Trusty):
status: In Progress → Incomplete
Revision history for this message
Martin Pitt (pitti) wrote :

I removed the upload from the trusty unapproved queue so that the SRU team stops revisiting this over and over again. Please reupload when the above issues were resolved.

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Milestoning this bug to ubuntu-16.04.2 for now, it needs to be revisited to address the issues raised by Martin.

FWIW, the arm patches were necessary changes to support other changes in the ltrace core that were required for ppc64el. It's been a while now but as I recall they didn't break arm at all, but it will need some retesting.

Changed in ltrace (Ubuntu Trusty):
milestone: none → ubuntu-14.04.5
milestone: ubuntu-14.04.5 → trusty-updates
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Oops, I think this has already been addressed in xenial appropriately, so do we really need a trusty task?

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-12-16 05:34 EDT-------
Unfortunately the code for ppc64el was done at same time as the arm code and some functions common to both have then been merged to common functions. That's why a lot of files changed and not only the ppc part.
So this has been addressed since 16.04

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.