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.
prev 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: linkBe 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).