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.
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.
Regards,
Dimitri
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
