Graphviz Issue Tracker
Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000857graphvizDotpublic2005-04-01 04:252011-04-28 04:03
ReporterJulio Sanchez 
Assigned Toerg 
PlatformOSx86-Linux-Fedora Core 3OS Version
Summary0000857: Latin1 characters in labels crash dot or make it mishandle escapes

There are two problems that I thought were independent but that I have
traced to the same source.

The first problem is that dot crashes in a repeatable way for a given
input but changes to the input make it crash or not in an unpredictable
way. The test files all contain ISO Latin1 characters in labels.

The second observed problem is that when a label contains an ISO Latin1
character (over 0x7f, that is) immediately followed by an escape sequence
such as \n, the sequence is not interpreted and appears literally in the
output graph.

Since the crash spot varies and makes no sense, I suspected a stack
or arena corruption much earlier to the actual crash, so I resorted to
ElectricFence that is sometimes useful in these cases.

The culprit is the Big5 special-case code in label_size in
dotneato/common/labels.c. Check it and see that it will pass unchecked
the character after some high characters, even if is the terminating
NUL (thus overflowing the space allocated to line and corrupting the
arena now, creating the condition for a later crash) or the \ at the
beginning of the escape sequence.

Disabling that special-case code removes both problems.

I think the diagnosis above is complete, if you really require a test
I will oblige (at least one that shows the escape sequence problem), but
I think that the problem is evident once the culprit piece of code is
put under the light.
Additional Information

It is obvious that the special-case code was added for a reason so just
removing it is not a real fix. I don't have one. Sorry for that.

[erg] Requested input graph and command line options.

I do not have any simple test files that crash. As a matter of fact,
since the crash is delayed from a prior arena corruption, it is
perfectly possible that a file that crashes for me does not crash for
you. The problem is that an allocated area in the arena is overflown
with certain inputs. This corrupts pointers and may result in a
crash. The arena corruption always happens with the right input file,
it is just that the crash may or may not happen, depending on how
large the damage was, the exact memory management done, etc. I run
with Fedora Core 3 that has a debugging memory management
implementation that makes these problems more evident. I have run for
weeks shutting down those checks by setting the environment variable
MALLOC_CHECK_ to 0. But that only hides the problems and does not
prevent all later crashes.

I use graphviz to plot data from GRAMPS, a genealogy program. I can
easily produce files that crash for me but a) they are large, b) they
contain confidential information I am not at liberty to share and c)
they might not crash for you.

But I can easily produce a short file that shows the first symptom
(mishandling of escape sequences) and that, if run with ElectricFence,
will crash. It does not crash for me without
ElectricFence. But will overflow the data area all the same (use a
debugger if you do not believe me). Please find it attached.

>> I've tried several graphs with Latin-1 characters and they all work fine.

Have you tried to put a high-bit-set character right in front of a
escape sequence? Or right at the end of the label? Remember my
characterization of the bug: after some characters that have the
high-bit set, the next character is copied into the output without any
special processing even if it is the terminating NUL or the backslash
at the beginning of a escape sequence. Read the code, it is obvious
once you are told.

>> Also, please
>> specify what command line options you used. Thanks.

  dot -Tps >

TagsNo tags attached.
STATUS-COMMENTFixed (28 April 2005)
VERSION     2.2
Attached Files

- Relationships

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2011-04-28 04:03 user1 New Issue
2011-04-28 04:03 user1 Assigned To => erg

MantisBT 1.2.5[^]
Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker