Re: [Doxygen-users] Segfault when using tag files from documentation that has been compiled using t

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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 <t0...@gm...> 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&#174;
> Code Sight&#153; - 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
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] Segfault when using tag files from documentation that has been compiled using t

Re: [Doxygen-users] Segfault when using tag files from documentation that has been compiled using tag files