[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs geometry

From: Nick Roberts
Subject: Re: Emacs geometry
Date: Tue, 1 Aug 2006 11:51:52 +1200

 > > `pr' is tricky; I'm guessing that the Windows pipe emulation on the
 > > Emacs side and the console output on the GDB side don't work together
 > > well enough for `pr' to work from within Emacs.  (`pr' does work for
 > > me if I invoke GDB from the Command Prompt window outside Emacs.)  Use
 > > `xtype' to see the type and xint, xsymbol, xcar, etc., according to
 > > what xtype prints, to see the value.
 > Phew, finally! (c:
 > (gdb) p Fassq (Qtop, f->param_alist)
 > $1 = 23713793
 > (gdb) xtype
 > Lisp_Symbol
 > (gdb) xsymbol
 > $2 = (struct Lisp_Symbol *) 0x169d800
 > "nil"
 > (gdb)
 > That was done withing a MinGW shell.  `pr' isn't working in that shell
 > either.

I think Eli is right as to why, `pr' actually prints by executing Emacs.  The
commentary in gdb-ui.el has something about how to make the output stream
unbuffered (Note: I don't use Windows, it's just advice someone else gave me).

>From your earlier e-mail:

>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>   string-match("//+" nil)
>>   gud-find-file(nil)
>>   gdb-set-hollow()
>>   gdb-prompt("")
>>   gud-gdba-marker-filter([...])
>>   apply([...])
>>   gud-marker-filter([...])
>>   gud-filter(#<process gud-emacs.exe> [...])

I'm a bit baffled because gdb-prompt doesn't call gdb-set-hollow, only
gdb-info-stack-custom does.  I've recently changed the code (yesterday)
so this part doesn't get called by default so you may have to set
gdb-find-source-frame to t to reproduce it.

If you do move the executable (as with "make install") you need to be sure
that GDB can still find the source (some debug formats store the information,
others don't).  Starting GDB in the source tree means GDB will find the
source because it looks in the current directory.

If you do:

* starting GDB from the command line and using `emacs.exe' as the
  executable to debug
* loading .gdbinit from GDB with `source /path/to/.gdbinit'
* setting a breakpoint with `b w32_createwindow'
* running Emacs with `run -g 80x30+10+20'

Does it say something like?:

2071      w32fns.c: No such file or directory.
          in w32fns.c

Even so Emacs should say the same thing and not generate a backtrace.  Can
you find out how gdb-set-hollow gets called e.g do debug-on-entry there,
or Edebug on gdb-prompt?

Nick                                           http://www.inet.net.nz/~nickrob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]