Re: Build hangs in lisp/gnus.

[Alan Mackenzie]

Hello, Eli.

On Sat, Apr 04, 2015 at 07:56:41PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 4 Apr 2015 16:42:15 +0000
> > Cc: address@hidden
> > From: Alan Mackenzie <address@hidden>

> > > Type "finish" repeatedly s long as it displays the call-stack frames,
> > > then tell here which frame was the last you saw, before it stopped
> > > showing frames.

> > I typed "finish" just once, and the looping build process resumed with
> > the message:

> > Run till exit from #4  0x00000000005f5e5d in Ffuncall (nargs=3, 
> > args=0x7fff0f1dc3a8) at eval.c:2721

> > .  Does that give any useful information?

> Yes, it now becomes important to understand what was that frame
> doing.  Can you reproduce the same hang and backtrace at will?  If so,
> after you attach GDB, and assuming the frame that calls Ffuncall is
> again frame #4, type these commands:

>  (gdb) frame 4
>  (gdb) p args[0]
>  (gdb) xtype
>  (gdb) p args[1]
>  (gdb) xtype
>  (gdb) p args[2]
>  (gdb) xtype

> For each Lisp type that "xtype" reports, there's a corresponding
> command to display the Lisp object in human-readable form: "xsymbol"
> for a symbol, "xstring" for a string, "xvectorr" for a vector, etc.
> So after each "xtype" command invoke the corresponding command to
> display the object, and let's take it from there.

OK.

args[0] is a symbol, "macroexpand".
args[1] is a cons; xlist gives: 

warning: Couldn't restore frame #3 in current thread.  Bottom (innermost)
frame selected:
#0  0x000000000054f442 in make_lisp_symbol (sym=0x5f0714
<backtrace_next+36>) at lisp.h:1068
1068      Lisp_Object a = XIL (TAG_SYMOFFSET ((char *) sym - (char *)
lispsym));
$38 = 0xf7640
Lisp_Symbol
$39 = (struct Lisp_Symbol *) 0xd6baf0
"caddr"
---
$40 = 0xcba0
Lisp_Symbol
$41 = (struct Lisp_Symbol *) 0xc81050
"x"
---
nil

, which to me looks like the list "(caddr x)".

args[2] is a symbol, "nil".

This looks very promising.  I have been messing around with "caddr",
etc., for a few weeks now, and it could well be that a change I've made
isn't as inconsequential as I thought.  In particular, I don't really
understand the form "(declare (compiler-macro cl--compiler-macro-cXXr))"
near the start of the caddr function.

Thanks for all the help!

-- 
Alan Mackenzie (Nuremberg, Germany).