#94 semantic-ia-fast-jump only closes buffers

closed-fixed
semantic (53)
5
2009-11-02
2009-08-21
No

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

Discussion

<< < 1 2 (Page 2 of 2)
  • 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.

     
  • Eric M. Ludlam
    Eric M. Ludlam
    2009-10-01

    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.

     
  • Eric M. Ludlam
    Eric M. Ludlam
    2009-10-01

    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.

     
  • Eric M. Ludlam
    Eric M. Ludlam
    2009-10-03

    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.

     
  • Eric M. Ludlam
    Eric M. Ludlam
    2009-10-18

    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.

     
  • Eric M. Ludlam
    Eric M. Ludlam
    2009-11-02

    • status: open --> closed-fixed
     
<< < 1 2 (Page 2 of 2)