Hello Dimitri,
Thanks for your quick reply.
On 14.07.2014, at 20:29, Dimitri van Heesch <doxy...@gmail.com> wrote:
> Hi Torsten,
>
> Seems like a symbol definition has itself as container, which is not good
> (and not possible normally).
> Can you enable the commented out code in Definition::qualifiedName()?
> That will print the name of the symbol. Would be good to know if that symbol
> name came from the tag file.
I followed your advise. Indeed the recursion happens on a symbol coming from
the tag file of library A, which was used already referenced by the Doxyfile of
library B and used again by the Doxyfile of library C.
------------------------------------------------------------------------
$ doxygen Doxyfile
[...]
start sc_core::qualifiedName() localName=sc_core
end sc_core::qualifiedName()=sc_core
start sc_core::sc_in< sc_dt::sc_logic >::qualifiedName() localName=sc_in<
sc_dt::sc_logic >
start sc_core::sc_in< sc_dt::sc_logic >::qualifiedName() localName=sc_in<
sc_dt::sc_logic >
start sc_core::sc_in< sc_dt::sc_logic >::qualifiedName() localName=sc_in<
sc_dt::sc_logic >
[... forever until segfault]
------------------------------------------------------------------------
In the tag file of library A, I find this symbol registered as:
<class kind="class">sc_core::sc_in< sc_dt::sc_logic ></class>
In the tag file of library B, I find this symbol again registered as:
<compound kind="namespace">
<name>sc_core::sc_in< sc_dt::sc_logic ></name>
<filename>a00563.html</filename>
</compound>
This seems wrong to me and could explain, why the definition has itself as
container.
> A workaround you could try is to guard the "else" against simple self
> recursion, i.e. replace
>
> if (m_impl->outerScope->name()=="<globalScope>")
> {
> m_impl->qualifiedName = m_impl->localName;
> }
> else
> {
>
> with
>
> if (m_impl->outerScope->name()=="<globalScope>")
> {
> m_impl->qualifiedName = m_impl->localName;
> }
> else if (m_impl->outputScope!=this)
> {
>
> no guarantee that it will not end up in a recursive loop elsewhere though.
I tried this and now indeed doxygen passes the "Adding xrefitems..." phase to
get stuck in the "Generating namespace index..." phase, which seems to be
coherent with the above observation of the tag file content.
GDB backtrace gives:
------------------------------------------------------------------------
(gdb) bt
#0 0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
#1 0x000000327507a991 in malloc () from /lib64/libc.so.6
#2 0x000000000078e136 in QCString::QCString (this=0x7fffff3ff0c0, size=21)
at scstring.cpp:41
#3 0x000000000078f018 in QCString::mid (this=0x15be6b0, index=23, len=20)
at scstring.cpp:393
#4 0x000000000057bc34 in NamespaceDef::isLinkableInProject (this=0x15be6a0)
at namespacedef.cpp:1049
#5 0x00000000005c9a43 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7978
#6 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7982
#7 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7982
#8 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7982
#9 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7982
#10 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7982
------------------------------------------------------------------------
Looking at the local variables:
------------------------------------------------------------------------
(gdb) up
#1 0x000000327507a991 in malloc () from /lib64/libc.so.6
(gdb) up
#2 0x000000000078e136 in QCString::QCString (this=0x7fffff3ff0c0, size=21)
at scstring.cpp:41
41 m_data = (char *)malloc(size);
(gdb) up
#3 0x000000000078f018 in QCString::mid (this=0x15be6b0, index=23, len=20)
at scstring.cpp:393
393 SCString s( len+1 );
(gdb) up
#4 0x000000000057bc34 in NamespaceDef::isLinkableInProject (this=0x15be6a0)
at namespacedef.cpp:1049
1049 if (extractAnonNs && // extract anonymous
ns
(gdb) up
#5 0x00000000005c9a43 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7978
7978 if (cnd->isLinkableInProject() && cnd->localName().find('@')==-1)
(gdb) print cnd
$1 = (NamespaceDef *) 0x15be6a0
(gdb) print nd
$4 = (NamespaceDef *) 0x15be6a0
(gdb) print includeClasses
$5 = false
(gdb) up
#6 0x00000000005c9ac4 in namespaceHasVisibleChild (nd=0x15be6a0,
includeClasses=false) at util.cpp:7982
7982 else if (namespaceHasVisibleChild(cnd,includeClasses))
(gdb) print nd
$6 = (NamespaceDef *) 0x15be6a0
(gdb) print includeClasses
$7 = false
(gdb) print cnd
$8 = (NamespaceDef *) 0x15be6a0
------------------------------------------------------------------------
… this seems to indicate that doxygen is again recursing on a node linked to
itself.
Do you have any more suggestions how to localize the root of the problem?
> Regards,
> Dimitri
Regards,
Torsten
>
> On 14 Jul 2014, at 15:48 , Torsten Mähne <t0r...@gmx.de> wrote:
>
>> Hello,
>>
>> I think that I've run into the same segfault that has been reported on 20
>> Dec 2013 by JohnOldman
>> <http://doxygen.10944.n7.nabble.com/Segfault-when-using-tag-files-from-documentation-that-has-been-compiled-using-tag-files-td6414.html#a6420>.
>>
>> On 22 Dec 2013, 12:11:47, Dimitri van Heesch <doxygen@gm…> wrote:
>>> On 22 Dec 2013, at 12:31, JohnOldman <j.r.greis@...> wrote:
>>>
>>>> UPDATE:
>>>> I've tried now with a whole bunch of different versions and it seems like
>>>> the problem first arises as of 1.6.2:
>>>> 1.6.1 and 1.6.0 work, 1.6.2 and about half a dozen other newer versions
>>>> I've
>>>> tried give me the same segfault. Could this be an incompatibility with my
>>>> distribution? I'm using Scientific Linux 6.
>>
>> I also observed the segfault on Scientific Linux 6 (RHEL 6 clone) on both,
>> i686 and x86_64 platforms. I also have a situation, where I generate source
>> code documentation for a library C, which depends in a chain on two other
>> libraries B and A: C->B->A. I added the tag files generated by Doxygen for
>> libraries B and A to the Doxyfile of library C.
>>
>> When running doxygen on the Doxyfile of library C, the segfault happens
>> always in the phase Adding xrefitems…
>>
>> On my side, I don't observe the problem on doxygen 1.5.7.1 (Scientific Linux
>> 5 i686).
>>
>>> It is more likely a bug in doxygen introduced in 1.6.2 and triggered by
>>> your specific example.
>>> Can you grab the latest doxygen source from GitHub and compile it using
>>> ./configure --debug and then run it from a debugger and/or from valgrind.
>>> That might give an indication where the problem is located.
>>
>> I did clone the doxygen repository from Github (commit g3a5e6ac), build
>> Doxygen with debug symbols as suggested and executed doxygen on the
>> problematic Doxyfile from within gdb:
>>
>> ------------------------------------------------------------------------
>>
>> $ gdb ~/bin/doxygen
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from ~/bin/doxygen...done.
>> (gdb) run Doxyfile
>> Starting program: ~/bin/doxygen Doxyfile
>> [Thread debugging using libthread_db enabled]
>> …
>> Building group list...
>> Building directory list...
>> Building namespace list...
>> Building file list...
>> Building class list...
>> Associating documentation with classes...
>> Computing nesting relations for classes...
>> Building example list...
>> Searching for enumerations...
>> Searching for documented typedefs...
>> Searching for members imported via using declarations...
>> Searching for included using directives...
>> Searching for documented variables...
>> Building interface member list...
>> Building member list...
>> Searching for friends...
>> Searching for documented defines...
>> Computing class inheritance relations...
>> Computing class usage relations...
>> Flushing cached template relations that have become invalid...
>> Creating members for template instances...
>> Computing class relations...
>> Add enum values to enums...
>> Searching for member function documentation...
>> Building page list...
>> Search for main page...
>> Computing page relations...
>> Determining the scope of groups...
>> Sorting lists...
>> Freeing entry tree
>> Determining which enums are documented
>> Computing member relations...
>> Building full member lists recursively...
>> Adding members to member groups.
>> Computing member references...
>> Inheriting documentation...
>> Generating disk names...
>> Adding source references...
>> Adding xrefitems...
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
>> Missing separate debuginfos, use: debuginfo-install
>> glibc-2.12-1.132.el6.x86_64 libgcc-4.4.6-4.el6.x86_64
>> libstdc++-4.4.6-4.el6.x86_64
>> (gdb) bt full
>> #0 0x0000003275079367 in _int_malloc () from /lib64/libc.so.6
>> No symbol table info available.
>> #1 0x000000327507a991 in malloc () from /lib64/libc.so.6
>> No symbol table info available.
>> #2 0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
>> str=0x8b84fc "::") at ../qtools/qcstring.h:304
>> l = 2
>> #3 0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
>> str=0x8b84fc "::") at scstring.cpp:61
>> No locals.
>> #4 0x00000000005c8f00 in getLanguageSpecificSeparator
>> (lang=SrcLangExt_Unknown,
>> classScope=false) at util.cpp:7746
>> No locals.
>> #5 0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> No locals.
>> #6 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> No locals.
>> #7 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> No locals.
>> #8 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> No locals.
>> #9 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> No locals.
>> #10 0x00000000006da354 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> No locals.
>> [...]
>> ------------------------------------------------------------------------
>>
>> The backtrace continuous to mention Definition::qualifiedName thousands of
>> times (I stopped after #10000).
>>
>> ------------------------------------------------------------------------
>> (gdb) up
>> #1 0x000000327507a991 in malloc () from /lib64/libc.so.6
>> (gdb)
>> #2 0x000000000043354f in QCString::duplicate (this=0x7fffff3ff130,
>> str=0x8b84fc "::") at ../qtools/qcstring.h:304
>> 304 m_data = (char *)malloc(l+1);
>> (gdb)
>> #3 0x000000000078e0ff in QCString::QCString (this=0x7fffff3ff130,
>> str=0x8b84fc "::") at scstring.cpp:61
>> 61 duplicate(str);
>> (gdb)
>> #4 0x00000000005c8f00 in getLanguageSpecificSeparator
>> (lang=SrcLangExt_Unknown,
>> classScope=false) at util.cpp:7746
>> 7746 return "::";
>> (gdb)
>> #5 0x00000000006da326 in Definition::qualifiedName (this=0x1bfe150)
>> at definition.cpp:1358
>> 1358 m_impl->localName;
>> (gdb) print m_impl
>> $1 = (DefinitionImpl *) 0x1bfe260
>> (gdb) print m_impl->localName
>> $2 = {m_data = 0x1c0eba0 "sc_in< sc_dt::sc_logic >"}
>> ------------------------------------------------------------------------
>>
>> This localName is from library A and is actually defined in a namespace
>> called sc_core.
>>
>> Looking at the recursive implementation of Definition::qualifiedName() in
>> the mentioned source file, it seems that the end recursion criteria is never
>> fulfilled:
>>
>> ------------------------------------------------------------------------
>> (gdb) l
>> 1353 }
>> 1354 else
>> 1355 {
>> 1356 m_impl->qualifiedName = m_impl->outerScope->qualifiedName()+
>> 1357 getLanguageSpecificSeparator(getLanguage())+
>> 1358 m_impl->localName;
>> 1359 }
>> 1360 //printf("end
>> %s::qualifiedName()=%s\n",name().data(),m_impl->qualifiedName.data());
>> 1361 //count--;
>> 1362 return m_impl->qualifiedName;
>> (gdb) print m_impl->outerScope->m_impl->qualifiedName
>> $3 = {m_data = 0x0}
>> ------------------------------------------------------------------------
>>
>> Maybe something goes wrong with the lookup through the tag files?
>>
>> I hope you have some suggestion how to fix the problem. I can help with
>> testing a potential fix.
>>
>>> Regards,
>>> Dimitri
>>
>> Best regards,
>>
>> Torsten
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck®
>> Code Sight™ - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Doxygen-users mailing list
>> Doxygen-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Doxygen-users mailing list
Doxygen-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-users
