crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P

crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P

[David Reitter]

I'm getting crashes after extending a macro.  I would appreciate your  
help.

I have added to the WINDOW_WANTS_HEADER_LINE_P macro (dispextern.h) a  
function call to an elisp function whose name is stored in `window- 
wants-header-line-function':

       && (NILP(Vwindow_wants_header_line_function)  
||                   \
	  !NILP (safe_call_win(Vwindow_wants_header_line_function, (W)))))



safe_call_win looks pretty straight-forward:

/* Call function FN with window argument.
    Return the result, or nil if something went wrong. */

Lisp_Object
safe_call_win (fn, w)
      Lisp_Object fn;
      struct window *w;
{
   Lisp_Object window;
   Lisp_Object val;
   struct gcpro gcpro1;
   val = Qnil;
   window = Qnil;
   if ((FUNCTIONP (fn)))
     {
       XSETWINDOW (window, w);
       GCPRO1 (window);
       val = safe_call1 (fn, window);
       UNGCPRO;
     }
   return val;
}

However, I keep getting crashes, always during the evaluation of said  
function:

5   libSystem.B.dylib             	0x966639af abort + 73
6   org.gnu.Emacs                 	0x000f320b Feval + 923 (eval.c:2362)
7   org.gnu.Emacs                 	0x000f360f Fprogn + 63 (eval.c:450)
8   org.gnu.Emacs                 	0x000f38df funcall_lambda + 671  
(eval.c:3185)
9   org.gnu.Emacs                 	0x000f3c2b Ffuncall + 443 (eval.c: 
3062)
10  org.gnu.Emacs                 	0x000f1f3a  
internal_condition_case_2 + 266 (eval.c:1583)
11  org.gnu.Emacs                 	0x0001717e safe_call + 158 (xdisp.c: 
2348)
12  org.gnu.Emacs                 	0x000171c5 safe_call1 + 37 (xdisp.c: 
2362)
13  org.gnu.Emacs                 	0x00017278 safe_call_win + 168  
(xdisp.c:2382)
14  org.gnu.Emacs                 	0x0016cc4b draw_fringe_bitmap_1 +  
1467 (fringe.c:669)
15  org.gnu.Emacs                 	0x0016cf2a draw_fringe_bitmap + 90  
(fringe.c:868)

The elisp function that is called just evaluates to nil or t and  
doesn't do anything else. (It does work in some cases.)
The crashes do not depend on the `window' argument, and they do not go  
away if I play around with the GCPRO call or an additional BLOCK_INPUT.

What's going on? 

Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P

[Nick Roberts]

I'm not an expert, but

 > I'm getting crashes after extending a macro.  I would appreciate your  
 > help.
 > 
 > I have added to the WINDOW_WANTS_HEADER_LINE_P macro (dispextern.h) a  
 > function call to an elisp function whose name is stored in `window- 
 > wants-header-line-function':
 > 
 >        && (NILP(Vwindow_wants_header_line_function)  
 > ||                   \
 > 	  !NILP (safe_call_win(Vwindow_wants_header_line_function, (W)))))
 > 
 > 
 > 
 > safe_call_win looks pretty straight-forward:
 > 
 > /* Call function FN with window argument.
 >     Return the result, or nil if something went wrong. */
 > 
 > Lisp_Object
 > safe_call_win (fn, w)
 >       Lisp_Object fn;
 >       struct window *w;
 > {
 >    Lisp_Object window;
 >    Lisp_Object val;
 >    struct gcpro gcpro1;
 >    val = Qnil;
 >    window = Qnil;
 >    if ((FUNCTIONP (fn)))
 >      {
 >        XSETWINDOW (window, w);

I don't think you need GCPRO1 here

 >        GCPRO1 (window);
 >        val = safe_call1 (fn, window);
 >        UNGCPRO;
 >      }
 >    return val;
 > }
 > 
 > However, I keep getting crashes, always during the evaluation of said  
 > function:

and it looks to me like the elisp function whose name is stored in
`window-wants-header-line-function' is a lisp primitive which either has
too many argumnts ( > 8 ) or whose argument list has been incorrectly
defined.

 > 5   libSystem.B.dylib             	0x966639af abort + 73
 > 6   org.gnu.Emacs                 	0x000f320b Feval + 923 (eval.c:2362)
 > 7   org.gnu.Emacs                 	0x000f360f Fprogn + 63 (eval.c:450)
 > 8   org.gnu.Emacs                 	0x000f38df funcall_lambda + 671  
 > (eval.c:3185)
 > 9   org.gnu.Emacs                 	0x000f3c2b Ffuncall + 443 (eval.c: 
 > 3062)
 > 10  org.gnu.Emacs                 	0x000f1f3a  
 > internal_condition_case_2 + 266 (eval.c:1583)
 > 11  org.gnu.Emacs                 	0x0001717e safe_call + 158 (xdisp.c: 
 > 2348)
 > 12  org.gnu.Emacs                 	0x000171c5 safe_call1 + 37 (xdisp.c: 
 > 2362)
 > 13  org.gnu.Emacs                 	0x00017278 safe_call_win + 168  
 > (xdisp.c:2382)
 > 14  org.gnu.Emacs                 	0x0016cc4b draw_fringe_bitmap_1 +  
 > 1467 (fringe.c:669)
 > 15  org.gnu.Emacs                 	0x0016cf2a draw_fringe_bitmap + 90  
 > (fringe.c:868)
 > 
 > The elisp function that is called just evaluates to nil or t and  
 > doesn't do anything else. (It does work in some cases.)
 > The crashes do not depend on the `window' argument, and they do not go  
 > away if I play around with the GCPRO call or an additional BLOCK_INPUT.
 > 
 > What's going on? 

but I might have it wrong.

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

Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P

[David Reitter]

On 1 Mar 2008, at 20:58, Nick Roberts wrote:

>> However, I keep getting crashes, always during the evaluation of said
>> function:
>
> and it looks to me like the elisp function whose name is stored in
> `window-wants-header-line-function' is a lisp primitive which either  
> has
> too many argumnts ( > 8 ) or whose argument list has been incorrectly
> defined.

I found the same in the code, but this is not true. The function is

(defun need-header-line-p (window)  t)

and it seems to get called in some situations without problems.
Perhaps there is some re-entrance business when re-display is  
triggered from the Lisp side? Is that possible?

I've not found much in the way of documentation (beyond a section in  
the the Emacs Lisp Reference), and it's pretty hard to find one's way  
into the C source.

Either way, I've solved my problem now without calling a Lisp function.

- D

Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P

[Nick Roberts]

 > > and it looks to me like the elisp function whose name is stored in
 > > `window-wants-header-line-function' is a lisp primitive which either has
 > > too many argumnts ( > 8 ) or whose argument list has been incorrectly
 > > defined.
 > 
 > I found the same in the code, but this is not true. The function is
 > 
 > (defun need-header-line-p (window)  t)

You're right, abort is called from Feval, not Ffuncall.

 > and it seems to get called in some situations without problems.
 > Perhaps there is some re-entrance business when re-display is  
 > triggered from the Lisp side? Is that possible?
 > 
 > I've not found much in the way of documentation (beyond a section in  
 > the the Emacs Lisp Reference), and it's pretty hard to find one's way  
 > into the C source.

The source _is_ the documentation, as they say.  I've found lisp.h a good
starting point. Any real documentation can easily become outdated but the
XEmacs Internals Manual by Ben Wing is good for some things, like specbinding.
Generally though, if it seems difficult to understand the source code that's
probably because it is difficult to understand the source code: there's no
silver bullet.

 > Either way, I've solved my problem now without calling a Lisp function.
 > 
 > - D

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

Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P

[Stefan Monnier]

> I'm getting crashes after extending a macro.  I would appreciate your help.

> I have added to the WINDOW_WANTS_HEADER_LINE_P macro (dispextern.h)
> a function call to an elisp function whose name is stored in `window- 
> wants-header-line-function':

>       && (NILP(Vwindow_wants_header_line_function) ||                   \
> 	  !NILP (safe_call_win(Vwindow_wants_header_line_function, (W)))))

I'd be surprised if this macro is only used at places where it is safe
to run elisp code.  When doing such things, I highly recommend you run
with -DENABLE_CHECKING (which I don't guarantee will catch your
problem, but may).


        Stefan