semantic-ia-fast-jump only closes buffers
Brought to you by:
zappo
Menu
▾
▴
#94 semantic-ia-fast-jump only closes buffers
Hi!
I really have two problems which seem related. Please split this
ticket if they aren't:
1) With a ede-cpp-root-project configuration, sometimes opening a file will result in (wrong-type-argument (or eieio-object-p class-p) nil)
I have a file I can always reproduce this with, unfortunately the
source code belongs to my employer, so I can't publish it.
See "Backtrace 1" in attached file.
2.)
On the second attempt, I *can* open the file and if I then try to
semantic-ia-fast-jump on a certain symbol, I get (error "Selecting
deleted buffer"):
See "Backtrace 2" in attached file.
For both of these Problems I used the following cedet-config.el (which
is loaded into my .emacs:
{{{
(require 'cedet)
(require 'ecb)
(require 'semanticdb-global)
(require 'ede-cpp-root)
(require 'gtags)
(global-ede-mode 1)
(semantic-load-enable-gaudy-code-helpers)
(semantic-load-enable-all-exuberent-ctags-support)
;; if you want to enable support for gnu global
(global-semantic-folding-mode 1)
(global-senator-minor-mode 1)
(semanticdb-enable-gnu-global-databases 'c-mode)
(semanticdb-enable-gnu-global-databases 'c++-mode)
(global-srecode-minor-mode 1)
(eval-after-load 'cedet
'(progn
(orionif
(progn
(ede-cpp-root-project "snort+patches"
:file "~/project/CarmentiS/git-svn/snort-tguard/Makefile.am"
:include-path '("/src/include"
"/include"
"../include"
"include")
:spp-files '( "config.h" ))
(ede-cpp-root-project "CarmentiS"
:file "~/git/CarmentiS/src/README"
:system-include-path
'("/lib/libcarmentis/logging/src"
"/lib/libcarmentis/data"
"/core/cs_dump"
"/export/cs_export")
:include-path '("."
"../include"
"include")
:spp-files '( "config.h" )))
nil)
(semantic-add-system-include "/usr/lib/gcc/x86_64-linux-gnu/4.1/include" 'c-mode)
(semantic-add-system-include "/usr/lib/gcc/x86_64-linux-gnu/4.3/include" 'c-mode)
(semantic-add-system-include "/usr/include/c++/4.3/tr1" 'c++-mode)))
(provide 'cedet-config)
;;; Local variables:
;;; auto-recompile: t
;;; End:
}}}
If I comment out the ede-cpp-root-projects, clear out ~/.semanticdb
and restart emacs, the same attempt gives a different error and
backtrace.
See "Backtrace 3" in attached file.
I hope those backtraces already help you to track down the problem.
If not, I can provide assistance by trying to find a minimal emacs
configuration and set of source files to track down the problem, but I
may need help with that (i.e. what settings or semantics elements of a
source file may be related to the problem).
Kind regards
FDF
Forgot to mention that, as the title implies, the buffer I pressed "M-." in will be closed afterwards.
If you delete ede-cpp-root.elc (the compiled version) restart Emacs, and recreate the stack (backtrace 1), it will show more about what it is trying to do. That might help debug.
There is also a chance there is a single problem related to exuberent ctags. If you comment out that line and clear out the DB caches, does that help?
Are you using CEDET from CVS, or the last 1.0pre6 release?
Thanks
Sorry for my late reaction, somehow I mistracked this and failed to notice that I was supposed to provide more info.
I tried both methods you proposed at once and I still get a backtrace, hopefully with more information this time.
I'll attach it.
New backtrace, with ede-cpp-root.elc deleted and exuberant tags disabled.
And I'm using cedet from cvs, but the last checkout was on august 19.
Bug is still present in cvs checkout from today, with and without exuberant ctags.
I have checked in a change today that should fix the stack in cedet-backtrace-new. Stacks in code that is not byte-code is very helpful. I didn't reproduce the problem, so thus could not verify a fix. Could you test it?
Thanks
Ok, it seems the first problem is fixed now, I can open the file without error and it gets parsed.
The second problem is still present, i.e. semantic-ia-fast-jump closes the buffer, I'll attach a new backtrace for that. I've made sure to nuke all *.elc files.
I think I can give some more information on what I'm trying to do here:
As you can see in the backtrace I tried semantic-ia-fast jump on cs_argos_t which is a typedef'd struct declared in <cs_argos.h> which is in a completely different Module of the project (i.e. it's supposed to be installed on the system).
(Note that for testing purposes I sometimes have a version of those headers installed in $HOME/local/include but I'd still prefer semantic to give me the location in the source tree. But that's a different matter.)
New Backtrace from semantic-ia-fast-jump
I just noticed that the problem is related to the fact that the root of my project tree is a symbolic link. I just exchanged the directory and the symlink and don't get an error any more. The symbol is not found with semantic-ia-fast-jump, but I get a proper error message in the mode line, the buffer stays open so I can try semantic-complete-jump, which works.
I had forgotten to mention, the bug I fixed was that an entry in the cpp preprocessor file table (The :spp-files slot in your ede-project root) had an invalid file in it, which caused the first error which is now fixed. It should be throwing a warning now about not finding the file. If you were expecting some CPP macros to exist that is needed to parse files for finding the symbol in question, then that was likely it. After fixing that in your config, if it is then relevant to what you are trying to do, you will need to clear your .semanticdb cache, and have your files reparsed in a fresh Emacs session.
Your new backtrace indicates that the current buffer has no parsing information or semanticdb table. Is it in c++ or c mode? You can use semantic-c-describe-environment to see what it thinks.
Regarding the invalid file: indeed, I forgot to add "build" to the include path, which is where the generated config.h file can be found. But of course it only contains simple 0 or 1 macros generated by configure.
I can only reproduce the backtrace if I swap the project root back to the symlinked version, and the exact path seems to matter (i.e. just switching to the new symlink doesn't give me the error).
What am I looking for in the output of semantic-c-describe-environment? It looks identical every time, whether the bug will occur or not.
The c environment was to look for differences in how the header files were found, which I thought might be related. Instead, because of the symlinks, I would guess you need to change ede--disable-inode which might reveal that there is something funny going on w/ symlinks and the file caches that is built up.
Ok, I can reproduce the behaviour (buffer deletion) under the conjunction of these two circumstances:
- the root of the project Directory is a symlink set up in the way it used to be when the bug first occured
- ede--disable-inode is nil
If I change one of these conditions, I just get the regular error.
Ok, so symlinks and the inode caching don't seem to mix. What is the "regular error"? Is that the backtrace related to the fast-jump command?
> What is the "regular error"? Is that the backtrace related to the fast-jump command?
Yes. Or it used to be. Now fast-jump works for the example symbol. I wonder what changed...
For my part this bug can be closed now, as the main error is fixed, and another one apparently disappeared as well.
If I encounter more oddities I'll file a new bug, as this one contains two different problems already, which both seem to be fixed.