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