unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: newsspam5REMOVETHIS@robf.de
To: help-gnu-emacs@gnu.org
Subject: Re: How to debug "Debugger entered--Lisp error: (void-function nil)"
Date: Sun, 08 Apr 2007 22:02:36 +0200	[thread overview]
Message-ID: <85wt0mfxcz.fsf@robf.de> (raw)
In-Reply-To: 87hcs0q31d.fsf@lion.rapttech.com.au

Tim X <timx@nospam.dev.null> writes:
[...]
>>> What you need to do is track down the init error in your .vm file. Normally,
>>> the backtrace will show the call stack, but what you have copied appears to
>>> just be the last (top) element in the stack. With the rest of the call stack
>>> you can usually narrow down the search as it will show you what emacs was doing
>>> prior to trying to call the void function. 
>>
>> This is exactly my problem, GNU Emacs does NOT give anything more,
>> i.e. those two lines are all I get in my backtrace buffer.
>>
>
> hmmm. Not sure exactly what that means. Sounds like the error is happening at
> the very top level of the stack, which I would have thought was 'unusual' if
> the error is being generated by an add-on package rather than in the core of
> emacs. 

Yeah, that is really odd ;-/

>
>>> I'd suggest going through your VM config and comment out everything and then
>>> try adding each value back, one at a time until you get the error again. 
>>
>> It is not in the config, it is in (my) VM sources and it does not
>> happen for XEmacs with the same sources and configuration.
>>
>
> So, your getting the same error without any .vm file?

Yes. 

> Are you certain your xemacs and emacs source trees are totally
> separate and there isn't some path shadowing going on thats
> giving you a mix of emacs 21 and xemacs compiled code?

Definitely.

>>> To give you confidence it will work, I'm running VM under emacs 22. I've not
>>> had any problems except a couple of weeks ago when a change to emacs 22 caused
>>> problems with compiling vm (an issue with new emacs approach to printing data
>>> structures and fixed easily once I was pointed to the solution).
>>
>> Could you also point me to the solution?
>>
>
> Sure, but I doubt its of much use. It is specific to emacs 22 and affects the
> compilation of the source rather than execution. The URL for the Debian bug
> report on this is 
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410492
>
>> ... maybe I should try to get a more recent Emacs.  
>
> Well, that might help with emacs 22, being a development branch, its always
> wise to checkout the latest version if you run into an issue. However, if your
> getting this under emacs 21, then you probably already have the latest version
> of the stable emacs branch (there hasn't been an emacs 21 update for a while). 

Yeah, I still get the error.

>>> You should also note that you can get some unexpecttd/odd
>>> behavior/errors if you have some emacs code compiled with emacs
>>> 21 and you try to run it under emacs 22 (though code compiled
>>> with emacs 22 is more likely to cause issues for emacs 21). I
>>> run different source trees for emacs 21 and emacs 22 for this
>>> reason.
>>
>> I did not knew that there are problems between 21 and 22, so far
>> I was only beaten by those between X and GNU Emacs, but this is
>> also not the source of my problem ;-/
>>
>
> Its a bad idea (TM) to run code under one version of emacs that was compiled
> under another. For example, emacs 22 has some functions that vary slightly form
> the same functions in emacs 21 and this can cause some interesting problems. 
>
> I still suspect it is either something in your .emacs/.vm or possibly some
> interaction between the VM code and another package you are loading. I have
> since confirmed that I can run VM 7.19 under both emacs 21.4 and emacs 22 (CVS)
> with no errors (and I've got debug on error enabled). I'm running on a Debian
> testing/unstable system and have quite a lot of additional packages installed,
> including a fairly customized .emacs with my own code etc. It is possible you
> are hitting a bug which has been resolved in the Debian package of VM. 
>
> One other thing to check is your VM sources. The VM author hasn't been very
> active for a few years now and there are now a couple of common forks of the
> original code base getting around.

Which are the fork you know?

I am only aware of mine.

Kyle has handed over to me and I am now preparing a VM 8.0
release, but I want to sort out this problem before.

> Even if your not running Debian, it might be worthwhile
> grabbing the Debian VM source package from the unstable branch
> and build it yourself?
>
> It may also be worthwhile posting your .emacs and .vm, just in case there is
> something others may notice that may help. Also, while trying to track down the
> issue, make sure your not loading any other packages that may interact with VM,
> such as bbdb, supercite, trivial-cite, etc, just in case the problem isn't VM,
> but something being triggered by VM. 

O.K. here is my current status on this, with Debian

  emacs21/testing uptodate 21.4a+1-3
  vm/testing uptodate 7.19-11

An the ~/.emacs containing only this single line:

  (setq debug-on-error t)

When I run

  emacs21 -f vm

I get the backtrace

  Debugger entered--Lisp error: (void-function nil)
  (nil)

I am really puzzled now ...

I am running emacs under a different account than the X session
and used .XAuthority to allow it to connect to my X session.

When I run it as

  emacs21 -nw -f vm

the error does not occur.

Gosh, I should have tried the Debian packages earlier ... thanks
for tip.

Still this is odd and I do not really understand it.

> sorry I can't provide more specific help. Emacs 21.4 definitely works with VM
> 7.19 and emacs 22 will work with it once the patch to prevent the compile bug
> is applied. So, all I can say is that I wold be looking for something unique to
> your installation/configuration rather than a bug in emacs or vm. 

Hey, you gave me many good tips!

Thank you!

Robert

  reply	other threads:[~2007-04-08 20:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-13 23:13 How to debug "Debugger entered--Lisp error: (void-function nil)" newsspam5REMOVETHIS
2007-03-14  7:06 ` Tim X
2007-03-31 23:51   ` newsspam5REMOVETHIS
2007-04-01  1:47     ` Tim X
2007-04-08 20:02       ` newsspam5REMOVETHIS [this message]
2007-04-08 20:17         ` newsspam5REMOVETHIS
2007-04-01  0:01   ` newsspam5REMOVETHIS
2007-04-01  2:04     ` Tim X
2007-04-08 19:14       ` newsspam5REMOVETHIS
2007-04-01  2:05     ` Tim X
2007-04-08 20:04       ` newsspam5REMOVETHIS
2007-04-09  5:16         ` Tim X
2007-04-09  9:38           ` Tim X
2007-04-09 20:17           ` newsspam5REMOVETHIS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85wt0mfxcz.fsf@robf.de \
    --to=newsspam5removethis@robf.de \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).