unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P
@ 2008-03-01 12:03 David Reitter
  2008-03-01 20:58 ` Nick Roberts
  2008-03-02  5:46 ` Stefan Monnier
  0 siblings, 2 replies; 5+ messages in thread
From: David Reitter @ 2008-03-01 12:03 UTC (permalink / raw)
  To: emacs- devel

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? 




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P
  2008-03-01 12:03 crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P David Reitter
@ 2008-03-01 20:58 ` Nick Roberts
  2008-03-01 21:35   ` David Reitter
  2008-03-02  5:46 ` Stefan Monnier
  1 sibling, 1 reply; 5+ messages in thread
From: Nick Roberts @ 2008-03-01 20:58 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs- devel

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P
  2008-03-01 20:58 ` Nick Roberts
@ 2008-03-01 21:35   ` David Reitter
  2008-03-02  7:53     ` Nick Roberts
  0 siblings, 1 reply; 5+ messages in thread
From: David Reitter @ 2008-03-01 21:35 UTC (permalink / raw)
  To: Nick Roberts; +Cc: emacs- devel

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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P
  2008-03-01 12:03 crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P David Reitter
  2008-03-01 20:58 ` Nick Roberts
@ 2008-03-02  5:46 ` Stefan Monnier
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2008-03-02  5:46 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs- devel

> 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




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P
  2008-03-01 21:35   ` David Reitter
@ 2008-03-02  7:53     ` Nick Roberts
  0 siblings, 0 replies; 5+ messages in thread
From: Nick Roberts @ 2008-03-02  7:53 UTC (permalink / raw)
  To: David Reitter; +Cc: emacs-devel

 > > 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




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-03-02  7:53 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-01 12:03 crashes during Feval from within WINDOW_WANTS_HEADER_LINE_P David Reitter
2008-03-01 20:58 ` Nick Roberts
2008-03-01 21:35   ` David Reitter
2008-03-02  7:53     ` Nick Roberts
2008-03-02  5:46 ` Stefan Monnier

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).