From: Edward Peschko <edwardp@excitehome.net>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: watchpoints inside 'commands'
Date: Sun, 08 Apr 2001 16:59:00 -0000 [thread overview]
Message-ID: <20010408165852.A24221@excitehome.net> (raw)
In-Reply-To: <200104080808.EAA01801@delorie.com>
> Ah, okay, then how about setting a breakpoint near the exit from the
> scope where the watchpoint is defined, and setting up the commands of
> that breakpoint to silently delete the watchpoint and continue? Would
> that do what you want?
Ok, but there is no command - as far as I can tell - to 'silently delete the
watchpoint and continue'. Take the following code:
---
#include <stdio.h>
void a();
int main()
{
int xx;
for (xx = 0; xx < 100; xx++)
{
function();
}
}
int yy = 0;
void a()
{
char data[10] = "hello";
if (yy++%10 == 0)
data[0] = 'i';
}
if you say something like:
b 20
Breakpoint 1 at 0x10924: file a.c, line 20.
commands 1
> silent
> watch data[0];
> continue
then, gdb will set up a watchpoint (which I assume is a breakpoint) at 20 when
line #20 is hit. So far so good.
But the watchpoint has a different *number* each time it comes up (ie: watch
data[0] is 'watchpoint 2' on the first way round, watch data[0] is 'watchpoint
3' the second time round, etc. etc.
So this does not work. And in any case, wouldn't it be easier to say -
watch data[0] 22 25
meaning 'watch the memory space represented by data[0] from line 22 to line 25'?
Ed
> Can you get the trashing if some of the threads don't run? It's
> probably best to have the minimum number of threads that still
> reproduce the problem.
If we turn down the threads, its pretty stable (ie: it still takes time to
crash, but a longer period) And it does not crash if we take threading out
completely.
> Anyway, how many possible memory regions did you find to be trashed
> until now? If it is a relatively small number, watchpoints could
> still help (you could watch all or most of them).
its different every time.
> That's true, but you could handle this with watchpoint commands: they
> could simply print their usual stuff and then continue. Later you
> could examine the session script and decide which of the breaks were
> false alarms and which not.
That would be fine, if watchpoints didn't change their number each time you
created and deleted them...
> What you describe sounds like uninitialized pointer somewhere, or some
> other source of random addresses being poked. (Are the regions that
> get trashed really random, or do you have only a small set of possible
> victims?) If the address is really random, I'd suggest to think what
> could be the source of such randomness. A random address is not easy
> to get by in most programs.
which is why I think the interface into gcc should change to accomodate this.
Its hell to track down problems like this in program right now, it wouldn't be
(as much hell) if we had an interface like this.
Ed
next prev parent reply other threads:[~2001-04-08 16:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010405200028.A18474@excitehome.net>
2001-04-05 20:05 ` Edward Peschko
2001-04-06 2:09 ` Eli Zaretskii
2001-04-06 11:20 ` Edward Peschko
2001-04-07 0:17 ` Eli Zaretskii
2001-04-07 17:33 ` Edward Peschko
2001-04-08 1:09 ` Eli Zaretskii
2001-04-08 16:59 ` Edward Peschko [this message]
2001-04-08 17:45 ` Daniel Berlin
2001-04-08 23:21 ` Eli Zaretskii
2001-04-17 10:38 ` Andrew Cagney
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=20010408165852.A24221@excitehome.net \
--to=edwardp@excitehome.net \
--cc=eliz@is.elta.co.il \
--cc=gdb@sources.redhat.com \
/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