From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: dkcombs@panix.com (David Combs) Newsgroups: gmane.emacs.help Subject: Re: Copy/paste issue. Date: Mon, 7 May 2012 04:46:46 +0000 (UTC) Organization: Public Access Networks Corp. Message-ID: References: <20120331154408.40E7F180CAB@neo.msri.org> NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1336366216 6762 80.91.229.3 (7 May 2012 04:50:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 May 2012 04:50:16 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon May 07 06:50:15 2012 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SRFtk-0002ic-4Z for geh-help-gnu-emacs@m.gmane.org; Mon, 07 May 2012 06:50:12 +0200 Original-Received: from localhost ([::1]:35487 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SRFtj-0002H5-Bs for geh-help-gnu-emacs@m.gmane.org; Mon, 07 May 2012 00:50:11 -0400 Original-Path: usenet.stanford.edu!panix!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 50 Original-NNTP-Posting-Host: panix1.panix.com Original-X-Trace: reader1.panix.com 1336366006 25155 166.84.1.1 (7 May 2012 04:46:46 GMT) Original-X-Complaints-To: abuse@panix.com Original-NNTP-Posting-Date: Mon, 7 May 2012 04:46:46 +0000 (UTC) X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Original-Xref: usenet.stanford.edu gnu.emacs.help:192337 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:84745 Archived-At: Talking about binary search for finding bugs. In this thread you're talking about binary search on an input file. Of course, you can also do that on the running of a program. I use a language ("MainSail") that makes that particularly simple. When compiled debuggable, there places in the binary where it lets you set breakpoints. It also keeps a global variable "brkcnt", break-count, of the number of possible places you could set a breakpoint that you have run past thus far. So, suppose that the program crashes at some surprise place, and looking around in the debugger shows nothing obvious -- except, HEY!, how'd that file-pointer get nulled out (or get changed to point not to a file, etc). And there's nowhere nearby that that pointer gets played with. What to do? Well, you know what the current brkcnt is right now, at the crash-point. And you know that early on that file-pointer was just fine. So you start setting one breakpoint at each test run, and do it by bisection. For each run, when it breaks (at the current bisection point), you check that pointer for correctness. If it's ok, you kill the program, reset the break point to halfway between there and the crash point, and run it again. If it's not ok, you kill the program, set the break point to halfway in the other direction. It's just amazing HOW FAST you can home in on THE instruction that zeros the file pointer. A million instructions (in YOUR code, not non-debuggable libraries) range -- you find the error point in just ten runs. --- Well, I'm sure I'm not telling you guys anything new; you've probably been doing this for decades. But anyway, I thought it was pretty cool, an easy way to home in on what would otherwise be an almost impossible task to find. David