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

semantic (53)


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.


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)
;; 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
(ede-cpp-root-project "snort+patches"
:file "~/project/CarmentiS/git-svn/snort-tguard/Makefile.am"
:include-path '("/src/include"
:spp-files '( "config.h" ))
(ede-cpp-root-project "CarmentiS"
:file "~/git/CarmentiS/src/README"
:include-path '("."
:spp-files '( "config.h" )))
(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

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


1 2 > >> (Page 1 of 2)
  • Forgot to mention that, as the title implies, the buffer I pressed "M-." in will be closed afterwards.

  • Eric M. Ludlam
    Eric M. Ludlam

    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?


  • Eric M. Ludlam
    Eric M. Ludlam

    • assigned_to: nobody --> zappo
  • 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.

  • Eric M. Ludlam
    Eric M. Ludlam

    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?


  • 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.)

1 2 > >> (Page 1 of 2)