Thread: [Doxygen-develop] doxygen loops when passing "foo(>0)" to findParameterList
Brought to you by:
dimitri
Menu
▾
▴
doxygen-develop
|
From: Helmut G. <he...@su...> - 2013-08-04 12:58:10
|
Control: clone 718151 -1
Control: reassign -1 doxygen 1.8.4-1
Control: severity -1 normal
Control: retitle -1 doxygen loops when passing "foo(>0)" to findParameterList
On Sat, Aug 03, 2013 at 11:21:11PM +0200, Matthias Klose wrote:
> fix it in libburn or disable building the docs. upstream did tell you that they
> didn't want to update that for newer doxygen versions. There is absolutely no
> reason to reassign this to doxygen.
While the report was not overly helpful, part of the issue is with
doxygen. I looked into the issue and pull in
dox...@li... for further assistance.
So the issue at hand is that doxygen does not terminate when building
the documentation for libburn. On interrupting doxygen after leaving it
running for some time you will see a traceback like this:
#0 findParameterList (name=...) at util.cpp:1848
#1 0x00000000005f894f in resolveRef (scName=0x0, name=0x1657d30 "burn_abort(>0)", inSeeBlock=false, resContext=0x7fff9a4e8c40, resMember=0x7fff9a4e8c48, lookForSpecialization=true, currentFile=0x1603fc0, checkScope=true) at util.cpp:4363
#2 0x00000000006a608c in handleLinkedWord (parent=0x1c8f4c0, children=...) at docparser.cpp:1030
#3 0x00000000006b832e in DocPara::parse (this=0x1c8f480) at docparser.cpp:6311
#4 0x00000000006b257e in DocSimpleSect::parse (this=0x1c8f410, userTitle=false, needsSeparator=false) at docparser.cpp:4570
#5 0x00000000006b3436 in DocPara::handleSimpleSection (this=0x16594c0, t=DocSimpleSect::Since, xmlContext=false) at docparser.cpp:4887
#6 0x00000000006b59bf in DocPara::handleCommand (this=0x16594c0, cmdName=...) at docparser.cpp:5399
#7 0x00000000006b8a4e in DocPara::parse (this=0x16594c0) at docparser.cpp:6478
#8 0x00000000006b9abb in DocRoot::parse (this=0x1651080) at docparser.cpp:6843
#9 0x00000000006ba35b in validatingParseDoc (fileName=0x164f620 ".../libburn/libburn.h", startLine=3608, ctx=0x156b7e0, md=0x183a3a0, input=0x1653f80 " Either by setting an own handler or\nby activating the built-in signal handler.\n\nA function parameter handle of NULL activates the built-in abort handler. \nDepending on mode it may cancel all drive op"..., indexWords=true, isExample=false, exampleName=0x0, singleLine=false, linkFromIndex=false) at docparser.cpp:7085
#10 0x0000000000574224 in OutputList::generateDoc (this=0x18790e0, fileName=0x164f620 ".../libburn/libburn.h", startLine=3608, ctx=0x156b7e0, md=0x183a3a0, docStr=..., indexWords=true, isExample=false, exampleName=0x0, singleLine=false, linkFromIndex=false) at outputlist.cpp:153
#11 0x000000000055e4a0 in MemberDef::writeDocumentation (this=0x183a3a0, ml=0x17405b0, ol=..., scName=0x1641150 "libburn.h", container=0x1603fc0, inGroup=false, showEnumValues=false, showInline=false) at memberdef.cpp:2745
#12 0x000000000056aff5 in MemberList::writeDocumentation (this=0x17405b0, ol=..., scopeName=0x1641150 "libburn.h", container=0x1603fc0, title=0x163d660 "Function Documentation", showEnumValues=false, showInline=false) at memberlist.cpp:655
#13 0x0000000000446904 in FileDef::writeMemberDocumentation (this=0x1603fc0, ol=..., lt=MemberListType_docFuncMembers, title=...) at filedef.cpp:1742
#14 0x000000000044263f in FileDef::writeDocumentation (this=0x1603fc0, ol=...) at filedef.cpp:685
#15 0x000000000042364f in generateFileDocs () at doxygen.cpp:7842
#16 0x0000000000430ab7 in generateOutput () at doxygen.cpp:11231
#17 0x00000000004032c6 in main (argc=2, argv=0x7fff9a4e9818) at main.cpp:38
Indeed the issue lies within findParameterList. The name parameter
passed to resolvRef as a c string is passed to the former function as a
QString, but its value still represents "burn_abort(>0)". Given this
value, findParameterList goes into an infinite "do { ... } while (...)"
loop. The loop iterations alternate between templateDepth=0 and
templateDepth=1. On the second iteration it will take "then" branch of
the outer "if" and will set nextOpenPos=-1 and nextClosePos=-1. This
causes the inner "else" branch to be selected setting pos=-2 and thus
continuing the loop.
A possible fix would be to change the loop condition from
"while(pos != -1)" to "while(pos >= 0)".
Is this analysis correct?
As for the libburn maintainers, I suggest to change the comment in the
header to not include the verbatim string "burn_abort(>0)" in order to
not confuse doxygen. Yeah, it's a bug in doxygen that it loops, but
you'll have to work around this one for the time being.
Helmut
|
|
From: Albert <alb...@gm...> - 2013-08-04 15:40:48
|
This looks a bit like *Bug 701295*<https://bugzilla.gnome.org/show_bug.cgi?id=701295>- Doxygen 1.8.4 goes into an endless loop. Did you try it with the current git version as well? If the problem is still present please submit a bug in the bug tracer with a self-contained example (source+config file in a tar or zip) that allows us to reproduce the problem? Albert On Sun, Aug 4, 2013 at 2:31 PM, Helmut Grohne <he...@su...> wrote: > Control: clone 718151 -1 > Control: reassign -1 doxygen 1.8.4-1 > Control: severity -1 normal > Control: retitle -1 doxygen loops when passing "foo(>0)" to > findParameterList > > On Sat, Aug 03, 2013 at 11:21:11PM +0200, Matthias Klose wrote: > > fix it in libburn or disable building the docs. upstream did tell you > that they > > didn't want to update that for newer doxygen versions. There is > absolutely no > > reason to reassign this to doxygen. > > While the report was not overly helpful, part of the issue is with > doxygen. I looked into the issue and pull in > dox...@li... for further assistance. > > So the issue at hand is that doxygen does not terminate when building > the documentation for libburn. On interrupting doxygen after leaving it > running for some time you will see a traceback like this: > > #0 findParameterList (name=...) at util.cpp:1848 > #1 0x00000000005f894f in resolveRef (scName=0x0, name=0x1657d30 > "burn_abort(>0)", inSeeBlock=false, resContext=0x7fff9a4e8c40, > resMember=0x7fff9a4e8c48, lookForSpecialization=true, > currentFile=0x1603fc0, checkScope=true) at util.cpp:4363 > #2 0x00000000006a608c in handleLinkedWord (parent=0x1c8f4c0, > children=...) at docparser.cpp:1030 > #3 0x00000000006b832e in DocPara::parse (this=0x1c8f480) at > docparser.cpp:6311 > #4 0x00000000006b257e in DocSimpleSect::parse (this=0x1c8f410, > userTitle=false, needsSeparator=false) at docparser.cpp:4570 > #5 0x00000000006b3436 in DocPara::handleSimpleSection (this=0x16594c0, > t=DocSimpleSect::Since, xmlContext=false) at docparser.cpp:4887 > #6 0x00000000006b59bf in DocPara::handleCommand (this=0x16594c0, > cmdName=...) at docparser.cpp:5399 > #7 0x00000000006b8a4e in DocPara::parse (this=0x16594c0) at > docparser.cpp:6478 > #8 0x00000000006b9abb in DocRoot::parse (this=0x1651080) at > docparser.cpp:6843 > #9 0x00000000006ba35b in validatingParseDoc (fileName=0x164f620 > ".../libburn/libburn.h", startLine=3608, ctx=0x156b7e0, md=0x183a3a0, > input=0x1653f80 " Either by setting an own handler or\nby activating the > built-in signal handler.\n\nA function parameter handle of NULL activates > the built-in abort handler. \nDepending on mode it may cancel all drive > op"..., indexWords=true, isExample=false, exampleName=0x0, > singleLine=false, linkFromIndex=false) at docparser.cpp:7085 > #10 0x0000000000574224 in OutputList::generateDoc (this=0x18790e0, > fileName=0x164f620 ".../libburn/libburn.h", startLine=3608, ctx=0x156b7e0, > md=0x183a3a0, docStr=..., indexWords=true, isExample=false, > exampleName=0x0, singleLine=false, linkFromIndex=false) at > outputlist.cpp:153 > #11 0x000000000055e4a0 in MemberDef::writeDocumentation (this=0x183a3a0, > ml=0x17405b0, ol=..., scName=0x1641150 "libburn.h", container=0x1603fc0, > inGroup=false, showEnumValues=false, showInline=false) at memberdef.cpp:2745 > #12 0x000000000056aff5 in MemberList::writeDocumentation (this=0x17405b0, > ol=..., scopeName=0x1641150 "libburn.h", container=0x1603fc0, > title=0x163d660 "Function Documentation", showEnumValues=false, > showInline=false) at memberlist.cpp:655 > #13 0x0000000000446904 in FileDef::writeMemberDocumentation > (this=0x1603fc0, ol=..., lt=MemberListType_docFuncMembers, title=...) at > filedef.cpp:1742 > #14 0x000000000044263f in FileDef::writeDocumentation (this=0x1603fc0, > ol=...) at filedef.cpp:685 > #15 0x000000000042364f in generateFileDocs () at doxygen.cpp:7842 > #16 0x0000000000430ab7 in generateOutput () at doxygen.cpp:11231 > #17 0x00000000004032c6 in main (argc=2, argv=0x7fff9a4e9818) at main.cpp:38 > > Indeed the issue lies within findParameterList. The name parameter > passed to resolvRef as a c string is passed to the former function as a > QString, but its value still represents "burn_abort(>0)". Given this > value, findParameterList goes into an infinite "do { ... } while (...)" > loop. The loop iterations alternate between templateDepth=0 and > templateDepth=1. On the second iteration it will take "then" branch of > the outer "if" and will set nextOpenPos=-1 and nextClosePos=-1. This > causes the inner "else" branch to be selected setting pos=-2 and thus > continuing the loop. > > A possible fix would be to change the loop condition from > "while(pos != -1)" to "while(pos >= 0)". > > Is this analysis correct? > > As for the libburn maintainers, I suggest to change the comment in the > header to not include the verbatim string "burn_abort(>0)" in order to > not confuse doxygen. Yeah, it's a bug in doxygen that it loops, but > you'll have to work around this one for the time being. > > Helmut > > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Doxygen-develop mailing list > Dox...@li... > https://lists.sourceforge.net/lists/listinfo/doxygen-develop > |
|
From: Helmut G. <he...@su...> - 2013-08-04 20:11:17
|
Control: forwarded 718151 https://bugzilla.gnome.org/show_bug.cgi?id=701295 Control: tags 718151 fixed-upstream On Sun, Aug 04, 2013 at 05:40:40PM +0200, Albert wrote: > This looks a bit like *Bug > 701295*<https://bugzilla.gnome.org/show_bug.cgi?id=701295>- Doxygen > 1.8.4 goes into an endless loop. > Did you try it with the current git version as well? Thanks for looking it up. The git version changes the relevant code in a way, that fixes the observed behaviour. Helmut |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X