Klaus Zeitler writes:
> >>>>> "Klaus" == Klaus Zeitler <[EMAIL PROTECTED]> writes:
> Klaus>
> Klaus> emacs backtrace shows:
> Klaus> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> Klaus> get-buffer-window(nil)
> Klaus> gdb-display-source-buffer(#<buffer aMOEthernetPort.cpp>)
> Klaus>
> gud-display-line("/vobs/ubtssw_oam/NodeBMOs/auto_rt/rt/src/aMOEthernetPort.cpp"
> 414)
> Klaus> gud-display-frame()
> Klaus> gud-filter(#<process gud-umc.vx> "0xb2fc5c8) at
> /vobs/ubtssw_oam/NodeBMOs/auto_rt/rt/src/aMOEthernetPort.cpp:414\n\nsource
> /vobs/ubtssw_oam/NodeBMOs/auto_rt/rt/src/aMOEthernetPort.cpp:414:13146:beg:0x62ebe8\n\npre-prompt\n(gdb)
> \nprompt\n")
>
> When I checked with edebug, the variable gud-last-last-frame in
> gdb-display-source-buffer was set to:
> "source /vobs/ubtssw_oam/NodeBMOs/auto_rt/rt/src/aMOEthernetPort.cpp"
> Maybe the error is caused by that "source" ahead of the filename.
Karl Chen reported a similar problem where he had 'run' in his .gdbinit
where I said:
M-x gdb has the added complication that it is used for both options
"--fullname" and "--annotate=3" and Emacs has to work out which has been
invoked from the output. Maybe at some stage we can move the old behaviour
(--fullname) out to another command gud-gdb, say.
I can suggest two workarounds:
1) Specify the core file later:
Run gdb (like this): gdb --annotate=3 emacs
Then in the GUD buffer:
(gdb) core ~/emacs/src/core.3491
2) Use 'M-x gdba', which should work how you want but won't give you the
old behaviour.
--
Nick http://www.inet.net.nz/~nickrob
_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
