Hi Damien,
I don't think it is necessary to have a .semanticdb file, since you
could also just set
(setq-default semanticdb-new-database-class 'semanticdb-project-database)
to disable file saving altogether, and that is how I run my test suite.
It might be that there is a construct that, when saved, fails to load
back in correctly, which is the opposite from the Emacs daemon which
isn't restarted often.
Any amount of additional investigation you can do would be helpful.
Eric
On 01/26/2010 03:56 AM, Damien Deville wrote:
> Hi,
>
> One thing I spotted which is maybe related to our problem, if I launch
> emacs using the following command "emacsclient -n -c" (which launch
> emacs daemon if it does not run and then launch an emacsclient to
> connect to it), ~/.semanticdb is not created (i suspect that the pop up
> thing that ask the user for permission to create the folder does not
> like daemon part). If i launch a standard emacs, pop up arise and
> .semanticdb folder is created.
>
> When using the daemon / client I still have the errors I reported on
> lots of my c/h files (but due to the thing reported just before I do not
> have any .semanticdb folder). I will try what you suggested in the first
> reply mail to have a better stack trace, but maybe the daemon thing will
> help you targeting the issue.
>
> Damien
>
> Eric M. Ludlam wrote:
>> Hi Damien,
>>
>> The semanticdb tool will check the timestamps and size of files vs when
>> they were last parsed both at load time, and when they are periodically
>> accessed at runtime. If it feels it is out of date, then it will
>> reparse the file from scratch since it cannot know how to incrementally
>> parse the file.
>>
>> I suspect there may be some construct in your header file, or in the
>> file including the foo.h you cite below, that could be causing the issue
>> since it seems to be reproducable.
>>
>> The other possibility is that using Emacs trunk and CEDET/CVS conflicts
>> in some way. I have not yet tried this as Emacs trunk now also has
>> CEDET in it, so a mix of different semantic support files could be
>> causing trouble.
>>
>> Eric
>>
>> On 01/20/2010 11:17 AM, Damien Deville wrote:
>>> Hi cedet-devel,
>>>
>>> I tested cleaning the database and it seem to work, but after few days
>>> issue was back when opening files.
>>>
>>> Here is what i thing occur, i am using git for my sources and handle
>>> lots of different branch stored at the same location on my home folder,
>>> i switch from branch to branch when needed.
>>>
>>> Would it possible that semanticdb record stuffs from branch A for
>>> example and then tries to use it after i switch branch for example to
>>> branch B, leading to semanticdb corruption as both branch share some
>>> code and have subtle differences ?
>>>
>>> Damien
>>>
>>> PS: i also use emacs daemon / emacsclient thus i do not restart often
>>> the daemon part of emacs.
>>>
>>> Eric M. Ludlam wrote:
>>>> Hi Damian,
>>>>
>>>> I haven't seen the issue in any C files I've edited recently. Could you
>>>> do the following?
>>>>
>>>> 1. Setup to get stack traces as you had before.
>>>> 2. Visit the function semantic-decoration-on-includes-highlight-default,
>>>> and eval it, like this:
>>>>
>>>> M-x find-function RET
>>>> semantic-decoration-on-includes-highlight-default RET
>>>> C-M-x ;; eval-defun
>>>>
>>>> 3. reproduce.
>>>>
>>>> this will expand the stack trace and hopefully point more directly at
>>>> the line causing the problem.
>>>>
>>>> The include file in question, from your stack, has no position
>>>> information. This is pretty strange. Thus, I'll guess the attached
>>>> patch helps, but it doesn't explain why you have a tag entering this
>>>> code w/out a position.
>>>>
>>>> I'd guess you were using some external tagger, like ctags, and for some
>>>> reason that produced tags associated with your buffer with no position.
>>>> You config indicates this is not the case. Did you try the ctags
>>>> parser once in the past? Those tags will still be in your .semanticdb
>>>> cache directory. Thus, exiting emacs, deleting your ~/.semanticdb cache
>>>> directory and restarting might also just "fix" the problem without the
>>>> use of the above patch. In that case, we'd need to figure out where the
>>>> bogus tag first came from (like ctags) and see if we can't find and fix
>>>> that bug instead.
>>>>
>>>> Eric
>>>>
>>>> Damien Deville wrote:
>>>>> Hi cedet-devel,
>>>>>
>>>>> Since an unknown number of versions of cedet i suffer from a strange
>>>>> bug that i was able to isolate but not reproduce on simple case
>>>>> yesterday.
>>>>>
>>>>> First i use last emacs trunk and last cedet from cvs, here is an
>>>>> extract of how i enable the modules i want to use in cedet.
>>>>>
>>>>> ; minimal + custom (only activate what we need and use)
>>>>> (semantic-load-enable-minimum-features)
>>>>> (global-semantic-idle-scheduler-mode 1)
>>>>> (global-semantic-idle-summary-mode 1)
>>>>> (global-semantic-idle-tag-highlight-mode 1)
>>>>> (global-senator-minor-mode 1)
>>>>> (global-semantic-decoration-mode 1)
>>>>>
>>>>> The bug is the following:
>>>>>
>>>>> Sometimes, When i open some .c or .h file semantic throws the
>>>>> following error, it also happens when jumping to the definition of a
>>>>> symbol using gtags.el
>>>>>
>>>>> "semantic-decoration-on-includes-highlight: Wrong type argument:
>>>>> arrayp, nil"
>>>>>
>>>>> If i enable debug-on-error here is what i have when trying to switch
>>>>> from a .c file to a .h file using sourcepair (partially anonymized):
>>>>>
>>>>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>>>>> semantic-decoration-on-includes-highlight-default(("foo.h" include
>>>>> nil (dependency-file "/somepath/foo.h") nil))
>>>>> semantic-decoration-on-includes-highlight(("foo.h" include nil
>>>>> (dependency-file "/somepath/foo.h") nil))
>>>>> semantic-decorate-add-decorations((("_XX_XXX_H" variable
>>>>> (:constant-flag t) nil nil) ("foo.h" include nil (dependency-file
>>>>> "/somepath/foo.h") nil) ("func1" function (:prototype-flag t :pointer
>>>>> 1 :arguments ... :type "char") nil nil)))
>>>>> semantic-decoration-mode-setup()
>>>>> semantic-decoration-mode()
>>>>> run-hooks(semantic-init-hook)
>>>>> semantic-new-buffer-fcn()
>>>>> run-hooks(mode-local-init-hook)
>>>>> #[nil "\300 \210\301\302!\207" [activate-mode-local-bindings
>>>>> run-hooks mode-local-init-hook] 2]()
>>>>> mode-local-map-file-buffers(#[nil "\300 \210\301\302!\207"
>>>>> [activate-mode-local-bindings run-hooks mode-local-init-hook] 2]
>>>>> #[nil " =?\207" [mode-local--init-mode major-mode] 2] (#<buffer
>>>>> foo2.h>))
>>>>> mode-local-post-major-mode-change()
>>>>> run-hooks(find-file-hook)
>>>>> after-find-file(nil t)
>>>>> find-file-noselect-1(#<buffer foo2.h> "/somepath/foo2.h" nil nil
>>>>> "/somepath/foo2.h" (10976667 94))
>>>>> find-file-noselect("/somepath/foo2.h" nil nil nil)
>>>>> find-file("/somepath/foo2.h")
>>>>> byte-code("...." [temp search-path possible-filenames
>>>>> matching-filename path-to-check sourcepair-analyze-filename
>>>>> buffer-name 0 message "%s is not a recognized source or header file
>>>>> (consider updating sourcepair-source-extensions or
>>>>> sourcepair-header-extensions)" nil 3 -2 "/*" sourcepair-find-one-of t
>>>>> throw found-matching-file find-file "No matching file for " "
>>>>> (consider updating sourcepair-source-path, sourcepair-header-path)"] 5)
>>>>> sourcepair-load()
>>>>> call-interactively(sourcepair-load nil nil)
>>>>>
>>>>> Here is another trace if i just ido-open-file:
>>>>> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>>>>> semantic-decoration-on-includes-highlight-default(("foo.h" include
>>>>> nil (dependency-file "/somepath/foo.h") nil))
>>>>> semantic-decoration-on-includes-highlight(("foo.h" include nil
>>>>> (dependency-file "/somepath/foo.h") nil))
>>>>> semantic-decorate-add-decorations((("_XX_XXX_H" variable
>>>>> (:constant-flag t) nil nil) ("foo.h" include nil (dependency-file
>>>>> "/somepath/foo.h") nil) ("func1" function (:prototype-flag t :pointer
>>>>> 1 :arguments ... :type "char") nil nil)))
>>>>> semantic-decoration-mode-setup()
>>>>> semantic-decoration-mode()
>>>>> run-hooks(semantic-init-hook)
>>>>> semantic-new-buffer-fcn()
>>>>> run-hooks(mode-local-init-hook)
>>>>> #[nil "\300 \210\301\302!\207" [activate-mode-local-bindings
>>>>> run-hooks mode-local-init-hook] 2]()
>>>>> mode-local-map-file-buffers(#[nil "\300 \210\301\302!\207"
>>>>> [activate-mode-local-bindings run-hooks mode-local-init-hook] 2]
>>>>> #[nil " =?\207" [mode-local--init-mode major-mode] 2] (#<buffer
>>>>> foo2.h>))
>>>>> mode-local-post-major-mode-change()
>>>>> run-hooks(find-file-hook)
>>>>> after-find-file(nil t)
>>>>> find-file-noselect-1(#<buffer foo2.h> "/somepath/foo2.h" nil nil
>>>>> "/somepath/foo2.h" (10976667 94))
>>>>> find-file-noselect("/somepath/foo2.h" nil nil)
>>>>> ido-file-internal(raise-frame)
>>>>> ido-find-file()
>>>>> call-interactively(ido-find-file nil nil)
>>>>>
>>>>> The issue vanish if i disable (global-semantic-decoration-mode 1) but
>>>>> i lose the overline decoration on function declaration which i find
>>>>> fancy and usefull, so to keep that part and disable the decoration on
>>>>> include i am forced to remove the ;;###autoload in
>>>>> semantinc-decorate-include.el.
>>>>>
>>>>> If you need any other information do not hesitate to ask.
>>>>>
>>>>> Damien
>>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Cedet-devel mailing list
> Cedet-devel@...
> https://lists.sourceforge.net/lists/listinfo/cedet-devel
>
|