Bug 191318 - LTC23983 ltrace sigsegvs traced process on fc5+
Summary: LTC23983 ltrace sigsegvs traced process on fc5+
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: ltrace
Version: rawhide
Hardware: ppc64
OS: Linux
medium
high
Target Milestone: ---
Assignee: Petr Machata
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-05-10 19:07 UTC by Petr Machata
Modified: 2015-05-05 01:32 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-07-15 00:53:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
first take on fixing this (4.41 KB, patch)
2006-07-12 11:27 UTC, Petr Machata
no flags Details | Diff

Description Petr Machata 2006-05-10 19:07:15 UTC
Description of problem:
ltrace sigsegvs child on ppc64

Version-Release number of selected component (if applicable):
0.4

How reproducible:
always

Steps to Reproduce:
1. x.c: "int main(void){return 0;}"
2. gcc x.c
2. ltrace a.out

Actual results:
sigsegv

Expected results:
smooth run

Additional info:
Binaries built on older machines (e.g. RHEL3/4) (maybe with older gcc?) will let
themselves trace just fine, so it's something with the way the binary on fc5+ is
generated.
There is i686 bug that could be related: #168490.

Comment 1 Petr Machata 2006-05-12 12:10:56 UTC
It all boils down to changes in /usr/lib/crti.o.  This is fc5 linkage:
$ ld -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtbegin.o x.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtsavres.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtend.o /usr/lib/crtn.o -lc
$ ./a.out; echo $?
4
$ ./ltrace ./a.out --- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

(x.o is the minimal program from comment#1, compiled with gcc -c x.c on fc5)
Now let's use crti.o from fc4:
$ ld -dynamic-linker /lib/ld.so.1 /usr/lib/crt1.o ~/fc4/crti.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtbegin.o x.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtsavres.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.0/crtend.o /usr/lib/crtn.o -lc
$ ./a.out; echo $?
4
$ ./ltrace ./a.out __libc_start_main(1, -5372, -5364, -5268, 0xf7fde740
<unfinished ...>
+++ exited (status 4) +++

Comment 2 IBM Bug Proxy 2006-06-08 20:23:26 UTC
IBM hit the same problem on rawhide. Hence connecting (or mirroring) the two
reports. Changing the version to 'devel' and severity=high to match ibm bug.
Thanks. 

Comment 3 Petr Machata 2006-07-12 10:25:43 UTC
in essence: fc5 binaries contain adresses, not instruction in PLT (so called
secure PLTs).  ltrace secure PLT branch contains the code necessary for
handling, but few issues have to be solved for it to work.  I have a strawman in
hand, it more or less works, but testsuite doesn't pass yet.  I will post a
patch later today, and will work on testsuite passing then.

Comment 4 Petr Machata 2006-07-12 11:27:24 UTC
Created attachment 132295 [details]
first take on fixing this

Testsuite still won't run with this patch.  Basic tests run, but there are few
mysterious failures I'm yet to look on.  Besides this, it's still hacky in
places.  In particular:
 * wait_for_something.c contains delayed initialization of breakpoints
 * sysdeps/linux-gnu/breakpoint.c contains explicit check if breakpoint is
already set. This isn't particularly clean, I would be better if this property
arose naturally from the way the insert_breakpoint is called.

Comment 5 Petr Machata 2006-07-12 20:43:30 UTC
The problem is that ltrace isn't able to extract return address from PT_LNK
register in sysdeps/linux-gnu/ppc/regs.c.  It gets NULL, to be correct, the call
won't end with an error.  But because of that NULL, ltrace doesn't notice when
library call ends, displays <unfinished...> message, and won't include the call
in final statistics (in case of -c option).

Other than that I'm getting a lot of __gmon_start__ calls.  No idea if they are
legal or not.  The weak-symbol detection code was wrong, but fixing didn't get
rid of these calls.

Comment 6 IBM Bug Proxy 2006-07-13 16:51:19 UTC
----- Additional Comments From gilliam.com  2006-07-13 12:55 EDT -------
I Thought that the secure PLT brance was merged into the main line.

See:
http://lists.alioth.debian.org/pipermail/ltrace-devel/2006-June/000066.html 

Comment 7 Petr Machata 2006-07-13 17:34:05 UTC
Yes, that work is done on top of trunk.  As is, the trunk still sigsegvs the
traced process on fc5+ ppc32.

Comment 8 Petr Machata 2006-07-15 00:53:35 UTC
I just did a built of svn trunk with few patches applied
(ltrace-0.5-1.0.45svn.5).  It contains the bugfix.

Comment 9 Petr Machata 2006-07-17 11:35:15 UTC
(In reply to comment #7)
> Yes, that work is done on top of trunk.  As is, the trunk still sigsegvs the
> traced process on fc5+ ppc32.
Oh, it didn't sigsegv, it just didn't trace at all.


Comment 10 IBM Bug Proxy 2006-10-10 11:26:48 UTC
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |OPEN




------- Additional Comments From shenlinf.com  2006-10-10 07:24 EDT -------
Test ltrace in fc6-test3 and it works fine.
-------------
[root@auroralp2 ~]# uname -a
Linux auroralp2.upt.austin.ibm.com 2.6.17-1.2630.fc6 #1 SMP Wed Sep 6 17:17:26
EDT 2006 ppc64 ppc64 ppc64 GNU/Linux
[root@auroralp2 ~]# rpm -q ltrace
ltrace-0.5-6.45svn.fc6
[root@auroralp2 ~]# ltrace ls
WARNING: Using e_entry from elf header (0x10002a10) for address of "_start"
unexpected breakpoint at 0xf7fc6400
_start(1, 0xf874fd04, 0xf874fd0c, 0xf874fd5c, 0xf7fbea00 <unfinished ...>
__libc_start_main(1, 0xf874fd04, 0xf874fd0c, 0xf874fd5c, 0xf7fbea00 <unfinished ...>
setlocale(6, "")                                 = "en_US.UTF-8"
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils")                          = "coreutils"
__cxa_atexit(0x10009e00, 0, 0, 0xff218b8, 4)     = 0 


Note You need to log in before you can comment on or make changes to this bug.