Skip to content
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

Trailing backslash in a label causes an error #13

Closed
mgedmin opened this issue Jan 30, 2014 · 3 comments
Closed

Trailing backslash in a label causes an error #13

mgedmin opened this issue Jan 30, 2014 · 3 comments

Comments

@mgedmin
Copy link

mgedmin commented Jan 30, 2014

Try this:

$ cat test.dot
graph {
  a[label="trailing backslash \\"];
}
$ dot -Tpng -o test.png test.dot

dot from graphiviz 2.36 on Windows complains:

Warning: c:\windows\temp\...\test.dot: syntax error in line 2 near ''

It also fails to create the PNG file.

(The actual test case I had complained about a syntax error near ',' despite there being no ',' on that line.)

dot from graphviz 2.26.3 on Ubuntu 13.10 is perfectly happy with this file and creates the expected PNG.

If the label is changed to contain anything after the escaped backslash (e.g. a single space), dot 2.36 on Windows stops complaining and starts generating PNGs.

@emdenrg
Copy link
Collaborator

emdenrg commented Jan 30, 2014

This was due to a change in the scanner in 2.32 but I can't understand why the change was made, so I've reversed the change.

@graphviz
Copy link
Collaborator

On Jan 30, 2014, at 9:00 AM, Emden R. Gansner notifications@github.com wrote:

This was due to a change in the scanner in 2.32 but I can't understand why the change was made, so I've reversed the change.


Reply to this email directly or view it on GitHub.

Was there any comment along with the commit?

@emdenrg
Copy link
Collaborator

emdenrg commented Jan 30, 2014

Yes, but it more or less repeats what I said above. In the original commit, I said something about not mapping double backslashes to themselves because the latter might be escaping a quote, but that just means one needs to use an additional backslash. The muddle is partly due to the multiple layers of string quoting, once at parse time, and again when generating text output.
In any case, the current code reflects what was done in the original scanner.

@emdenrg emdenrg closed this as completed Feb 4, 2014
pipcet pushed a commit to pipcet/graphviz that referenced this issue Jan 18, 2021
Address Sanitizer detected a few instances of the following:

  Direct leak of 168 byte(s) in 7 object(s) allocated from:
    #0 0x7f4bc2724330 in __interceptor_malloc (/lib/x86_64-linux-gnu/libasan.so.5+0xe9330)
    ellson#1 0x7f4bc24b1ea3 in vec_new /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:918
    ellson#2 0x7f4bc24b291a in find_all_cycles /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1073
    ellson#3 0x7f4bc24b2b64 in get_cycle_centroid /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1121
    ellson#4 0x7f4bc24b3c5c in makeStraightEdges /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1233
    ellson#5 0x7f4bc24b35f8 in makeStraightEdge /tmp/tmp.m68Z0dFAYs/graphviz/lib/common/routespl.c:1203
    ellson#6 0x7f4bbdf28b52 in _spline_edges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:659
    ellson#7 0x7f4bbdf29240 in splineEdges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:736
    ellson#8 0x7f4bbdf29310 in spline_edges1 /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:749
    ellson#9 0x7f4bbdf293be in spline_edges0 /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:779
    ellson#10 0x7f4bbdf29bcb in spline_edges /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatosplines.c:817
    ellson#11 0x7f4bbdf14ea6 in neato_layout /tmp/tmp.m68Z0dFAYs/graphviz/lib/neatogen/neatoinit.c:1489
    ellson#12 0x7f4bc242b6fc in gvLayoutJobs /tmp/tmp.m68Z0dFAYs/graphviz/lib/gvc/gvlayout.c:85
    ellson#13 0x559fcd474960 in main /tmp/tmp.m68Z0dFAYs/graphviz/cmd/dot/dot.c:132
    ellson#14 0x7f4bc21d709a in __libc_start_main ../csu/libc-start.c:308

find_all_cycles() was calling vec_delete() on the temporary vector it allocated,
but it did not take into account that the nested vectors were not freed by
vec_delete(). This change moves the open coded clean up logic from
get_cycle_centroid() into vec_delete() to fix this and make it less likely that
this is missed in future.

This was initially encountered while investigating #1554.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants