https://sourceware.org/bugzilla/show_bug.cgi?id=25069
--- Comment #2 from leftcopy.chx at gmail dot com ---
(In reply to Mark Wielaard from comment #1)
> I am unable to replicate this. Are you able to replicate with current git
> trunk (with the recent fixes for eu-unstrip)?
I cannot replicate wi
https://sourceware.org/bugzilla/show_bug.cgi?id=25069
--- Comment #3 from leftcopy.chx at gmail dot com ---
Created attachment 12053
--> https://sourceware.org/bugzilla/attachment.cgi?id=12053&action=edit
poc that triggers the crash against git 99dc63b1
Found another poc that triggers this cras
* Jonathon Anderson:
> Just finished some modifications to the patch series, git request-pull
> output below. This rebases onto the latest master and does a little
> diff cleaning, the major change is that I swapped out the memory
> management to use the pthread_key_* alternative mentioned befo
On Sat, 2019-10-26 at 12:54 +0200, Florian Weimer wrote:
> * Jonathon Anderson:
>
> > Just finished some modifications to the patch series, git request-pull
> > output below. This rebases onto the latest master and does a little
> > diff cleaning, the major change is that I swapped out the memor
On Sat, 2019-10-26 at 02:47 +, build...@builder.wildebeest.org
wrote:
> The Buildbot has detected a failed build on builder whole buildset
> while building elfutils.
> Full details are available at:
> https://builder.wildebeest.org/buildbot/#builders/10/builds/376
>
It looks like the s390
* Mark Wielaard:
> I'll see if I can create a case where that is a problem. Then we can
> see how to adjust things to use less pthread_keys. Is there a different
> pattern we can use?
It's unclear what purpose thread-local storage serves in this context.
You already have a Dwarf *. I would consi
Hello Florian Weimer,
I'm the original author of this patch, so I'll try to answer what I can.
For some overall perspective, this patch replaces the original libdw
allocator with a thread-safe variant. The original acts both as a
suballocator (to keep from paying the malloc tax on frequent sma
* Jonathon Anderson:
>> This assumes that memory allocation
>> is actually a performance problem, otherwise you could let malloc
>> handle the details.
>
> In our (Dyninst + HPCToolkit) work, we have found that malloc tends to
> be slow in the multithreaded case, in particular with many small
>
https://sourceware.org/bugzilla/show_bug.cgi?id=25069
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://sourceware.org/bugzilla/show_bug.cgi?id=25069
Mark Wielaard changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|libelf
Hi,
On Sat, 2019-10-26 at 11:45 -0500, Jonathon Anderson wrote:
> For some overall perspective, this patch replaces the original libdw
> allocator with a thread-safe variant. The original acts both as a
> suballocator (to keep from paying the malloc tax on frequent small
> allocations) and a ga
Hi,
On Sat, 2019-10-26 at 18:50 +0200, Florian Weimer wrote:
> * Jonathon Anderson:
>
> > > This assumes that memory allocation
> > > is actually a performance problem, otherwise you could let malloc
> > > handle the details.
> >
> > In our (Dyninst + HPCToolkit) work, we have found that malloc
On Sun, Oct 27, 2019 at 00:50, Mark Wielaard wrote:
Hi,
On Sat, 2019-10-26 at 11:45 -0500, Jonathon Anderson wrote:
For some overall perspective, this patch replaces the original libdw
allocator with a thread-safe variant. The original acts both as a
suballocator (to keep from paying the
13 matches
Mail list logo
