New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate attribute (target="_top" target="_top") generated in .SVG files (Origin: bugzilla #743367) #5724

doxygen opened this Issue Jul 2, 2018 · 0 comments


None yet
1 participant

doxygen commented Jul 2, 2018

status RESOLVED severity normal in component build for ---
Reported in version on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

On 2015-01-22 18:08:29 +0000, wrote:

Created attachment 295212
Screen cap of bug in Firefox, tersed config, subdirectory with SVG files.

Doxygen generates SVG files, which I think are used to display call and caller graphs, will contain two or more target="_top" attributes in the XML.

This is occurring in a huge Visual C++ project with hundreds of thousands of lines of code and comments. I have not seen this in smaller projects. I cannot provide a compile-ready repro for disclosure reasons. I have attempted to isolate a module with no dependencies that generates the error by having Doxygen only build using that module and its header, but that also fails to generate the error. To test proposed fixes, contact me through my bugzilla email address.

Some files ending with _icgraph.svg and _cgraph.svg will contain two or target="_top" attributes in the same XML statement.

No duplicate attributes.

Windows 7 SP1
Tested on Doxygen and 1.8.8
Tested on Firefox 34.0.5, IE 10.0.9200 and Chrome 40.0.2214.91 m
NOTE: The bug appears different in IE - a blank graph is shown with the error message.

Attached is a zip with a Doxygen generated directory of which 49 or 51 files ending with _icgraph.svg or _cgraph.svg are bad, a config tersed -s -u, and a Firefox screen cap of the failing page (since with the provided subdirectory, you cannot properly view the error).

I believe I have seen this bug before, that it had been fixed, and I suspect I am reporting a regression. I tried searching Bugzilla, but could not find the bug report.

On 2015-01-22 18:16:23 +0000, wrote:

For quick reference the bug in SVG file XML looks like this:

and this:

On 2015-01-24 09:03:19 +0000, albert wrote:

Thanks for the report, and the image does show the problem you have, it is a bit hard to reproduce the problem without source (and the html 'd80' is a bit incomplete).

Can you please attach a (small) self-contained example (source+config file in a tar or zip) that allows us to reproduce the problem?

On 2015-01-25 09:07:19 +0000, albert wrote:

I've tried to reproduce the problem with a codebase that I have but have not been able to reproduce the problem. So my question about the example / additional information remains.

At first I missed the remark in the STEPS TO REPRODUCE, which I can fully understand. Sorry for that.

On 2015-01-26 20:25:50 +0000, wrote:

Yes, it is a proprietary big system. The key here word is BIG. And it doesn't happen in mere 100,000 line code projects. Have you tried using my config against something like PAINTLIB?

I don't know what your code looks like, but if you want to put some debugging / tracing code in a module and have me run that version of Doxy against my code, I would be more than happy to do so.

Other than that, I can only point out that it only manifests itself in whatever generates the target="_top code" in the _icgraph.svg and _cgraph.svg files, but not other .SVG file.

Again, just ask and I can help on my side. I am in Los Angeles PST.

On 2015-01-27 18:09:15 +0000, wrote:

I can now reproduce the multiple attribute symptom at will and prevent it from happening.

Delete the generated HTML folder output from the previous Doxygen compilation and run Doxygen. The symptom disappears. Doxygen a second time with existing HTML output. The symptom occurs.

I did some regression testing to see if I could help discover when the problem started. (Very smart thinking to keep all the old distributable available for download!) Doxygen fails starting with release Release does not generate the symptom.

The symptom appears related to Doxygen's reuse of previously compiled HTML output. The number of extra target="_top" attributes added to the .SVG files seems proportional to the number of recompiles done using the old output. Unfortunately, generating the symptom still appears to be related to the actual size of the project. I cannot make the symptom appear in my smaller projects.

As a quick workaround, may I suggest a config option to always delete the HTML output before running the compile?

FYI: My project causes Doxygen to generate 36,000 files and folders for 550MB.

On 2015-01-28 18:27:13 +0000, albert wrote:

This looks like some important information, the multiple runs of doxygen.

I think The fact that it does appear after 1.7.4 is due to the fact that the INTERACTIVE_SVG possibility has been added at that time, as a reference see the release notes of v1.7.5:
New option INTERACTIVE_SVG which when set to YES in combination with DOT_IMAGE_FORMAT=svg will make doxygen generate interactive SVG diagrams that support zooming and panning via the mouse (only for large graphs).

The adding of the target="_top" is done in the DotFilePatcher::run of dot.cpp where replaceRef is called. The DotFilePatcher::run is called (as far as I can see) from the DotManager::run and giving a message like "Patching output file". The patcher is also called from writeDotImageMapFromFile, but without message.

I've now seen the same problem in my codebase, though I have to make one remark that in my case some of the images were not generated in the first "round" and where generated in the second and third "round".
Further investigations are required, but is it possible that a class is defined in more than one place (cpp file). In my case it looks like I have this as multiple programs are defined in the code base and I run doxygen in one go over the entire code base.

On 2017-09-28 07:29:50 +0000, SamK wrote:


I know this is an "old" bug report but I am running the latest doxygen 1.8.13 and I get this double attribute error when having .dot graphs generated for my documentation.

What I noticed is that this happens only when I support external Qt documentation via TAGFILES, i.e. TAGFILES = qtcore.tags=
Once I clear the TAGFILES setting, the dot graphs are shown correctly and the problem disappears.

Is there a fix for this bug available or can I workaround this somehow?


On 2017-09-28 07:31:57 +0000, SamK wrote:

Btw. this is on Windows 10 64-Bit

On 2017-09-28 08:04:34 +0000, albert wrote:

@SamK It looks like it happens only under some rare circumstances. Can you add a small example showing the problem, so we can try to reproduce the problem?

On 2017-09-28 08:10:04 +0000, SamK wrote:

Hi Albert,

by example do you mean my .cfg file I am using? Or what do you need exactly?
The issue I get is happening with a big proprietary project so there is no way for me to extract anything from it (but I could give out the .cfg file of course)

On 2017-09-28 08:21:39 +0000, albert wrote:

@SamK I mean a small project. I.e. configuration file (Doxyfile), source files (minimal / stripped down), tag files, other files to reproduce the problem. To summarize the files so that we only have to start doxygen to reproduce the bug (and can search for the problem).

I do understand the problem with the propriety code. What I always do in such a case is to reduce the number of files (till I have a minimal set, preferably only 1 or 2 source files). In the remaining files I start to strip away as much as possible of the remaining code and comments again till a small minimal example and afterwards I do, when necessary, some name mangling.
This all is a bit tedious of course and can take quite a bit of time but most of the time necessary .

On 2017-09-28 09:16:55 +0000, SamK wrote:

Sure, I have just made such a minimal project where it can be easily reproduced. Where can I send it?

On 2017-09-28 09:20:03 +0000, albert wrote:

Best is to attach it to this bug report otherwise (and just in this case when this is not possible) send it to me.

On 2017-09-28 09:25:15 +0000, SamK wrote:

Created attachment 360583
Duplicate attributes

Using TAGFILES to support Qt documentation and having the class DoxyGenClassA being inherited from Qt's QObject is making the svg dot graphs not showable in Firefox with the duplicate attribute (target="") error.

Fixed by either removing TAGFILES or not inheriting from QObject.

doxygen.exe etc. not included but folder still there. Also link to graphviz needs to be adapted in the config file of course.

On 2017-09-28 09:25:46 +0000, SamK wrote:

Thank Albert, I have just attached it.

On 2017-09-28 09:31:23 +0000, SamK wrote:

Oh one more, it contains a solution for VS2013

On 2017-09-28 10:00:18 +0000, albert wrote:

When running the example I get the message (dots are mine):
XML Parsing Error: duplicate attribute
Location: file:///..../doxygenBug/html/class_doxy_gen_class_a__inherit__graph.svg
Line Number 32, Column 181:

Removing one of the targets does solve the problem (not really feasible for the user), have to check the code.

On 2017-09-28 10:38:27 +0000, SamK wrote:

Yep, that's exactly the error I get. It can be solved by manually removing one of the target tag's from the svg but as you say, that's not feasible for the end-user. It should work straight out of the box.


On 2017-09-28 17:29:32 +0000, albert wrote:

Problem can be overcome, as a workaround, by setting the configuration option EXT_LINKS_IN_WINDOW to NO so the external references will come in the current tab instead of a new tab.

I just pushed a proposed patch to github (pull request 606)

(took a bit of time today as first the regression, pull request 605, had to be solved to properly see the results.

On 2017-09-29 08:54:15 +0000, albert wrote:

Changes have been integrated into the master branch on github.

On 2017-12-25 18:43:43 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.14. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).

On 2018-01-10 23:01:47 +0000, Scott Heavner wrote:

This breaks links from tagfiles, see Bug 792415.

@doxygen doxygen closed this Jul 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment