From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9357 invoked by alias); 5 Feb 2015 18:23:49 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 9328 invoked by uid 48); 5 Feb 2015 18:23:48 -0000 From: "marc.khouzam at ericsson dot com" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/16551] Execution stops when encountering a dprintf with an invalid string Date: Thu, 05 Feb 2015 18:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints X-Bugzilla-Version: 7.7 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marc.khouzam at ericsson dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: antoine.tremblay at ericsson dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-q1/txt/msg00196.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16551 --- Comment #2 from Marc Khouzam --- (In reply to Antoine Tremblay from comment #1) > The expectation of the developer should be that if a command input is wrong, > gdb > can't do what the user requested and control is returned to the developer > to fix the error. Ok, that makes sense. > I'm also uncertain about what you mean by the stopped event beeing missed ? I think a dprintf is treated as an internal breakpoint, so when one is hit, there is no *stopped event that Eclipse can see. This makes sense because we expect the execution to resume. However, in this case, the execution of the thread that hit the dprintf stayes suspended but we don't notify eclipse (with a *stopped event) so eclipse still shows everything as running, and things get stuck. > Also bug 15185 would not fix the isssue since we can only know about the bad > symbol at the runtime of that line since shared libraries could be loaded > dynamicaly thus we can't prevalidate the dprintf input as we enter it. It does seem like it would not be possible, but gdb is able to do some checking when we set conditions. I was hoping we could do something similar? I'll put a note in the relevant bug: (gdb) b 9 if ii<0 No symbol "ii" in current context. -- You are receiving this mail because: You are on the CC list for the bug.