This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/16159] malloc_printerr() deadlock, when calling malloc_printerr() again
- From: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 14 Nov 2013 16:47:48 +0000
- Subject: [Bug malloc/16159] malloc_printerr() deadlock, when calling malloc_printerr() again
- Auto-submitted: auto-generated
- References: <bug-16159-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=16159
--- Comment #19 from Ondrej Bilka <neleai at seznam dot cz> ---
On Thu, Nov 14, 2013 at 03:54:30PM +0000, bugdal at aerifal dot cx wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16159
>
> --- Comment #18 from Rich Felker <bugdal at aerifal dot cx> ---
> Ondrej, did you even check your results with readelf or ldd? -lgcc is a static
> library and is always linked, so of course it won't make any difference. You
> need to test with -lgcc_s (and double-check to make sure the dependency really
> got added).
>
I asked for benchmark because of that, with a lgcc_s there is difference.
plain
real 0m3.039s
user 0m0.195s
sys 0m3.049s
with lgcc_s
real 0m3.141s
user 0m0.169s
sys 0m3.179s
with lpthread
real 0m3.282s
user 0m0.182s
sys 0m3.308s
> BTW, I'm not sure how well your test will do measuring exec time versus other
> overhead. If you'd like, I have a test I can post that execs itself and
> measures the actual time from just before the execve syscall to the start of
> main.
>
These also count as I wanted to show a relative performance impact. If
this is taken into extreme we could improve performance by staticaly linking lm
and lpthread
Or using prelink.
--
You are receiving this mail because:
You are on the CC list for the bug.