|
Sergey,
Thanks again. We've applied both patches and with them solved
some customer problems.
I've put your two patches into a github push request, in the hope
that the libunwind team will accept that request so that the
"official" libunwind contains these fixes. The idea that we're
depending on a "patched" libunwind scares some people, and breaks
some of their development tools.
Doug Moore
Rice University
On 09/07/2018 07:44 AM, Sergey Korolev
wrote:
Doug,
please try this patch also.
Sergey,
Your patch does remove memory allocation from the file, but
oddly, I
still have problems with malloc being invoked. The second
time I
tested with your patch, I got hung here:
#0 0x0000ffffb5a85d74 in __lll_lock_wait_private () from
/lib64/libc.so.6
#1 0x0000ffffb5a0ea38 in malloc () from /lib64/libc.so.6
#2 0x0000ffffb59c15bc in qsort_r () from /lib64/libc.so.6
#3 0x0000ffffb592c8b0 in _ULaarch64_dwarf_find_debug_frame
(found=0,
address@hidden,
address@hidden,
address@hidden,
obj_name=0xffffb67dc440
"/home/dougm/.local/lib/hpctoolkit/ext-libs/libdwarf.so.1",
start=<optimized out>,
end=<optimized out>) at
dwarf/Gfind_proc_info-lsb.c:380
#4 0x0000ffffb592cab0 in _ULaarch64_dwarf_callback
(info=0xffffeb099ef8, size=<optimized out>,
ptr=0xffffeb09a018) at
dwarf/Gfind_proc_info-lsb.c:667
#5 0x0000ffffb5abac88 in dl_iterate_phdr () from
/lib64/libc.so.6
#6 0x0000ffffb592cff4 in _ULaarch64_dwarf_find_proc_info
(as=0xffffb5948230 <local_addr_space>,
address@hidden,
address@hidden,
need_unwind_info=1, arg=0xffffeb09a9a0) at
dwarf/Gfind_proc_info-lsb.c:693
#7 0x0000ffffb592a158 in fetch_proc_info
(address@hidden,
ip=281473734119984) at dwarf/Gparser.c:454
#8 0x0000ffffb592ba08 in _ULaarch64_dwarf_reg_states_iterate
(c=0xffffeb09a1d0, cb=0xffffb6750844
<dwarf_reg_states_callback>,
token=0xffffeb09a1b8)
at dwarf/Gparser.c:1034
So, perhaps qsort isn't safe either, as odd as that seems.
Doug
Quoting Sergey Korolev <address@hidden>:
> Doug,
>
> Can you try this patch?
> http://lists.nongnu.org/archive/html/libunwind-devel/2018-06/msg00005.html
>
> пт, 7 сент. 2018 г. в 1:56, Doug Moore <address@hidden>:
>
>> It seems that unw_get_proc_info calls
dwarf_make_proc_info, calls
>> fetch_proc_info, calls dwarf_find_proc_info, calls
dl_iterate_phdr,
>> calls dwarf_callback, calls dwarf_find_debug_frame,
calls calloc, and
>> callloc is not signal safe on the aarch64 device I'm
testing on.
>>
>> So would there be a problem with replacing the
calloc/realloc memory
>> management of 'tab' in Gfind_proc_info-lsb.c with
mmap and munmap and
>> memcpy?
>>
>> Is the memory allocated for 'tab' freed anywhere?
It's not obvious that
>> it is.
>>
>> Thanks,
>>
>> Doug Moore
>>
>> Rice University
>>
>>
>> _______________________________________________
>> Libunwind-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/libunwind-devel
>>
|