This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]
- From: "Eli Zaretskii" <eliz at gnu dot org>
- To: David Lecomber <david at streamline-computing dot com>
- Cc: drow at false dot org, gdb-patches at sources dot redhat dot com
- Date: Sun, 21 Nov 2004 07:16:19 +0200
- Subject: Re: [PATCH] Seg fault whilst stepping when watch set [ping!] [in breakpoint.c]
- References: <01c4cef8$Blat.v2.2.2$3fd12960@zahav.net.il> <1100996751.22991.39.camel@cpc2-oxfd5-5-0-cust91.oxfd.cable.ntl.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: David Lecomber <david@streamline-computing.com>
> Cc: Daniel Jacobowitz <drow@false.org>, patches <gdb-patches@sources.redhat.com>
> Date: Sun, 21 Nov 2004 00:25:51 +0000
>
> > Also, last time we talked, I asked whether this could be due to the
> > Fedora exec-shield feature, but didn't see any response to that.
> > Could you please check that?
>
> I'm not sure how to verify that one
There should be a way to switch exec-shield off, but I don't know how.
I meant to ask you to see if switching it off makes the problem go
away.
> Thanks for looking at this bug, here's the latest stack trace and
> session log for current CVS:
Thanks, there seems to be a different problem (or maybe several
problems):
> (gdb) b f90demo.f90 : 41
> During symbol reading, unsupported tag: 'DW_TAG_module'.
> During symbol reading, Attribute value is not a constant
> (DW_FORM_block1).
> [...]
> (gdb) watch i
> During symbol reading, incomplete CFI data; unspecified registers (e.g.,
> eax) at 0x804bc35.
Can someone please explain what do these messages mean, in the context
of the problem at hand, and why didn't David report them in a previous
GDB version? Did the same problems happen in the older GDB as well,
but were just silently ignored, or are we looking at a completely
different cause for a segfault?
Also, David, I asked you to check why doesn't GDB segfault when it
evaluates the same expression on line 1142, before calling
insert_bp_location.
> I know the patch I originally suggested could be a cure of the symptom,
> rather than the cause - but as it's harmless, if we can't figure out why
> it happens, it could be worth just committing anyway: all the patch does
> is check a value is non-null, and if so takes action - without the patch
> such a scenario will always segfault!
Sorry, I'm reluctant to approve a patch that fixes a problem that we
are unable to understand. It's not clean.