Crash in `i frame'

[Richard Stallman]

In GDB 6.4 on GNU/Linux, I did `i frame' after a strange Emacs crash
involving stack clobberage.  The command did not work, reporting
"internal error" in dwarf-frame2.c:676.  (I am typing this from
memory; I can't be sure of the file name, but the line number was
definitely 676.)

The selected frame was the innermost one, and was calling
__kernel_vsyscall (that may not be the precise spelling).

`i frame' is a low-level command for last resort examination of the
stack, in comfusing cases.  It must be written defensively, so that it
_always_ works, no matter how unreasonable the data is.  It must never
report "internal error"; it must do something reasonable, no matter
what data it finds.

Please ack when this is fixed -- it is very important.


___
Bug-gdb mailing list
Bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb

Re: Emacs .gdbinit incompatible with latest GDB

[Richard Stallman]

the recent GDB has problems running GDB `xbacktrace' on EMACS
http://sources.redhat.com/ml/gdb/2007-02/msg00252.html

It seems clear why the change was made:

On the other hand byte arrays become unreadable if printed as strings.

However, it seems that their hope this would not bother anyone was based
on an assumption which is inaccurate:

  I hope nobody uses sign-specification for strings.

Which GDB behavior is better is a matter of how often each one is
convenient and how often it causes trouble.  I don't know enough to
have an opinion about that, but if neither one is clearly better
overall, it would be best to leave GDB the way it was.




___
bug-gdb mailing list
bug-gdb@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gdb

Bug in entering numbers

[Richard Stallman]

In GDB 7.0.1-debian

print -2147483648

outputs

$1 = 2147483648

which I think is not right.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.


___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb

Suggestion for `return'

[Richard Stallman]

The `return' command should set a flag so that `continue' behaves like
`signal 0'.  I know about the need for `signal 0' to avoid crashing,
but just now I forgot it and lost important data.  I think that anyone
who takes the trouble to return out of a stack frame has indicated
a desire to keep running the program rather than let it handle the signal.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.


___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb

Bug in tracing frames

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In gdb 7.01-debian, Emacs got into an infloop and I typed C-g C-g to
get back to GDB.  I got the following incomplete backtrace.  Evidently
GDB is unable to trace the stack back properly from the signal
handler.

This is on the Lemote Yeeloong.

Please ack receipt of this message.


#0  0x76a4d3c4 in kill () from /lib/libc.so.6
#1  0x00657004 in sys_suspend () at sysdep.c:450
#2  0x0063fcf8 in handle_interrupt (in_signal_handler=true) at keyboard.c:10318
#3  0x0063fb18 in handle_interrupt_signal (sig=2) at keyboard.c:10259
#4  0x006599b0 in deliver_process_signal (sig=2, 
handler=0x63fa78 ) at sysdep.c:1568
#5  0x0063fb74 in deliver_interrupt_signal (sig=2) at keyboard.c:10266
#6  
#7  0x in ?? ()
#8  0x in ?? ()

Lisp Backtrace:
"get-text-property" (0x7fff09e8)
"font-lock-extend-jit-lock-region-after-change" (0x7fff0dbc)
"run-hook-with-args" (0x7fff0db8)
"jit-lock-after-change" (0x7fff1144)
"replace-match" (0x7fff1348)
"grep-filter" (0x7fff1698)
"run-hooks" (0x7fff1710)
"compilation-filter" (0x7fff19dc)

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.


___
bug-gdb mailing list
bug-gdb@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gdb

[mam@Theory.Stanford.EDU: note from Prof Knuth]

[Richard Stallman]

I think this is really a GDB bug.  If you find it is a bug
in some other program, please DTRT.

--- Start of forwarded message ---
From: Maggie McLoughlin <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: note from Prof Knuth
Reply-to: [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
X-BeenThere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,

List-Id: Bug reports for GNU Emacs,
the Swiss army knife of text editors 
List-Unsubscribe: ,

List-Archive: 
Date: Wed, 20 Dec 2000 00:04:09 -0800 (PST)
Content-Type: text
Content-Length: 2756

Here's a small but annoying bug in GDB (or just possibly in GCC).
I have version 4.18, configured as "i386-redhat-linux".
My gcc is "egcs-2.91.66".

Three small files that illustrate the problem are appended below.
File "simple.c" was generated by "ctangle simple simple simple",
from the CWEB source file "simple.w" and the CWEB change file "simple.ch".
The #line directives in simple.c refer back to those source files.

When I invoke GDB from EMACS and say "break main" and then "run", I usually can
single step through my programs using "n" repeatedly, and the other window
shows where I am in the source files.

But in this case, GDB gets lost. When I get to the source line that
prints "The last line", the "n" instruction does not stop after that
instruction; I mean, it executes the change-file line that prints "No, this
one is actually last" without giving me a chance to single-step through
that instruction.

Of course I reduced a huge program down to this simple case, so that you
could diagnose the bug more easily. In the real program, there are
lots of instructions I never get to see when single-stepping. So I'm
hoping you can fix the bug, thereby helping me to debug incredibly
many other CWEB programs in the future, even though the bug looks rather
harmless in this simple case.

The bug appears to go away if I reduce the program even more. For example,
it is evidently necessary to jump back and forth between simple.w and
simple.ch in the place where I've changed "A bad line" to "A good line";
without that change, GDB works as it should when it gets to the other change.

Yours truly, Don Knuth

- - cut here for "simple.c" ---
/*1:*/
#line 5 "simple.w"

#include  

main()
{
printf("The first line.\n");
#line 4 "simple.ch"
printf("A good line.\n");
#line 12 "simple.w"
/*2:*/
#line 15 "simple.w"

printf("The last line.\n");

#line 9 "simple.ch"
/*:2*//*3:*/
#line 9 "simple.ch"

printf("No, this one is actually last.\n");

/*:3*/
#line 12 "simple.w"
;
}

/*:1*/
- --- cut here for "simple.w" -
\datethis

@*A curious bug. This program tweaks a bug in \.{gdb}.

@c
#include 

main()
{
  printf("The first line.\n");
  printf("A bad line.\n");
  @;
}

@ @=
printf("The last line.\n");

@*Index.
-  cut here for "simple.ch" ---
@x change file for restarting POLYSLAVE after a checkpoint
  printf("A bad line.\n");
@y
  printf("A good line.\n");
@z
@x
@*Index.
@y
@ @=
printf("No, this one is actually last.\n");

@*Index.
@z

___
Bug-gnu-emacs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
--- End of forwarded message ---

___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb