Is your ftrace ringbuffer overflowing?

Try increasing /sys/kernel/debug/tracing/buffer_size_kb.

Clarification: #0 (1) needs to be run in /sys/kernel/debug/tracing

#1: It might be that the buffer is overflowing (it probably does), but it should not generate this error.

---

Saving the file from chrome://tracing after the error, it looks like the trace is truncated:

# gunzip trace_Thu_Jul_28_2016_4.23.31_PM.json.gz
gzip: trace_Thu_Jul_28_2016_4.23.31_PM.json.gz: unexpected end of file

# cat trace_Thu_Jul_28_2016_4.23.31_PM.json.gz | gunzip -c > trace_Thu_Jul_28_2016_4.23.31_PM.json

Looking at the file, traceEvents are all there (about 14 Mb):

{"traceEvents":[......
{"pid":16528,"tid":16644,"ts":0,"ph":"M","cat":"__metadata","name":"thread_name","args":{"name":"CompositorTileWorker1/16644"}}],

And then systemTraceEvents start:

"systemTraceEvents": "# tracer: nop
n#
n           
u003C...>-18427 [000] d..3    82.016893: sched_switch: prev_comm=systrace.sh prev_pid=18427 prev_prio=120 prev_state=D ==> next_comm=ksoftirqd/0 next_pid=3 next_prio=120
n     ksoftirqd/0-3     [000] d..3    82.016932: sched_switch: prev_comm=ksoftirqd/0 prev_pid=3 prev_prio=120 prev_state=S ==> next_comm=Binder_4 next_pid=18413 next_prio=120
n        Binder_3-17800 [003] dnh2    82.016990: sched_wakeup: comm=gle.android.gms pid=17982 prio=120 success=1 target_cpu=003
n        Binder_3-17800 [003] d..3    82.016994: sched_switch: prev_comm=Binder_3 prev_pid=17800 prev_prio=120 prev_state=R ==> next_comm=gle.android.gms next_pid=17982 next_prio=120
n        Binder_4-18413 [000] d..3    82.017025: sched_switch: prev_comm=Binder_4 prev_pid=18413 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
n          
u003Cidle>-0     [000] d..2    82.017037: cpu_idle: state=0 cpu_id=0
n gle.android.gms-17982 [003] d..3    82.017084: sched_switch: prev_comm=gle.android.gms prev_pid=17982 prev_prio=120 prev_state=S ==> next_comm=Binder_3 next_pid=17800 next_prio=120
.... LOTS of data
n          chrome-17155 [001] d..3    90.588063: sched_switch: prev_comm=chrome prev_pid=17155 prev_prio=120 prev_state=R ==> next_comm=chrome next_pid=16528 next_prio=112
n      lowpool[3]-18420 [003] d..3    90.588065: sched_switch: prev_comm=lowpool[3] prev_pid=18420 prev_prio=130 prev_state=R ==> next_comm=rcu_preempt next_pid=7 next_prio=120
n     rcu_preempt-7     [003] d..3    90.588092: sched_switch: prev_comm=rcu_preempt prev_pid=7 prev_prio=120 prev_state=S ==> next_comm=lowpool[3] next_pid=18420 next_prio=130
n      lowpool[3]-18420 [003] dnh3    90.589954: sched_wakeup: comm=Chrome_ChildIOT pid=16686 prio=112 success=1 target_cpu=003
n            bash-11832 [000] d.h3    90.589974: sched_wakeup: comm=irq/102-ekth350 pid=110 prio=49 success=1 target_cpu=001
n      lowpool[3]-18420 [003] d..3    90.589976: sched_switch: prev_comm=lowpool[3] prev_pid=18420 prev_prio=130 prev_state=R ==> next_comm=Chrome_ChildIOT next_pid=16686 next_prio=112
n          chrome-16528 [001] d..3    90.589998: sched_switch: prev_comm=chrome prev_pid=16528 prev_prio=112 prev_state=R ==> next_comm=irq/102-ekth350 next_pid=110 next_prio=49
n irq/102-ekth350-110   [001] d..3    90.590077: sched_switch: prev_comm=irq/102-ekth350 prev_pid=110 prev_prio=49 prev_state=D ==> next_comm=evdev next_pid=16657 next_prio=120
n Chrome_ChildIOT-16686 [003] d..3    90.590291: sched_switch: prev_comm=Chrome_ChildIOT prev_pid=16686 prev_prio=112 prev_state=S ==> next_comm=lowpool[3] next_pid=18420 next_prio=130
n           evdevF
<EOF!>

Basically, the file ends abruptly (because the gzipped file was truncated, as noted by gunzip).

Running the helper manually seems to work fine:
/usr/libexec/debugd/helpers/systrace.sh start sched power input gfx workq
/usr/libexec/debugd/helpers/systrace.sh stop > /usr/local/trace

jcliang hypothetized that some DBus command from chrome://tracing to debugd is timeout out.

I wonder whether this is a dup of  issue 630030 

Yes, it looks incredibly similar, but I do have easy repro steps, I'll let you de-duplicate as you see fit.