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
