public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "eclipsehivernale at sfr dot fr" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug server/16168] Signal heavy execution + repeated breakpoint locks up gbserver
Date: Sun, 23 Nov 2014 15:33:00 -0000	[thread overview]
Message-ID: <bug-16168-4717-K4uHO0XjxM@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-16168-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=16168

--- Comment #4 from eclipsehivernale at sfr dot fr ---
I am a software developer of a multi threaded application (about 10 threads).
Recently we decided to use tcmalloc instead of the glibc malloc.
It is a google open source malloc optimized for multi allocation allocation.

Since this change, it is impossible to use gdbserver.
The SIGPROF signal management is automatic in tcmalloc library.
After a few "next" operation, gdbserver hangs, waiting for a pending event from
thread which has received a SIGPROF signal, exactly like you describe in your
comment.

It is still possible to use gdb directly on the remote target, but this is a
waste of time.
I also observed once gdb hanged in native configuration, but I can't tell for
sure it is the same issue as I just killed it and tried again.

I tested the patch you posted:
https://sourceware.org/ml/gdb-patches/2013-11/msg00361.html and it seems to
work fine on 7.8.50.20141107.

There are other freeze/hangs reported in the bug zilla database that may be
linked to this issue, since it can appear by using any running operation (next,
step, break...) and every gdb version so far are impacted.

I think more and more people will face this issue (tcmalloc + multi threaded
application without control on SIGPROF) and I would like to push to integrate a
fix in the next version of gdb.

Anyway thanks a lot to you for the investigation and the fix suggestion.
If no action is taken to fix gdb then I guess I will use your fix locally
forever.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


      parent reply	other threads:[~2014-11-23 15:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 20:28 [Bug server/16168] New: " saugustine at google dot com
2013-11-14  1:06 ` [Bug server/16168] " saugustine at google dot com
2013-12-04 19:36 ` dje at google dot com
2013-12-04 19:37 ` dje at google dot com
2014-11-23 15:05 ` eclipsehivernale at sfr dot fr
2014-11-23 15:33 ` eclipsehivernale at sfr dot fr [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-16168-4717-K4uHO0XjxM@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=gdb-prs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).