unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: "Vladimir Murzin" <murzin.v@gmail.com>
To: "David Combs" <dkcombs@panix.com>,
	help-gnu-emacs-bounces+murzin.v=gmail.com@gnu.org,
	help-gnu-emacs@gnu.org
Subject: Re: Copy/paste issue.
Date: Mon, 7 May 2012 06:09:59 +0000	[thread overview]
Message-ID: <1573872336-1336370998-cardhu_decombobulator_blackberry.rim.net-39647548-@b25.c12.bise7.blackberry> (raw)
In-Reply-To: <jo7k3m$oi3$1@reader1.panix.com>

David,

It seems you replied to the wrong thread ;)

Best wishes,
Vladimir Murzin

-----Original Message-----
From: dkcombs@panix.com (David Combs)
Sender: help-gnu-emacs-bounces+murzin.v=gmail.com@gnu.orgDate: Mon, 7 May 2012 04:46:46 
To: <help-gnu-emacs@gnu.org>
Subject: Re: Copy/paste issue.

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



  reply	other threads:[~2012-05-07  6:09 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-31 15:44 Copy/paste issue Silvio Levy
2012-03-31 16:03 ` Drew Adams
2012-03-31 16:15 ` Peter Dyballa
     [not found] ` <mailman.205.1333209850.20052.help-gnu-emacs@gnu.org>
2012-05-07  4:46   ` David Combs
2012-05-07  6:09     ` Vladimir Murzin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-03-31  8:46 "Jérôme M. Berger"
2012-03-31  8:51 ` "Jérôme M. Berger"
2012-03-31  9:49   ` Peter Dyballa
2012-03-31 10:24     ` "Jérôme M. Berger"
2012-03-31 10:34   ` Eli Zaretskii
2012-03-31 13:47 ` XeCycle
2012-03-31 15:14   ` Drew Adams
2012-04-01  7:59   ` "Jérôme M. Berger"
     [not found] ` <mailman.189.1333201685.20052.help-gnu-emacs@gnu.org>
2012-05-07  4:19   ` David Combs
2012-05-07  6:27     ` Drew Adams
2012-05-07  7:52     ` Yaoyuan
     [not found]     ` <mailman.730.1336372071.855.help-gnu-emacs@gnu.org>
2012-05-29  1:36       ` David Combs
     [not found]     ` <mailman.731.1336377127.855.help-gnu-emacs@gnu.org>
2012-05-29  1:40       ` David Combs
2012-05-29 13:53         ` Barry Margolin

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=1573872336-1336370998-cardhu_decombobulator_blackberry.rim.net-39647548-@b25.c12.bise7.blackberry \
    --to=murzin.v@gmail.com \
    --cc=dkcombs@panix.com \
    --cc=help-gnu-emacs-bounces+murzin.v=gmail.com@gnu.org \
    --cc=help-gnu-emacs@gnu.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).