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
next prev parent 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
* 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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.