Thread: [cedet-semantic] Semantic Speedbar Analysis Recursion Problem with stdio.h
Brought to you by:
zappo
From: Manuel S. <man...@gm...> - 2012-12-17 14:16:18
|
Hi, I was using the semantic-speedbar-analysis for my project written in C when emacs got completely stuck and I had to wait for about 30-40 seconds until the speedbar was loaded. During that process it says: "Possible recursion for '_IO_FILE_plus'". I do not have any struct or typedef called like this in my project, therefore I checked the includes directory and figered out that there is the problem: Semantic includes the /usr/include folder for my installed libraries. So if I grep for 'IO_FILE_PLUS in there I get following output: $ grep IO_FILE_plus * libio.h:struct _IO_FILE_plus; libio.h:extern struct _IO_FILE_plus _IO_2_1_stdin_; libio.h:extern struct _IO_FILE_plus _IO_2_1_stdout_; libio.h:extern struct _IO_FILE_plus _IO_2_1_stderr_; I mean I can't really delete that library and couldn't find any help using google etc. Could someone please give me a hint on that? My CEDET configuration looks like this: -------------------------------------------------------- ;; Enable EDE (Project Management) features (global-ede-mode 1) ;;to enable code folding (global-semantic-tag-folding-mode) ;; Enabling Semantic (code parsing, smart completion) features (semantic-load-enable-gaudy-code-helpers) (global-semantic-idle-scheduler-mode 1) ;The idle scheduler with automatically reparse buffers in idle time. ;;(global-semantic-idle-completions-mode 1) ;Display a tooltip with a list of possible completions near the cursor. (global-semantic-idle-summary-mode 1) ;Display a tag summary of the lexical token under the cursor. ;;to work with my include files and cedet ;; (semantic-add-system-include "/usr/include/" 'c++-mode) ;; (semantic-add-system-include "~/include" 'c++-mode) ;; (semantic-add-system-include "~/include" 'c-mode) (semantic-add-system-include "/opt/AMDAPP/include" 'c-mode) (semantic-add-system-include "/opt/AMDAPP/include" 'c++-mode) ;;To use additional features for names completion, and displaying of information for tags & classes, ;; you also need to load the semantic-ia package. This could be performed with following command: (require 'semantic-ia) ;;to work with systme include files and gcc ;;(require 'semantic-gcc) ;;integrate semantic with Imenu (defun my-semantic-hook () (imenu-add-to-menubar "TAGS")) (add-hook 'semantic-init-hooks 'my-semantic-hook) ;;load Semanticdb (require 'semanticdb) (global-semanticdb-minor-mode 1) ;;working with tags ;; gnu global support (require 'semanticdb-global) (semanticdb-enable-gnu-global-databases 'c-mode) (semanticdb-enable-gnu-global-databases 'c++-mode) ;; (setq semantic-idle-scheduler-max-buffer-size 10) (setq speedbar-use-images nil) (semantic-speedbar-analysis) ;; SHOW FUNCTION IN TOP OF EMACS (global-semantic-stickyfunc-mode 1) --------------------------------------------------- |
From: Tomasz G. <to...@wp...> - 2012-12-17 19:12:22
|
Manuel Schneckenreither <man...@gm...> writes: > I was using the semantic-speedbar-analysis for my project written in C > when emacs got completely stuck and I had to wait for about 30-40 > seconds until the speedbar was loaded. During that process it says: > "Possible recursion for '_IO_FILE_plus'". I do not have any struct or > typedef called like this in my project, therefore I checked the > includes directory and figered out that there is the problem: > > Semantic includes the /usr/include folder for my installed > libraries. So if I grep for 'IO_FILE_PLUS in there I get following > output: > > $ grep IO_FILE_plus * > libio.h:struct _IO_FILE_plus; > libio.h:extern struct _IO_FILE_plus _IO_2_1_stdin_; > libio.h:extern struct _IO_FILE_plus _IO_2_1_stdout_; > libio.h:extern struct _IO_FILE_plus _IO_2_1_stderr_; > > > I mean I can't really delete that library and couldn't find any help > using google etc. > > Could someone please give me a hint on that? Hi, If your error message is "Possible metatype recursion for _IO_FILE_plus" then following patch might help. I experienced this problem during name completion after problems with parsing Qt classes where forward declaration was discovered as class declaration. I would like someone to comment on this patch if it is correct and if it doesn't make this code run much slower. I don't really know what those expressions mean but during debugging they seemed to be the same but 'eq' didn't know about it. So IMHO either this patch is ok or parsing part should be fixed to produce exactly the same object for both expressions in 'eq'. === modified file 'lisp/cedet/semantic/analyze/fcn.el' --- a/lisp/cedet/semantic/analyze/fcn.el 2012-12-05 18:52:09 +0000 +++ b/lisp/cedet/semantic/analyze/fcn.el 2012-12-17 18:17:13 +0000 @@ -255,7 +255,7 @@ (nexttype (semantic-analyze-dereference-metatype type scope type-declaration)) (idx 0)) (catch 'metatype-recursion - (while (and nexttype (not (eq (car nexttype) lasttype))) + (while (and nexttype (not (equal (car nexttype) lasttype))) (setq lasttype (car nexttype) lasttypedeclaration (cadr nexttype)) (setq nexttype (semantic-analyze-dereference-metatype lasttype scope lasttypedeclaration)) Regards Tomasz Gajewski |
From: Tomasz G. <to...@wp...> - 2013-01-05 21:04:06
|
"Eric M. Ludlam" <er...@si...> writes: > Hi Tomasz, > > Thanks for the patch. That is a good call on identifying the problem > w/ eq. Usually, all the types are compressed into the semantic > typecache, and dups are removed. That means analysis has a smaller > sorted body to search, speeding things up. It also implies that eq > should be ok. > > Apparently not the case though. :) I expected that it was such a case. > I tried out your patch, and used `semantic-tag-similar-p' so that tags > that are basically the same, but show up in different places (ie - > file location, faux tags vs real tags, etc) will still be considered > equal. It appears to pass all the regular unit tests. > > Could someone give it a try to make sure it is sufficient for this > problem? Do you want to make this change from eq to equal or you want to fix this case to work with eq? Anyway I've experienced problems with testcase I sent you earlier with Qt includes. When opening qstring.h when it was not parsed properly due to missing macro definitios (due to spp-table/spp-files problems you solved some time ago). In such case class definition for QString was not recognized and forward declaration of QString from qchar.h (included from qstring.h) was found and treated as class declaration and for this forward declaration this eq/equal made a difference. Let me know if you were able to reproduce the problem. If not I'll try to prepare a testcase for you. Regards Tomasz Gajewski > On 12/17/2012 02:12 PM, Tomasz Gajewski wrote: >> >> Manuel Schneckenreither<man...@gm...> writes: >> >>> I was using the semantic-speedbar-analysis for my project written in C >>> when emacs got completely stuck and I had to wait for about 30-40 >>> seconds until the speedbar was loaded. During that process it says: >>> "Possible recursion for '_IO_FILE_plus'". I do not have any struct or >>> typedef called like this in my project, therefore I checked the >>> includes directory and figered out that there is the problem: >>> >>> Semantic includes the /usr/include folder for my installed >>> libraries. So if I grep for 'IO_FILE_PLUS in there I get following >>> output: >>> >>> $ grep IO_FILE_plus * >>> libio.h:struct _IO_FILE_plus; >>> libio.h:extern struct _IO_FILE_plus _IO_2_1_stdin_; >>> libio.h:extern struct _IO_FILE_plus _IO_2_1_stdout_; >>> libio.h:extern struct _IO_FILE_plus _IO_2_1_stderr_; >>> >>> >>> I mean I can't really delete that library and couldn't find any help >>> using google etc. >>> >>> Could someone please give me a hint on that? >> >> >> Hi, >> >> If your error message is "Possible metatype recursion for _IO_FILE_plus" >> then following patch might help. I experienced this problem during name >> completion after problems with parsing Qt classes where forward >> declaration was discovered as class declaration. >> >> I would like someone to comment on this patch if it is correct and if it >> doesn't make this code run much slower. I don't really know what those >> expressions mean but during debugging they seemed to be the same but >> 'eq' didn't know about it. So IMHO either this patch is ok or parsing >> part should be fixed to produce exactly the same object for both >> expressions in 'eq'. >> >> >> === modified file 'lisp/cedet/semantic/analyze/fcn.el' >> --- a/lisp/cedet/semantic/analyze/fcn.el 2012-12-05 18:52:09 +0000 >> +++ b/lisp/cedet/semantic/analyze/fcn.el 2012-12-17 18:17:13 +0000 >> @@ -255,7 +255,7 @@ >> (nexttype (semantic-analyze-dereference-metatype type scope type-declaration)) >> (idx 0)) >> (catch 'metatype-recursion >> - (while (and nexttype (not (eq (car nexttype) lasttype))) >> + (while (and nexttype (not (equal (car nexttype) lasttype))) >> (setq lasttype (car nexttype) >> lasttypedeclaration (cadr nexttype)) >> (setq nexttype (semantic-analyze-dereference-metatype lasttype scope lasttypedeclaration)) >> >> |
From: Eric M. L. <er...@si...> - 2013-01-15 01:33:46
|
Hi Tomasz, I opted to go with the fix I proposed. I also added a short-cut in semantic-tag-similar-p in case the tags are eq so no performance will be lost. I was not ultimately able to reproduce the problem you described. If the issue is as hairy as you describe, it may not ultimately be worth trying to figure out the problem with the metatype search. What would be worthwhile is some sort of internal sanity check that Semantic can run against itself at idle time. Thus, if you figure out what went wrong, we might rig up a check that spots the failure, and does a full reset of the offending files, thus fixing the problem more permanently. Thanks Eric >> Could someone give it a try to make sure it is sufficient for this >> problem? > > Do you want to make this change from eq to equal or you want to fix this > case to work with eq? > > Anyway I've experienced problems with testcase I sent you earlier with > Qt includes. When opening qstring.h when it was not parsed properly due > to missing macro definitios (due to spp-table/spp-files problems you > solved some time ago). In such case class definition for QString was not > recognized and forward declaration of QString from qchar.h (included > from qstring.h) was found and treated as class declaration and for this > forward declaration this eq/equal made a difference. > > Let me know if you were able to reproduce the problem. If not I'll try > to prepare a testcase for you. > > Regards > Tomasz Gajewski |
From: Eric M. L. <er...@si...> - 2013-01-04 02:03:11
Attachments:
analyze-fcn.patch
|
Hi Tomasz, Thanks for the patch. That is a good call on identifying the problem w/ eq. Usually, all the types are compressed into the semantic typecache, and dups are removed. That means analysis has a smaller sorted body to search, speeding things up. It also implies that eq should be ok. Apparently not the case though. :) I tried out your patch, and used `semantic-tag-similar-p' so that tags that are basically the same, but show up in different places (ie - file location, faux tags vs real tags, etc) will still be considered equal. It appears to pass all the regular unit tests. Could someone give it a try to make sure it is sufficient for this problem? Thanks Eric On 12/17/2012 02:12 PM, Tomasz Gajewski wrote: > > Manuel Schneckenreither<man...@gm...> writes: > >> I was using the semantic-speedbar-analysis for my project written in C >> when emacs got completely stuck and I had to wait for about 30-40 >> seconds until the speedbar was loaded. During that process it says: >> "Possible recursion for '_IO_FILE_plus'". I do not have any struct or >> typedef called like this in my project, therefore I checked the >> includes directory and figered out that there is the problem: >> >> Semantic includes the /usr/include folder for my installed >> libraries. So if I grep for 'IO_FILE_PLUS in there I get following >> output: >> >> $ grep IO_FILE_plus * >> libio.h:struct _IO_FILE_plus; >> libio.h:extern struct _IO_FILE_plus _IO_2_1_stdin_; >> libio.h:extern struct _IO_FILE_plus _IO_2_1_stdout_; >> libio.h:extern struct _IO_FILE_plus _IO_2_1_stderr_; >> >> >> I mean I can't really delete that library and couldn't find any help >> using google etc. >> >> Could someone please give me a hint on that? > > > Hi, > > If your error message is "Possible metatype recursion for _IO_FILE_plus" > then following patch might help. I experienced this problem during name > completion after problems with parsing Qt classes where forward > declaration was discovered as class declaration. > > I would like someone to comment on this patch if it is correct and if it > doesn't make this code run much slower. I don't really know what those > expressions mean but during debugging they seemed to be the same but > 'eq' didn't know about it. So IMHO either this patch is ok or parsing > part should be fixed to produce exactly the same object for both > expressions in 'eq'. > > > === modified file 'lisp/cedet/semantic/analyze/fcn.el' > --- a/lisp/cedet/semantic/analyze/fcn.el 2012-12-05 18:52:09 +0000 > +++ b/lisp/cedet/semantic/analyze/fcn.el 2012-12-17 18:17:13 +0000 > @@ -255,7 +255,7 @@ > (nexttype (semantic-analyze-dereference-metatype type scope type-declaration)) > (idx 0)) > (catch 'metatype-recursion > - (while (and nexttype (not (eq (car nexttype) lasttype))) > + (while (and nexttype (not (equal (car nexttype) lasttype))) > (setq lasttype (car nexttype) > lasttypedeclaration (cadr nexttype)) > (setq nexttype (semantic-analyze-dereference-metatype lasttype scope lasttypedeclaration)) > > > > Regards > Tomasz Gajewski > > ------------------------------------------------------------------------------ > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial > Remotely access PCs and mobile devices and provide instant support > Improve your efficiency, and focus on delivering more value-add services > Discover what IT Professionals Know. Rescue delivers > http://p.sf.net/sfu/logmein_12329d2d > _______________________________________________ > cedet-semantic mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-semantic > |