Bug 1064406

Summary: [abrt] ltrace: allocate_integer(): ltrace killed by SIGABRT
Product: [Fedora] Fedora Reporter: Jeff Buhrt <buhrt>
Component: ltraceAssignee: Petr Machata <pmachata>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: mnewsome, pmachata
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/bd73c8035306f523a2bcd79df7aaa5d0bb0c94ef
Whiteboard: abrt_hash:27875dfb81aeb7d3c034c55fc723625b6e470508
Fixed In Version: ltrace-0.7.2-9.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-15 15:06:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description Jeff Buhrt 2014-02-12 14:34:50 UTC
Description of problem:
ltrace -p <Thunderbird pid>
wait say 10-15 seconds and ltrace core dumps.
I was read to click 'Edit' on a message filter. No mail was downloading at the time.
-a user with a cleaned dconf database seems to core quickly. Editing a Thunderbird filter would take less than a second in this case. Rebuilt using: dconf dump / > dconf-dump; dconf load / < dconf-dump

A different user may run ltrace longer or not have an error.
-In this case a possibly corrupt/unoptimized dconf/user file seems to allow ltrace to survive (longer). Ironically editing a Thunderbird filter would take ~1min 17sec in this case. (no dconf rebuild)

strace works fine in both cases.


 gdb /usr/bin/ltrace core.18342
...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `ltrace -p 18271'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb7732424 in __kernel_vsyscall ()
(gdb) where
#0  0xb7732424 in __kernel_vsyscall ()
#1  0x4930fb96 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#2  0x493113d3 in __GI_abort () at abort.c:89
#3  0x08058675 in allocate_integer (context=<optimized out>, valuep=<optimized out>, offset=0, pool=POOL_FUNCALL, 
    sz=<optimized out>) at fetch.c:270
#4  0x08058aab in arch_fetch_pool_arg_next (context=0x86cf800, proc=<optimized out>, info=0x86b9620, valuep=0xbfba8750, 
    pool=POOL_FUNCALL, type=<optimized out>) at fetch.c:757
#5  0x08058f8a in arch_fetch_arg_next (context=<optimized out>, context@entry=0x86cf800, type=<optimized out>, 
    type@entry=LT_TOF_FUNCTION, proc=<optimized out>, proc@entry=0x86ca358, info=info@entry=0x86b9620, 
    valuep=valuep@entry=0xbfba8750) at fetch.c:826
#6  0x080544dc in fetch_arg_next (context=context@entry=0x86cf800, type=type@entry=LT_TOF_FUNCTION, 
    proc=proc@entry=0x86ca358, info=info@entry=0x86b9620, valuep=valuep@entry=0xbfba8750) at fetch.c:138
#7  0x08062654 in fetch_simple_param (type=type@entry=LT_TOF_FUNCTION, proc=proc@entry=0x86ca358, 
    context=context@entry=0x86cf800, arguments=arguments@entry=0x86cf8e0, info=0x86b9620, own=<optimized out>, 
    own@entry=0, valuep=valuep@entry=0x0) at output.c:272
#8  0x08063586 in fetch_one_param (params_leftp=<synthetic pointer>, param=0x86b9640, arguments=0x86cf8e0, 
    context=0x86cf800, proc=0x86ca358, type=LT_TOF_FUNCTION) at output.c:356
#9  fetch_params (func=<optimized out>, func=<optimized out>, params_leftp=<synthetic pointer>, arguments=0x86cf8e0, 
    context=0x86cf800, proc=0x86ca358, type=LT_TOF_FUNCTION) at output.c:384
#10 output_left (type=type@entry=LT_TOF_FUNCTION, proc=0x86ca358, libsym=0x86bac38) at output.c:489
#11 0x08061882 in handle_breakpoint (event=0x8074168 <event>, event=0x8074168 <event>) at handle_event.c:666
#12 handle_event (event=event@entry=0x8074168 <event>) at handle_event.c:179
#13 0x0804a744 in ltrace_main () at libltrace.c:194
#14 0x0804a101 in main (argc=3, argv=0xbfba8964) at main.c:55

Version-Release number of selected component:
ltrace-0.7.2-8.fc20

Additional info:
reporter:       libreport-2.1.12
backtrace_rating: 4
cmdline:        ltrace -p 14005
crash_function: allocate_integer
executable:     /usr/bin/ltrace
kernel:         3.12.10-300.fc20.i686+PAE
runlevel:       N 5
type:           CCpp
uid:            0

Truncated backtrace:
Thread no. 1 (10 frames)
 #3 allocate_integer at fetch.c:270
 #4 arch_fetch_pool_arg_next at fetch.c:757
 #5 arch_fetch_arg_next at fetch.c:826
 #6 fetch_arg_next at fetch.c:138
 #7 fetch_simple_param at output.c:272
 #8 fetch_one_param at output.c:356
 #9 fetch_params at output.c:384
 #10 output_left at output.c:489
 #11 handle_breakpoint at handle_event.c:666
 #12 handle_event at handle_event.c:179

Comment 1 Jeff Buhrt 2014-02-12 14:35:02 UTC
Created attachment 862341 [details]
File: backtrace

Comment 2 Jeff Buhrt 2014-02-12 14:35:03 UTC
Created attachment 862342 [details]
File: cgroup

Comment 3 Jeff Buhrt 2014-02-12 14:35:05 UTC
Created attachment 862343 [details]
File: core_backtrace

Comment 4 Jeff Buhrt 2014-02-12 14:35:07 UTC
Created attachment 862344 [details]
File: dso_list

Comment 5 Jeff Buhrt 2014-02-12 14:35:08 UTC
Created attachment 862345 [details]
File: environ

Comment 6 Jeff Buhrt 2014-02-12 14:35:10 UTC
Created attachment 862346 [details]
File: limits

Comment 7 Jeff Buhrt 2014-02-12 14:35:13 UTC
Created attachment 862347 [details]
File: maps

Comment 8 Jeff Buhrt 2014-02-12 14:35:14 UTC
Created attachment 862348 [details]
File: open_fds

Comment 9 Jeff Buhrt 2014-02-12 14:35:17 UTC
Created attachment 862349 [details]
File: proc_pid_status

Comment 10 Jeff Buhrt 2014-02-12 14:35:19 UTC
Created attachment 862350 [details]
File: var_log_messages

Comment 11 Petr Machata 2014-02-13 14:13:08 UTC
I can reproduce it thus:

thunderbird & sleep 4; time ~/Fedora/ltrace/ltrace-0.7.2/ltrace -f -p $(jobs -p)

... this fails almost immediately.  The problem seems to be in attach to multi-threaded program, where struct process.e_machine isn't set properly for non-leader threads, and fetch backend gets confused.

Comment 12 Fedora Update System 2014-02-13 16:08:31 UTC
ltrace-0.7.2-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/ltrace-0.7.2-9.fc20

Comment 13 Fedora Update System 2014-02-14 07:49:38 UTC
Package ltrace-0.7.2-9.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ltrace-0.7.2-9.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-2423/ltrace-0.7.2-9.fc20
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2014-03-15 15:06:11 UTC
ltrace-0.7.2-9.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.