Bug#710336: some observations
On Sat, Jun 01, 2013 at 08:57:37PM +0200, Rene Engelhard wrote:
> just noticed I missed a part here:
>
> 10:29 < suihkulokki> setting it to 5 will make the code SIGBUS where the unaligned access being made
That's brilliant: got it!
On ARM v5 running the padauk1 test from the test suite:
mjc@dreamy:~/debian/graphite2/graphite2-1.2.1/build$ ./gr2fonttest/gr2fonttest -trace /home/mjc/debian/graphite2/graphite2-1.2.1/build/tests/padauk1.json -log fred.log /home/mjc/debian/graphite2/graphite2-1.2.1/tests/fonts/Padauk.ttf -codes 1015 102F 100F 1039 100F 1031 1038
Bus error (core dumped)
And with gdb:
Program terminated with signal 7, Bus error.
#0 0xb6ecb620 in graphite2::Pass::readRules (this=0x71b1d0, rule_map=0xb6edf000 "\f\357\001",
num_entries=7443296, precontext=<optimized out>, sort_key=<optimized out>,
o_constraint=<optimized out>, rc_data=0x6f8394 "", o_action=<optimized out>,
ac_data=0x6f8395 "\036", face=...)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/Pass.cpp:202
202 rc_begin = *--o_constraint ? rc_data + be::peek<uint16>(o_constraint) : rc_end;
(gdb) bt
#0 0xb6ecb620 in graphite2::Pass::readRules (this=0x71b1d0, rule_map=0xb6edf000 "\f\357\001",
num_entries=7443296, precontext=<optimized out>, sort_key=<optimized out>,
o_constraint=<optimized out>, rc_data=0x6f8394 "", o_action=<optimized out>,
ac_data=0x6f8395 "\036", face=...)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/Pass.cpp:202
#1 0xb6ecc2b4 in graphite2::Pass::readPass (this=0x71b1d0, pass_start=0x6f78d6 "\001\232",
pass_length=<optimized out>, subtable_base=<optimized out>, face=...)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/Pass.cpp:163
#2 0xb6eceda8 in graphite2::Silf::readGraphite (this=0x719538,
silf_start=0x6f6514 <incomplete sequence \307>, lSilf=<optimized out>, face=...,
version=131072) at /home/mjc/debian/graphite2/graphite2-1.2.1/src/Silf.cpp:178
#3 0xb6ec78a8 in graphite2::Face::readGraphite (this=0x6f64b8, silf=...)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/Face.cpp:120
#4 0xb6ec3098 in (anonymous namespace)::load_face (face=..., options=<optimized out>)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/gr_face.cpp:49
#5 0xb6ec30fc in gr_make_face_with_ops (appFaceHandle=0x6f61b8, ops=0xb6edef00, faceOptions=6)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/gr_face.cpp:62
#6 0xb6ec33f4 in gr_make_file_face (
filename=0xbe93f864 "/home/mjc/debian/graphite2/graphite2-1.2.1/tests/fonts/Padauk.ttf",
faceOptions=6) at /home/mjc/debian/graphite2/graphite2-1.2.1/src/gr_face.cpp:215
#7 0x0000a7d4 in Parameters::testFileFont (this=0xbe93f520)
at /home/mjc/debian/graphite2/graphite2-1.2.1/gr2fonttest/gr2FontTest.cpp:605
#8 0x00009928 in main (argc=14, argv=0xbe93f6c4)
at /home/mjc/debian/graphite2/graphite2-1.2.1/gr2fonttest/gr2FontTest.cpp:819
(gdb) up
#1 0xb6ecc2b4 in graphite2::Pass::readPass (this=0x71b1d0, pass_start=0x6f78d6 "\001\232",
pass_length=<optimized out>, subtable_base=<optimized out>, face=...)
at /home/mjc/debian/graphite2/graphite2-1.2.1/src/Pass.cpp:163
163 o_constraint, rcCode, o_actions, aCode, face)) return false;
(gdb) print o_constraint
$1 = (const graphite2::uint16 * const) 0x6f79dd
And that's the problem, o_constaint is an odd address, but a word (16bit)
access is made to that address at Pass.cpp:202 (in my version of Pass.cpp
that has a few extra printf statements for debugging). It's line 198 in
the original source.
And when run on Alpha it's reporting the exact same line as an unaligned
access.
Now a question (as I don't remember) does the `?' in C/C++ guarantee that
the expression on the left of the `?' is fully evaluated before the true
or false statements are evaluated on the right of the `?'. I don't think
that guarantee is given, in which case the peek of o_constraint in the true
statement may be evaluated before the decrement of o_constraint in the
conditional. If so, this is in the realm of `undefined behaviour'.
If it is known that o_constraint must be odd on entry to
graphite2::Pass::readRules then a fix would be to shift the decrement
of o_constraint to the line before the ternary conditional. Maybe time to
put this analysis to upstream, who will know better, and see what they say.
Cheers
Michael.
Reply to: