|Anonymous | Login||2017-11-21 12:34 EST|
|Main | My View | View Issues | Change Log | Roadmap | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000857||graphviz||Dot||public||2005-04-01 04:25||2011-04-28 04:03|
|Platform||OS||x86-Linux-Fedora Core 3||OS Version|
|Summary||0000857: 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
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.
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 prueba.dot > prueba.ps
|Tags||No tags attached.|
|STATUS-COMMENT||Fixed (28 April 2005)|
|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|